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

Question

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

В спецификации HTTP / 1.1 (раздел 9.6) обсуждаются соответствующие коды ответа / ошибки. Однако это не относится к содержанию ответа.

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

Answer 5

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

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

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

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

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

Answer 6

Http-код ответа 201 для «Создано» вместе с заголовком «Местоположение», указывающим, где клиент может найти вновь созданный ресурс.

Answer 7

Если серверная часть REST API является реляционной базой данных SQL, тогда

1. вы должны иметь RowVersion в каждой записи, которую можно обновить (чтобы избежать проблемы потерянного обновления )
2. Вы должны всегда возвращать новую копию записи после PUT (чтобы получить новый RowVersion ).

Если вы не заботитесь о потерянных обновлениях или хотите заставить своих клиентов делать GET сразу после PUT, то ничего не возвращайте из PUT.

Answer 8

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

Answer 9

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

Answer 10

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

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