Можно предположить, что другой клиент также изменил другие аспекты ресурса в промежуточный период. Так лучше ли всегда включать полное представление в ответ на PUT, несмотря на накладные расходы на пропускную способность?
В REST я должен вернуть представление в ответ на PUT?
Ответ 1
Комментарий Jldupont указал мне в правильном направлении. Я буду использовать ETags, чтобы определить, был ли изменен ресурс, выполнив условный PUT с использованием заголовка If-match, как описано здесь.
Затем, в случае конфликта, я разрешу пользователю решить, следует ли получать последнее представление с сервера (GET) или перезаписать изменения со своим собственным.
Таким образом, нет необходимости возвращать полное представление в ответе на PUT, чтобы помочь в обнаружении и разрешении конфликтов.
Ответ 2
Во многих случаях (если не в большинстве случаев) сервер добавит что-то к ресурсу, даже если он создан или обновлен через PUT. Примерами являются временные метки, номер версии или любой элемент, вычисленный из других. Это верно, даже если вы следуете подходу RESTful и не используете PUT для частичных обновлений.
Только по этой причине возвращение обновленного или созданного представления ресурсов часто является хорошей идеей для запросов PUT. Я бы не стал называть его "лучшей практикой", хотя, если вы нажмете гигантский файл изображения размером 2 ГБ, вы, вероятно, не захотите вернуть его как часть ответа.
Включение ETag, с другой стороны, определенно заслуживает статуса "лучшей практики".
Ответ 3
Мне нравится думать, что GET и DELETE являются парой - они берут только идентификатор.
POST и PUT выглядят как пара. Они берут сериализованный объект и делают его постоянным. Следовательно, я думаю, что POST и PUT должны возвращать результирующий объект как созданный.
В некоторых случаях вы можете выполнять дополнительные вычисления как часть сохранения, а PUT может отражать полученные результаты. Технически это может быть 3-я нормальная форма, потому что вы получили значения. Но часто цель веб-службы состоит в том, чтобы сделать некоторый расчет добавленной стоимости как часть POST и, возможно, PUT.
Ответ 4
Возможно, вы захотите рассмотреть ответ 303 See Other с заголовком Location, установленным в URI обновленного ресурса (Post/Redirect/Get). Таким образом, клиент получает текущее состояние ресурса (если он хочет следовать заголовку Location), даже если он был отредактирован промежутком времени и не может повторно отправить запрос при использовании браузера.
Однако этот шаблон исключает отправку соответствующего кода успеха (200 OK, 202 Accepted и т.д.), который может быть полезен для клиента. Кроме того, в зависимости от вашего определения REST вы можете считать, что это нестандартная практика.
Вероятно, более вероятно, что клиенты, скорее всего, будут браузерами, управляемыми людьми.