Как правильно должен выглядеть адрес для REST объекта?
Добрый день.
Есть rest сервер. Три сущности: project, section, ticket. Проект содержит в себе несколько разделов, каждый раздел - несколько тикетов.
По идее для создания раздела путь должен быть таким: POST /projects/:project_id/sections А для обновления такой: PUT /projects/:project_id/sections/:section_id Дело в том, что у разделов id уникален в пределах всей системы, а не конкретного проекта, поэтому его можно определить без указания проекта. Поэтому путь для редактирования может выглядеть так: PUT /sections/:section_id
По идее, раз это вложенные сущности, то в пути для внутренней надо указать id внешней. Подскажите какой подход распростанен? Как правильно будет построить путь?
представьте что это у вас иерархия в виде дерева каталога, сразу станет очевидно что вам необходимо указывать проджект айди.
и обычно наоборот используют - для создания пут, для обновления пост - это связанно со спецификаций, позволяющей в пост запросе отправлять не все данные объекта, в отличии от например пут, где необходимо высылать все данные объекта.
>> то связанно со спецификаций, позволяющей в пост запросе отправлять не все данные объекта, в отличии от например пут, где необходимо высылать все данные объекта.<<
В чем же это заключается? И там и там параметры отправляются в теле запроса и я волен как угодно формировать их список.
>> представьте что это у вас иерархия в виде дерева каталога, сразу станет очевидно что вам необходимо указывать проджект айди. <<
Вот я и хотел избавиться от полной иерархии. Т.к. путь, например, к созданию лейбла для тикета выглядит так: POST /projects/:project_id/sections/:section_id/tickets/:ticket_id/labels
При этом серверу не надо знать ничего про раздел, только про тикет и проект.
HaruAtari: да вот именно там и описано что обновление используя пут-распространённая практика, но почему всё же лучше делать наоборот.
However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests.
HaruAtari: дело в том что например если у вас по запросу проджект айти будет выдаваться список секций, выбрав которую, будет выдаваться список тикетов, выбрав который будет выдавать список ещё чего-либо, то вы вдруг обнаружите что разработчику для использования вашего апи даже не надо читать документацию.
более того у разработчика уже есть инструменты для навигации по вашему апи используя расширения к навигационным оболочкам, которые позволяют организовать навигацию по всему дереву апи, имея 1 точку входа.
поэтому лучше выстраивать понятные иерархи, чем городить что-то не связанное.
дима кубитский: >> да вот именно там и описано что обновление используя пут-распространённая практика, но почему всё же лучше делать наоборот.
However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests. <<
Я все-таки не совсем понял, в чем претензия к распространенному подходу? Тут рекомендуется использовать PUT для идемпонентных запросов, а POST для неидемпонентных.
Если я отправляю два одинаковых запроса на создание, то они будут неидемпонентными т.к. для каждого будет создана новая сущность. При этом запросы на изменение с одинаковыми параметрами приведут к повторному обновлению полей сущности до тех же значений т.к результат будет одинаковым и запрос идемпонентный. Все-таки выходит, что создание - post, а редактирование - put.
Простой
Средний
Средний
Простой
Средний
