В REST я должен вернуть представление в ответ на PUT?

Question

Возможно, что другой клиент также изменил другие аспекты ресурса в промежуточный период. Поэтому лучше ли всегда включать полное представление в ответ на PUT, несмотря на издержки полосы пропускания?

Answer 1

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

Только по этой причине возврат обновленного или созданного представления ресурса часто является хорошей идеей для запросов PUT. Однако я не обязательно назвал бы это «лучшей практикой» - если вы поместите гигантский 2 ГБ файл изображения, вы, вероятно, не захотите возвращать его как часть ответа.

Включение ETag, с другой стороны, определенно заслуживает статуса "лучшей практики".

Answer 2

Комментарий Илдупонта указал мне верное направление. Я буду использовать ETag, чтобы определить, был ли изменен ресурс, выполнив условное PUT с использованием заголовка If-match , как описано здесь .

Затем, в случае конфликта, я позволю пользователю решить, получать ли последнее представление с сервера (GET) или перезаписывать изменения своим собственным.

Таким образом, нет необходимости возвращать полное представление в ответе на PUT только для того, чтобы помочь в обнаружении и разрешении конфликтов.

Answer 3

Мне нравится думать, что GET и DELETE - это пара - они берут только ID.

POST и PUT также кажутся парой. Они берут сериализованный объект и делают его постоянным. Следовательно, я думаю, что и POST, и PUT должны возвращать полученный объект как созданный.

В некоторых случаях вы можете выполнять дополнительные вычисления как часть постоянства, и PUT может отражать эти вычисленные результаты. Технически, это может быть третьим нормальным нарушением формы, потому что вы получили производные значения. Но часто весь смысл веб-службы заключается в том, чтобы сделать некоторые дополнительные вычисления в рамках POST и, возможно, PUT.

Answer 4

Возможно, вы захотите вернуть ответ 303 See Other с заголовком Location, установленным в URI обновленного ресурса ( Post / Redirect / Get ). Таким образом, клиент получает текущее состояние ресурса (если он решает следовать заголовку Location), даже если он был отредактирован в промежуточный период, и ему не грозит повторная отправка запроса при использовании браузера.

Однако этот шаблон исключает отправку соответствующего кода успеха (200 OK, 202 Accepted и т. Д.), Который может быть полезен для клиента. Кроме того, в зависимости от вашего определения REST, вы можете считать это нестандартной практикой.

Вероятно, более уместно, если клиенты, скорее всего, будут браузерами, управляемыми людьми.