Должна ли операция RESTful " PUT " вернуть что-то

мне было интересно, что мнения людей о RESTful PUT операция, которая возвращает nothing (null) в теле ответа.

321
put resources rest service

10 ответов

спецификация HTTP (RFC 2616) имеет ряд рекомендаций, которые применимы. Вот моя интерпретация:

  • HTTP-статус-код 200 OK для успешного ввода обновления в существующий ресурс. Тело реакции не требуется. (Per 9.6, 204 No Content еще более уместно.)
  • HTTP-статус-код 201 Created для успешной сдачи нового resource, с наиболее определенным URI для нового ресурса, возвращаемого в Поле заголовка местоположения и любые другие соответствующие URI и метаданные ресурса повторяются в теле ответа. (RFC 2616 раздел 10.2.2)
  • HTTP-статус-код 409 Conflict для PUT, который является неудачным из-за на 3rd - модификация партии, со списком различий между попыткой обновления и текущим ресурсом в ответе тело. (RFC 2616 раздел 10.4.10)
  • HTTP-статус-код 400 Bad Request за неудачную Положите, с текст на естественном языке (например, на английском) в тексте ответа это объясняет, почему пут не удался. (RFC 2616 раздел 10.4)
487

в отличие от большинства ответов здесь, я действительно думаю, что PUT должен вернуть обновленный ресурс (в дополнение к HTTP-коду, конечно).

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

112

код ответа Http 201 для " создан "вместе с заголовком" расположение", чтобы указать, где клиент может найти вновь созданный ресурс.

3

на HTTP / 1.1 spec (раздел 9.6) обсуждает соответствующие коды ответов/ошибок. Однако он не касается содержимого ответа.

Что бы вы ожидали ? Простой код ответа HTTP (200 и т. д.) мне кажется прямолинейным и недвусмысленным.

2

Я думаю, что сервер может возвращать контент в ответ на PUT. Если вы используете формат конверта ответов, который позволяет загружать данные (например, формат, используемый ember-data), вы также можете включить другие объекты, которые могут быть изменены с помощью триггеров базы данных и т. д. (Sideloaded данные явно для уменьшения # запросов, и это кажется прекрасным местом для оптимизации.)

Если я просто принимаю PUT и мне нечего сообщить, я использую статус код 204 без тела. Если у меня есть что сообщить, я использую код состояния 200 и включаю тело.

2

Я использовал RESTful API в своих сервисах, и вот мое мнение: Сначала мы должны прийти к общему мнению: PUT используется для обновления ресурса, который не создается и не получает.

Я определил ресурсы с: Stateless resource и Stateful resource:

  • ресурсы без гражданства Для этих ресурсов просто верните HttpCode с пустым телом, этого достаточно.

  • ресурсы состояния Например: версия ресурса. Для такого рода ресурсов, необходимо предоставить версия, когда вы хотите изменить ее, поэтому верните полный ресурс или верните версию клиенту, поэтому клиенту не нужно отправлять запрос get после действия обновления.

но, для службы или системы, держите его simple, clearly, easy to use and maintain это самое главное.

1

ОК... хотя я бы подумал, что рудиментарное указание на успех/неудачу / время опубликовано / # байты получены / и т. д. было бы лучше.

edit: я думал о целостности данных и / или ведении записей; метаданные, такие как хэш MD5 или метка времени для полученного времени, могут быть полезны для больших файлов данных.

-2

В идеале это вернет ответ успеха / неудачи.

-3

Так же, как пустое тело запроса соответствует первоначальной цели запроса GET, а пустое тело ответа соответствует первоначальной цели запроса PUT.

-3

существует разница между заголовком и телом HTTP-ответа. PUT никогда не должен возвращать тело, но должен возвращать код ответа в заголовке. Просто выберите 200, если он был успешным, и 4xx, если нет. Нет такой вещи, как код возврата null. Почему ты хочешь это сделать?

-3