Pull to refresh

Comments 15

Есть ли у вас пакетные операции, например удалить несколько ID? Как вы их реализуете, начиная от вида uri, http метода запроса и параметров передаваемых клиентом, заканчивая серверной логикой. Специальный ли это обработчик или это все сводится к обработчику удаления одного ID, как проверяется авторизация и права на выполнение операции?
Есть ли у вас пакетные операции, например удалить несколько ID?

Стараемся обходиться без них, как не вполне соответствующим принципам REST. Но в случае реализации, передавали бы массивом список ID. На стороне сервера будет обработчик удаления одного ID который проверяет право пользователя на совершение действия перед вызовом метода удаления одного ID, т.к. иначе и парсинг, проверка прав и работа с базой была бы в одном методе.

как проверяется авторизация и права на выполнение операции?

Вот тут предложено несколько методов разграничения прав пользователей в RESTful web API. Планирую написать продолжение статьи как раз об этом вопросе.
HTTP метод при этом в запросе остается DELETE? Параметры передаются в строке URI после "?" (как с ограничением длины дела обстоят)?
HTTP метод при этом в запросе остается DELETE?

Да. Хотя на стороне Caché легко можно добавить свои методы вроде BATCHDELETE.
Вот так
В классе %Projection.REST в блоке <xs:simpleType name="action"
Добавьте XML нод: <xs:enumeration value="BATCHDELETE" />
Скомпилируйте класс %Projection.REST
Добавьте в карту путей брокера новый путь: <Route Url="/test3/:ArrayArg" Method="BATCHDELETE" Call="Test3">
Скомпилируйте класс брокера.

Либо можно попробовать модифицировать карту путей так, чтобы при передаче одного элемента и нескольких элементов с разделителем вызывались различные методы.

Параметры передаются в строке URI после "?" (

Параметры передаются так: server.com/rest/collection/arg1/arg2/arg3

как с ограничением длины дела обстоят?

На стороне сервера происходит Regex поиск совпадения, так что теоретически всё ограничено максимальной длиной строки в Caché (3641144 в 2014.1), однако существуют ещё и ограничения браузера/веб-сервера.
Либо можно попробовать модифицировать карту путей так, чтобы при передаче одного элемента и нескольких элементов с разделителем вызывались различные методы.

Ещё можно добавить в метод проверку на существования параметра — для более гибкого вывода.
Например: добавить параметр id в методе GetAllCompanies(id As %String) As %Status. В брокере будет запись вида:
URL = "/json/companies/:id"
тогда добавим в метод условие проверки добавляющее в запрос строку " Where id = '"_id_"'" (не забудьте перед where поставить пробел) — получим конкретную компанию, а в случае его отсутствия запрос выдаст все компании.
" Where id = '"_id_"'"

Не надо советовать людям, то как не надо делать, пускай sql-инъекции в Cache сложнее, но они все равно возможны.
И советую вам тоже так не делать.
Защита от инъекций реализуется в DispatchRequest после этого в классы приходят только проверенные данные, к тому же когда таких запросов много текст брокера и обработчиков воспринимается легче. Безопасность вне Caché security — тема для отдельной статьи.
Всегда есть вероятность что мимо проверки что-то может проскочить, а вот при использовании параметризованных запросов, защита уже 100%. И не стоит этим пренебрегать никогда.
«параметризованных» и «защита 100%»
Это как? Спасибо.
мимо проверки
На мой взгляд одно из удобств связки REST и брокера состоит в том что мы получаем единую точку передачи параметров в базу и вызова методов, которую вполне возможно контролировать.
Параметризованные запросы, это когда все необходимые параметры для фильтрации запроса передаются в Execute или другой подобный метод, как отдельные переменные, а не формируется sql на их основе. Защита 100%, это значит что при таком формировании запросов, никакие значения входящих параметров никак не испортят сам запрос.

Не всегда есть возможность построить приложение таким образом чтобы все запросы от пользователя шли только через брокер. Например, если приложение старое и только переходит на новые интерфейсы, и было написано иначе, либо вообще не используется REST и брокер. Поэтому нужно всегда следовать некоторым правилам при разработке, так будто на любом этапе данные могут быть испорчены. Дополнительные проверки не помешают и добавят безопасности вашему приложению.
Как вы их реализуете

Зависит от того кто и как формирует JSON для передачи в Caché. На стороне сервера, в приёмнике необходимо приведении типов. Например почти всегда необходимо указывать в %ConvertJSONToObject тип обрабатываемого объекта, здесь это "Data.Company".
Специальный ли это обработчик

Да. В большинстве случаев необходимо писать свой обработчик. Мы формируем массив данных c помощью AngularJS и передаём их как в примере. Так же в JSON можно передавать несколько наборов данных.
авторизация и права

Если используется CSP (Caché Server Pages), то достаточно встроенной системы безопасности Так же Caché умеет создавать cookies на сервере.
А какие есть альтернативы построения REST API для свободных баз данных?
Не являюсь специалистом по FOSS СУБД, но мне кажется более вероятным использование каких-либо внешних средств для построения RESTful web API с подключением их к бд.

Также можно скачать однопользовательскую версию Cache (бесплатно) или использовать GlobalsDB с NodeJS.
Поставил минус за смешение в аннотации понятий REST и RESTful.
Sign up to leave a comment.