Как я могу справиться с расширением ресурсов при разработке/выполнении переходов в Moqui?

Я не могу понять, как мне обрабатывать имена переходов, чтобы они соответствовали лучшим практикам RESTful API в случае расширения ресурсов.

Например, если я хочу получить все заказы для определенного клиента, URI должен быть похож на https://api.website.com/customers/1000/orders.

Я могу сделать переходы спокойными для одного ресурса, то есть клиентов или заказов (как это было продемонстрировано в файле примера приложения в Moqui.), но не смог найти ни одного примера, который решит цель расширения ресурсов.

Проблема, с которой я сталкиваюсь, заключается в разработке переходов в соответствии с лучшими практиками спокойного API. В ExampleApp.xml есть примеры только для одного ресурса, т. е. объекта-примера.

Если я возьму модель данных, используемую в HiveMind в отношении управления проектами, то URI должен быть таким в соответствии с передовой практикой.

For fetching all Projects- https://api.website.com/projects
For fetching a Milestone for a particular Project - https://api.website.com/projects/DP/milestones/DP-MS-01 (Here, DP is the Project Id)
For fetching a Tasks of a particular Project- https://api.website.com/projects/DP/tasks/DP-1

Теперь, если я разрабатываю API в среде Moqui, вот как я должен назвать URI.

For fetching all Projects- https://api.website.com/projects
For fetching a Milestone of a Project- https://api.website.com/projects/DP/DP-MS-1
For fetching a Task of a Project- https://api.website.com/projects/DP/DP-1

Итак, вы можете видеть, что эти URI сбивают с толку, поскольку я не могу различить URI для получения вехи или задачи.

Я все еще могу создавать URI в соответствии с лучшими практиками проектирования restful API, проверяя параметры пути (т. Е. Если задачи находятся в параметре пути, тогда выполняйте операции, связанные с задачей, и аналогично для вех). Но этот подход не будет чистым, так как его обслуживание будет затруднено, если в URI будет слишком много параметров, таких как https://api.website.com/projects/DP/milestones/DP-MS-1/tasks/DP-1/worklogs/DP-1-WL-2/party.

Это всего лишь пример сценария, в котором я хочу получить группу/человека, который добавил рабочий журнал для задачи на определенной вехе определенного проекта. Это случай одной модели данных, то есть WorkEffort.

Но как насчет партий, клиентов, заказов, продуктов и т. д. моделей данных? Разработка API станет чрезвычайно утомительной работой для разработчика API.

Поэтому я просто спросил, есть ли другой более чистый подход, реализованный в Moqui, который я мог бы использовать в качестве эталона?


person adityazoso    schedule 27.02.2015    source источник


Ответы (2)


В последней версии Moqui Framework (еще не выпущенной, доступной только в репозитории GitHub, хотя она станет частью следующего выпуска) теперь есть автоматический интерфейс REST для выполнения операций поиска и CrUD.

Он поддерживает шаблоны, подобные описанным в этом вопросе, и многие другие, некоторые примеры см. в комментариях в файле экрана rest.xml (который обрабатывает запросы REST объекта):

https://github.com/moqui/moqui/blob/master/runtime/base-component/webroot/screen/webroot/rest.xml

person David E. Jones    schedule 26.03.2015

Концепция Moqui, которая обрабатывает это, - это параметры пути. Самые простые примеры — в примерах службы RESTful на экране ExampleApp.xml:

https://github.com/moqui/moqui/blob/master/runtime/base-component/example/screen/ExampleApp.xml

Пример запроса в комментарии на этом экране с curl выглядит так:

curl -X GET -H "Authorization: Basic am9obi5kb2U6bW9xdWk=" 
    http://localhost:8080/apps/example/ExampleEntity/TEST2

Переход, который обрабатывает этот запрос, выглядит так:

<transition name="ExampleEntity" method="get" read-only="true">
    <path-parameter name="exampleId"/>
    <actions>
        <entity-find-one entity-name="Example" value-field="example"/>
        <script>ec.web.sendJsonResponse(example)</script>
    </actions>
    <default-response type="none"/>
</transition>

Обратите внимание на использование элемента transition.path-parameter и на то, что этот переход применяется только к запросам с методом HTTP GET. Все, что находится после местоположения перехода в URL-адресе, рассматривается как параметр пути и помещается в поля контекста, такие как «exampleId» выше, в порядке элементов параметра пути.

В вашем случае у вас будет 2 параметра пути, идентификатор клиента и строка «заказы», ​​сообщающая ему о получении заказов для клиента.

person David E. Jones    schedule 27.02.2015
comment
Более полное освещение этой темы содержится в книге Making Apps with Moqui, которую можно загрузить с сайта moqui.org. . - person David E. Jones; 27.02.2015
comment
Я сослался на ExampleApp.xml, но он не содержит примеров, которые решат проблему, с которой я столкнулся. Поэтому я отредактировал вопрос, чтобы лучше объяснить мою проблему. - person adityazoso; 03.03.2015