Я не могу понять, как мне обрабатывать имена переходов, чтобы они соответствовали лучшим практикам 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, который я мог бы использовать в качестве эталона?