Каково оправдание запрета частичного PUT?

Question

Почему запрос HTTP PUT должен содержать представление «целого» состояния и не может быть просто частичным?

Я понимаю, что это существующее определение PUT - этот вопрос о причине (ах), почему он будет определен таким образом.

т.е:

Что получается, предотвращая частичные ПУТ?

Почему предотвращение частичных обновлений идемпотента считается приемлемой потерей?

Answer 1

PUT означает, что спецификация HTTP определяет это значение. Клиенты и серверы не могут изменить это значение. Если клиенты или серверы используют PUT таким образом, который противоречит его определению, может произойти, по крайней мере, следующее:

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

Если вы хотите выполнить частичное обновление, используйте PATCH или POST для подресурса и верните 303 См. Другое для основного ресурса, например

POST /account/445/owner/address
Content-Type: application/x-www-form-urlencoded

street=MyWay&zip=22222&city=Manchaster


303 See Other
Location: /account/445

РЕДАКТИРОВАТЬ: На общий вопрос, почему частичные обновления не могут быть идемпотентными:

Частичное обновление вообще не может быть идемпотентом, потому что идемпотентность зависит от семантики типа носителя. Таким образом, вы можете указать формат, который допускает идемпотентные пластыри, но нельзя гарантировать, что PATCH будет идемпотентным для каждого случая. Поскольку семантика метода не может быть функцией типа носителя (по причинам ортогональности), PATCH необходимо определить как неидемпотентный. И PUT (определяемый как идемпотент) не может использоваться для частичных обновлений.

Answer 2

При полном обновлении документа становится очевидным, не зная каких-либо подробностей конкретного API или его ограничений по структуре документа, каким будет итоговый документ после обновления.

Если известно, что определенный метод никогда не будет частичным обновлением контента, и API, который кто-то предоставил, поддерживает только этот метод, то всегда будет понятно, что кто-то, использующий API, должен будет сделать, чтобы изменить документ для получения заданного набор допустимого содержимого.

Answer 3

Краткий ответ: КИСЛОТНОСТЬ операции PUT и состояние обновленного объекта.

Длинный ответ:

RFC 2616: пункт 2.5, «метод POST запрашивает, чтобы заключенный объект был принят в качестве нового подчиненного запрошенного URL-адреса». Параграф 2.6, «Метод PUT запрашивает, чтобы закрытая сущность была сохранена по указанному URL».

Поскольку каждый раз, когда вы выполняете POST, семантика заключается в создании нового экземпляра сущности на сервере, POST представляет собой операцию ACID. Но повторение одного и того же POST дважды с одним и тем же объектом в теле может привести к разным результатам, если, например, серверу не хватило места для хранения нового экземпляра, который необходимо создать - таким образом, POST не идемпотентен.

С другой стороны, PUT имеет семантику обновления существующего объекта. Нет гарантии, что даже если частичное обновление является идемпотентным, оно также является ACID и приводит к согласованному и действительному состоянию объекта. Таким образом, для обеспечения ACIDity, семантика PUT требует отправки полного объекта. Даже если это не было целью авторов протокола HTTP, идемпотентность запроса PUT может возникнуть как побочный эффект от попытки применить ACID.

Конечно, если HTTP-сервер хорошо знает семантику сущностей, он может разрешать частичные PUT, поскольку он может посредством логики на стороне сервера обеспечить согласованность сущности. Однако для этого требуется тесная связь между данными и сервером.

Answer 4

Потому что, я думаю, это перешло бы в противоречивые «представления», когда несколько одновременных клиентов получают доступ к состоянию. Насколько я могу судить, в REST нет семантики «частичного документа», и, вероятно, преимущества добавления этого перед сложностью работы с этой семантикой в ​​контексте параллелизма не стоили усилий.

Если документ большой, ничто не мешает вам создавать несколько независимых документов и иметь всеобъемлющий документ, который связывает их вместе. Кроме того, как только все кусочки будут собраны, я думаю, на сервере можно будет сопоставить новый документ.

Итак, учитывая, что можно «обойти» эти «ограничения», я могу понять, почему эта функция не сработала.