REST - изменяет часть ресурса - ПОМЕЩЕННЫЙ или POST

Я вижу хороший бит помахивания руки на предмет того, как обновить только часть ресурса (например, индикатор состояния) использование REST.

Опции, кажется:

  1. Жалуйтесь, что HTTP не имеет команды PATCH или MODIFY. Однако принятый ответ на HTTP ИЗМЕНЯЕТ глагол для REST? делает хорошее задание показа, почему это не столь хорошая идея, как это могло бы казаться.

  2. Используйте POST с параметрами и определите метод (например, параметр, названный "действием"). Некоторые предложения состоят в том, чтобы указать X-HTTP-Method-Override заголовок с именем самоопределенного метода. Это, кажется, приводит к уродству переключения в рамках реализации на основе того, что Вы пытаетесь сделать и быть открытыми для критики того, чтобы не быть ОСОБЕННО УСПОКОИТЕЛЬНЫМ способом использовать POST. На самом деле проявление этого подхода начинает чувствовать себя подобно интерфейсу типа RPC.

  3. Используйте ПОМЕЩЕННЫЙ для перезаписывания подресурса ресурса, который представляет определенный атрибут (атрибуты) для обновления. На самом деле это - эффективно перезапись подресурса, который кажется в соответствии с духом ПОМЕЩЕННЫХ.

На данном этапе я рассматриваю № 3 как самую разумную опцию.

Действительно ли это - лучшая практика или антишаблон? Есть ли другие опции?

16
задан Community 23 May 2017 в 12:19
поделиться

5 ответов

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

Придерживайтесь 3 и используйте более детализированные подресурсы, а если вам действительно нужно поведение, подобное PATCH - используйте POST. Лично я все равно буду использовать этот подход, даже если PATCH действительно окажется жизнеспособным вариантом.

5
ответ дан 30 November 2019 в 22:24
поделиться

Это нормально для POST и эмуляции PATCH, если он недоступен


Прежде чем объяснять это, вероятно, стоит упомянуть, что в этом нет ничего плохого. использование POST для выполнения общих обновлений (см. здесь ). В частности:

POST становится проблемой только тогда, когда он используется в ситуации, для которой идеально подходит какой-либо другой метод: например, получение информации, которая должна быть представлением некоторого ресурса (GET), полной заменой представления (PUT)

На самом деле мы должны использовать PATCH для небольших обновлений сложных ресурсов, но он не так широко доступен, как хотелось бы. Мы можем эмулировать PATCH, используя дополнительный атрибут как часть POST.

Наш сервис должен быть открыт для сторонних продуктов, таких как SAP, Flex, Silverlight, Excel и т. Д. Это означает, что мы должны использовать технологию наименьшего общего знаменателя - какое-то время мы не могли использовать PUT, потому что во всех клиентских технологиях поддерживались только GET и POST.

Подход, который я выбрал, состоит в том, чтобы использовать "_method = patch" как часть запроса POST. Преимущества:

(a) легко иметь дело с на стороне сервера - мы в основном делаем вид, что PATCH доступен

(b) Он указывает третьим сторонам что мы не нарушаем REST , а работаем над ограничением браузера.Это также согласуется с тем, как несколько лет назад PUT обрабатывался сообществом Rails, поэтому должно быть понятно многим

(c) легко заменить , когда PATCH станет более широко доступным

(d) Это прагматичный ответ на неудобную проблему.

1
ответ дан 30 November 2019 в 22:24
поделиться

Есть два способа просмотреть обновление статуса.

  1. Обновить вещь. Это ПОСТАВИТЬ. Вариант 3

  2. Добавление дополнительной записи журнала в историю вещи. Элемент списка в этой последовательности записей журнала - это текущий статус. Это ПОЧТА. Вариант 2.

Если вы занимаетесь хранилищами данных или функциональным программированием, вы склонны недоверчиво относиться к изменениям статуса и любите ОТПРАВИТЬ новый исторический факт в статичную, неизменяемую вещь. Это действительно требует отделения вещи от истории вещи; приводит к двум таблицам.

В противном случае, вы не возражаете против «обновления», чтобы изменить статус вещи, и вас устраивает PUT. Это не делает различий между вещью и ее историей и хранит все в одной таблице.

Лично я считаю, что все меньше и меньше доверяю изменяемым объектам и PUT (за исключением «исправления ошибок»). (И даже тогда, я думаю, старую вещь можно оставить на месте, а новую добавить со ссылкой на предыдущую версию самого себя.)

Если есть изменение статуса, я думаю, что должен быть журнал статуса или история, и должен быть POST, чтобы добавить новую запись в эту историю. Может быть некоторая оптимизация для отражения «текущего» статуса объекта, к которому это относится, но это всего лишь закулисная оптимизация.

7
ответ дан 30 November 2019 в 22:24
поделиться

HTTP имеет ли команду PATCH. Он определен в разделе 19.6.1.1 RFC 2068 и был обновлен в draft-dusseault-http-patch-16 , который в настоящее время ожидает публикации как RFC .

5
ответ дан 30 November 2019 в 22:24
поделиться

ПАТЧ подходит для патча или diff форматы. До тех пор это вообще не очень полезно.

Что касается вашего решения 2 с настраиваемым методом, будь то в запросе или в заголовках, нет, нет, нет и нет, это ужасно :)

Допустимы только два способа: либо ПОСТАВИТЬ весь ресурс , с измененными вспомогательными данными, или POST для этого ресурса, или PUT для вспомогательного ресурса.

Все зависит от детализации ваших ресурсов и предполагаемых последствий для кеширования.

1
ответ дан 30 November 2019 в 22:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: