Каково выравнивание позади запрещения неравнодушного ПОМЕЩЕННЫЙ?
Почему HTTP ПОМЕЩАЕТ запрос, должны содержать представление 'целого' состояния и не может просто быть частичное?
Я понимаю, что это - существующее определение ПОМЕЩЕННЫХ - этот вопрос о причине (причинах), почему это было бы определено тот путь.
т.е.:
То, что получено путем предотвращения неравнодушный, ПОМЕЩАЕТ?
Почему предотвращение идемпотентных частичных обновлений считали приемлемой потерей?
3 ответа
PUT означает то, что определено в спецификации HTTP. Клиенты и серверы не могут изменить это значение. Если клиенты или серверы используют PUT таким образом, что это противоречит его определению, может произойти по крайней мере следующее:
Put по определению является идемпотентным. Это означает, что клиент (или посредник!) может повторить PUT любое количество раз и быть уверенным, что эффект будет одинаковым. Предположим, посредник получает запрос PUT от клиента. Когда он пересылает запрос на сервер, возникает сетевая проблема. Посредник по определению знает, что он может повторять PUT до тех пор, пока не добьется успеха. Если сервер использует PUT неидемпотентным способом, эти потенциальные многократные вызовы будут иметь нежелательный эффект.
Если вы хотите сделать частичное обновление, используйте PATCH или POST на под-ресурсе и верните 303 See Other на "главный" ресурс, например
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: По поводу общего вопроса, почему частичные обновления не могут быть идемпотентными:
Частичное обновление не может быть идемпотентным в целом, потому что идемпотентность зависит от семантики медиа-типа. То есть, вы можете определить формат, который позволяет использовать идемпотентные патчи, но нельзя гарантировать, что PATCH будет идемпотентным для каждого случая. Поскольку семантика метода не может быть функцией типа носителя (по причинам ортогональности), PATCH должен быть определен как неидемпотентный. А PUT (будучи определенным как идемпотентный) не может быть использован для частичных обновлений.
Потому что, я полагаю, это было бы преобразовано в несовместимые "представления", когда к состоянию обращаются несколько одновременных клиентов. Насколько я могу судить, в REST нет семантики «частичного документа», и, вероятно, преимущества добавления этого, несмотря на сложность работы с этой семантикой в контексте параллелизма, не стоили усилий.
Если документ большой, ничто не мешает вам создавать несколько независимых документов и иметь общий документ, связывающий их вместе. Кроме того, как только все детали будут собраны, новый документ можно будет сопоставить на сервере, я думаю.
Итак, учитывая, что можно «обойти» эти «ограничения», я могу понять, почему эта функция не прошла.
Краткий ответ: КИСЛОТНОСТЬ операции 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, поскольку он может гарантировать с помощью логики на стороне сервера согласованность объекта. Однако это требует тесной связи между данными и сервером.