Почему запрос HTTP PUT должен содержать представление "целого" состояния и не может быть частичным?
Я понимаю, что это существующее определение PUT - этот вопрос касается причины (причин), почему это будет определено таким образом.
то есть:
Что достигается путем предотвращения частичных PUT?
Почему предотвращение частичных обновлений idempotent считается приемлемой потерей?
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
EDIT: В общем вопросе, почему частичные обновления не могут быть идемпотентными:
Частичное обновление не может быть idempotent вообще, потому что idempotency зависит от семантики типа медиа. IOW, вы можете указать формат, который позволяет использовать идемпотентные исправления, но PATCH не может быть гарантированно идемпотентным для каждого случая. Поскольку семантика метода не может быть функцией типа носителя (по причинам ортогональности), PATCH нужно определить как не-идемпотентный. И PUT (определяется как idempotent) не может использоваться для частичных обновлений.
Потому что, я думаю, это перевело бы в противоречивые "взгляды", когда несколько одновременных клиентов получат доступ к состоянию. Насколько мне известно, семантики "частичного документа" в REST нет, и, вероятно, преимущества добавления этого в силу сложности работы с этой семантикой в контексте concurrency не стоили усилий.
Если документ большой, ничего не мешает вам создавать несколько независимых документов и иметь общий документ, который связывает их вместе. Кроме того, как только все биты и куски собраны, новый документ можно сопоставить на сервере, я думаю.
Итак, учитывая, что можно "обходить" эти "ограничения", я могу понять, почему эта функция не сделала разреза.
Короткий ответ: ACIDity операции 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, так как он может обеспечить с помощью серверной логики согласованность объекта. Однако это требует жесткой связи между данными и сервером.
При полном обновлении документа это очевидно, не зная каких-либо подробностей конкретного API или его ограничений в структуре документа, каков результирующий документ после обновления.
Если известно, что какой-то метод никогда не был частичным обновлением контента, а API, который предоставил только поддерживаемый этот метод, тогда всегда будет ясно, что кто-то, использующий API, должен будет сделать, чтобы изменить документ, чтобы иметь данный набор допустимого содержимого.