POSTing к ресурсу контроллера - должен ли ID контролера быть частью URI контроллера или параметром POST?

Question

В моей модели ресурсов у меня есть ресурс "подписка". Он проходит через состояния жизненного цикла, такие как «неподписанный» -> «ожидающий подписки» -> «подписанный» -> «ожидающий отписки» -> «отписанный».

Чтобы разрешить клиентам подписываться или отписываться от подписки, я планирую выставить два ресурса контроллера (называемые «sub» и «unsub») для подписки / отмены подписки, каждый из которых принимает запросы POST, которые синхронно помещают целевую подписку. перевести ресурс в соответствующее состояние «ожидание» и асинхронно выполнить дополнительную работу, чтобы перевести подписку в состояние «подписка» или «отказ от подписки».

Я могу подумать о нескольких способах назначения клиентом целевой подписки при отправке запроса POST на «sub» или «unsub». Я мог бы поместить целевой идентификатор подписки в URI, например так:

/ подписки / {subscription_id} / суб или, может быть / Суб / {subscription_id}

[Примечание. Предоставление идентификатора подписки в URI не представляет проблемы безопасности для моего приложения.]

Или я мог бы сделать идентификатор подписки параметром POST для:

/ суб

Мысли о том, какой подход предпочтительнее? Если вы предпочитаете подход URI, какой стиль URI вам больше нравится и почему?

Примечание: подписка, которая была отписана, впоследствии может быть повторно подписана, поэтому действие «отписаться» не эквивалентно удалению ресурса подписки.

Answer 1

Ради полноты я собираюсь дать еще один ответ, основанный на дальнейших исследованиях и рассмотрении.

В конечном счете, если вы следуете принципу HATEOAS, URI, отличные от верхнего уровня, эффективнонепрозрачный для клиентов, и, следовательно, с точки зрения клиента, на самом деле не имеет большого значения, определен ли контролируемый элемент в URI контроллера или нет.В качестве практического и эстетического аспекта с точки зрения службы, исключение его из URI контроллера делает его короче и проще, поэтому вот что.

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

Для моего проекта я в конечном итоге решил предоставить один ресурс контроллера в URI / subscription_tasks, принимая POSTкоторые включают действие (подписаться / отписаться) и целевой идентификатор подписки в качестве параметров формы в полезной нагрузке POST.POST возвращает ресурс subscription_task, который можно отслеживать с помощью опроса GET до тех пор, пока задача не будет завершена.

Answer 2

Я бы сделал ID параметром POST для / subscription.

Вместо того, чтобы иметь отдельный ресурс / отменить подписку, я бы отправил запрос DELETE в / подписку (передавая ID таким же образом).

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

РЕДАКТИРОВАТЬ - после уточнения.

REST использует глаголы GET, POST, PUT и DELETE.GET здесь не имеет смысла для создания / обновления.Вы не хотите УДАЛИТЬ, потому что вы хотите, чтобы ресурс оставался рядом.Поэтому я бы порекомендовал сделать POST для создания / запуска подписки и PUT для изменения / отмены подписки.Это небольшое неправильное использование глагола PUT, но я думаю, что оно подходит вам немного лучше, чем альтернативы.