RESTful - что должно содержать тело ответа DELETE

предположим, у меня есть API, где вы можете получить пользователей:

GET /RESTAPI/user/

и вы можете удалить пользователей:

DELETE /RESTAPI/user/123

Что такое спокойная конвенция о том, что должно содержать тело ответа DELETE? Я ожидал, что это должен быть новый список всех пользователей, который теперь больше не содержит пользователя с id 123.

Googling вокруг не получил никаких удовлетворительных ответов. Я только нашел мнения о том, как это сделать,но разве нет строгого определение RESTful-сервисов?

это не дубликат что должен возвращать RESTful API POST / DELETE в теле? и какие остальные вызовы PUT/POST / DELETE должны возвращаться по соглашению? поскольку эти вопросы требуют строгого определения относительно DELETE. Эти вопросы только отвечал только свободные мнения.

20
http rest restful-url

4 ответов

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

Я использовал это как руководство для RESTful services http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Он говорит, что ответьте со статусом 204 и пустым телом

Я придерживаюсь этих стандартов и документировать их для тех, кто хочет использовать мой Апис

24

204 No Content является популярным ответом для DELETE и иногда PUT Как хорошо.

однако, если вы реализуете HATEOAS, возвращая 200 OK С ссылок может быть более идеальным. Это связано с тем, что API HATEOAS REST предоставляет контекст клиенту. Подумайте о местоположении, в которое пользовательское приложение переходит после успешного выполнения команды delete. Вот краткий отрывок из статьи с более подробным обсуждением этого вопроса. См. статью в блоге для более полного обсуждение.

избегайте 204 ответов, если вы создаете приложение HATEOAS.

это урок о дизайне REST API, который я узнал при создании нетривиальных REST API. Чтобы быть максимально поддерживающим клиента, API REST не должен возвращать 204 (без содержимого) ответа.

С точки зрения службы, ответ 204 (без контента) может быть абсолютно корректным ответом на запрос POST, PUT или DELETE. В частности, для запроса на удаление это кажется очень подходящим, потому что что еще вы можете сказать?

однако, с точки зрения правильного клиента, осведомленного о HATEOAS, ответ 204 проблематичен, потому что нет ссылок, чтобы следовать. Когда гипермедиа выступает в качестве движка состояния приложения, когда нет ссылок, нет состояния. В других слова, ответ 204 отбрасывает все состояние приложения.

в данной статье рассматриваются POST, PUT, DELETE и GET. Вот конкретное обсуждение на DELETE:

отвечая на запросы удаления

запрос на удаление представляет намерение удалить ресурс. Таким образом, если служба успешно обрабатывает запрос на удаление, что еще она может сделать, кроме возврата 204 (без содержимого)? Ведь ресурс только что убрали.

ресурс часто является членом коллекции или иным образом "принадлежит" контейнеру. В качестве примера,http://foo.ploeh.dk/api/tags/rock представляет собой тег "rock", но другой способ взглянуть на него заключается в том, что ресурс /rock содержится в контейнере тегов (который сам является ресурсом). Это должно быть знакомо пользователям Atom Pub.

представьте, что вы хотите удалить http://foo.ploeh.dk/api/tags/rock ресурс. Для достижения этой цели вы выдаете запрос на удаление против него. Если все, что ваш клиент получает обратно, это 204 (без контента), он просто потерял свой контекст. Куда она ведет оттуда? Если вы не держите состояние на клиенте, вы не знаете, откуда вы пришли.

вместо того, чтобы возвращать 204 (без контента), API должен быть полезен и предлагать места для перехода. В этом примере я думаю, что одна очевидная ссылка для предоставления -http://foo.ploeh.dk/api/tags - контейнер из которого клиент только что удалил ресурс. Возможно, клиент хочет удалить больше ресурсов, так что это будет полезной ссылкой.

3

что такое спокойная конвенция о том, что DELETEтело ответа должно содержать?

REST-это архитектурный стиль, определенный Филдингом в Глава 5 его диссертации и описывает набор противопоказаний для приложений, построенных с этой архитектурой. Отдых предназначен для протокол indenpendent но Глава 6 той же диссертации описывает, как применяется REST через https.

как только ваше приложение REST разработано в верхней части протокола HTTP, вы должны знать о семантике HTTP. И semantis протокола HTTP/1.1 В настоящее время описано в RFC 7231.

полезная нагрузка ответа DELETE запрос, который успешно может:

  • быть пустым или;
  • включить представление статуса действие.

и следующие коды состояния ответа подходят для DELETE запрос, который удался:

  • 202: запрос был принят к обработке, но обработка не была завершена.
  • 204: сервер успешно выполнил запрос и что нет никакого дополнительного контента для отправки в полезной нагрузке ответа тело.
  • 200: запрос выполнен успешно, и полезная нагрузка запроса включает представление состояния действия.

см. следующую цитату из RFC 7231:

если DELETE метод успешно применен, исходный сервер должен отправить 202 (принято) код состояния, если действие, вероятно, удастся но еще не было принято, a 204 (без содержимого) код состояния, если этот приняты соответствующие меры, и никакой дополнительной информации представлено не будет., или 200 (OK) код состояния, если действие было принято и ответное сообщение включает в себя представление о состоянии.

2

Я бы сказал, что лучше всего держать ответы единообразными независимо от вызова. Говоря это с более прагматичной точки зрения, так как я работаю со многими API. Мне не очень нравится иметь дело с разными заголовками, кодами состояния и т. д. за ответ. Реакция 200 является лучшей, и тело может действительно иметь что-то о реакции. Не очевидно, что запрос на удаление, например, действительно удалил что-либо. Ответ может указывать на это или на наличие ошибки.

-3