Как отправить частичные обновления RESTful?

Ответ 1

Как вы можете видеть из комментариев в блоге, на который вы ссылаетесь, нет согласованного способа частичного обновления. Если тяжеловесы, такие как Сэм Руби, Джо Грегарио, Марк Ноттингем, Марк Пилигрим, Билл де Хора и т.д., Не могут прийти к соглашению, какая надежда у нас есть.

Насколько я понимаю, я бы не стал слишком беспокоиться. Создайте тип частичного обновления, который работает для вас, используйте PATCH, чтобы указать ваше намерение, и когда соглашение наконец будет достигнуто на носителе общего назначения, измените ваш сервер, чтобы принять оба формата.

Будь благодарен, что если худший грех, который совершает ваш REST api, злоупотребляет PUT/PATCH, тогда вы делаете очень хорошо.

Ответ 2

Сейчас в 2013 году вы должны использовать PATCH для частичных обновлений - либо с помощью json-patch (см. http://tools.ietf.org/html/rfc6902, либо http://www.mnot.net/blog/2012/09/05/patch) или документы xml-patch (см. http://tools.ietf.org/html/rfc7351). На мой взгляд, json-patch лучше всего подходит для ваших бизнес-данных.

PATCH с документами патчей JSON/XML имеет очень простую семантику для частичных обновлений. Если вы начнете использовать POST с измененными копиями исходного документа, для частичных обновлений вы в скором времени столкнетесь с проблемами, когда вы хотите, чтобы отсутствующие значения (или, вернее, нулевые значения) представляли либо "игнорировать это свойство", либо "устанавливали это свойство в пустое значение" - и это ведет к кроличьей дыре взломанных решений, что в итоге приведет к вашему формату патча.

Здесь вы можете найти более подробный ответ: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html.

Обновление: этот RPC?

Ну, если вы определяете RPC как отправку команд на сервер, то любые и все HTTP-операции - это вызовы RPC - вы хотите получить ресурс, PUT новое представление или DELETE его снова - каждый из них состоит из отправки команды ( глагол) GET/PUT/DELETE и т.д. и дополнительную полезную нагрузку. Просто случается, что рабочая группа HTTP (или кто когда-либо еще) ввела новый глагол PATCH, который позволяет клиентам делать частичные обновления ресурса.

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

RPC больше связан с вызовами туннелирования через HTTP таким образом, который невидим для посредников в Интернете - например, используя SOAP для переноса имен методов и параметров. Эти операции являются "невидимыми", поскольку нет стандартов, определяющих методы и параметры внутри полезной нагрузки.

Сравните это с PATCH с приложением типа мультимедиа /json -patch - намерение операции четко видно любому посреднику в сети, поскольку глагол PATCH имеет четко определенное значение, а полезная нагрузка кодируется в другой четко определенной публике доступный формат, принадлежащий общему авторитету в Интернете (IETF). Конечный результат - полная видимость для всех и не секретная семантика, специфичная для приложения.

REST также относится к "последовательному повторному использованию", что является именно тем, что PATCH с приложением /json -patch - повторное использование существующего стандарта вместо того, чтобы придумывать конкретные протоколы приложений, которые делают более или менее одинаковые.

Ответ 3

Вместо домашнего пивоварения частичного типа носителя обновления и использования еще нестандартного метода PATCH вы можете предоставить частям своих ресурсов свой собственный URI.

Ответ 4

HTTP PATCH теперь имеет RFC - HTTP PATCH RFC