Если операция RESTful "PUT" возвращает что-то

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Я определил ресурсы с помощью: Stateless resource и Stateful resource:

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

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

Но, для службы или системы сохраните ее simple, clearly, easy to use and maintain. Это самая важная вещь.

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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