Я создаю RESTful API, и некоторые из построенных мной маршрутов предназначены для поддержки типичных действий, связанных с «групповым» ресурсом. Для моих целей группа будет объектом, который позволяет пользователям системы быть «членами» группы и позволять им взаимодействовать друг с другом и т. Д. Например, «группа», называемая «Исследовательская группа», может позволить учащимся чтобы общаться друг с другом путем обмена заметками, файлами, сообщениями в чате и т. д.Правильные маршруты API REST для создания и обработки объекта «группы»
Мой вопрос: Что такое правильный способ создания URL-адресов маршрутов для поддержки создания, чтения, обновления и удаления связанные с группами? Должен ли объект группы быть организован под пользователем в URL? Следует ли разделять группы, поскольку это собственный объект, не подчиненный одному пользователю?
Сравните, например, следующие 2 маршрута:
GET /users/{id}/groups
и
GET /groups
Что лучше? Первый маршрут хорош для представления коллекции групп, членом которой является данный пользователь, но разве это не означает, что пользователь является абсолютным владельцем группы на всю вечность? Когда другие участники хотят отправить комментарий группе, если они будут вынуждены использовать следующий маршрут, который включает идентификатор пользователя? Например, должны ли другие пользователи комментировать делать что-то вроде этого?
POST /users/{id}/groups/{id}/comments
Мне кажется, что когда-то группа существует правильный маршрут для взаимодействия с ней должно быть что-то простое и универсальное, как, после чего опускает идентификатор пользователя от него. Это также сделало бы легко переключаться владельцев/админов группы без необходимости обновлять соответствующие разработчикам маршрута будет опираться на:
GET /groups/{id}
ли уместен/допустимое (с точки REST API), чтобы позволить прибоя, который отыскивает текущие группы пользователей по-прежнему будут связаны и организованы под объектом пользователя в URL-адресе, но для выполнения всех других взаимодействий с группой непосредственно по маршруту «групп», который не включает идентификатор пользователя? И если нормально организовывать вызовы под объектом «пользователи» на маршруте и иметь другие маршруты, основанные исключительно на объекте «group», не будет требовать, чтобы значения «user_id» передавались как часть вызовов манипуляции (чтобы знать, например, кто делает комментарий в группе)?
Я хочу сделать что-то, что правильно и имеет смысл. Ищете других людей, чтобы предлагать советы и дважды проверять мои мысли, прежде чем я соглашусь на то, что я делаю.
Заранее благодарен!
Одна последняя мысль, которую я имел при написании этого вопроса ...
Если я держать группы объектов подчиненного пользователю то, возможно, это нормально. Я говорю, что, поскольку любой вызов маршрута в будущем, сделанный любым другим пользователем, который является членом группы, будет звонить на общий ресурс группы исходя из их собственных уникальных значений в маршруте. Другими словами, как только пользователь является членом группы, результирующий маршрут, который они пинг для выполнения чего-либо, уникален для каждого пользователя, но ссылается на общий ресурс.
Например, два пользователя A и B размещения комментария к группе (с ID 52135) могут быть следующими:
// User A's unique route to post a comment to the group
POST /users/2867823/groups/52135/comments
// User B's unique route to post a comment to the group
POST /users/8872341/groups/52135/comments
Правило большого пальца должно быть не более двух уровней гнездования. –