Сейчас 2013 год - вам следует использовать PATCH для частичных обновлений - либо с помощью json-patch (см. http://tools.ietf.org/html/rfc6902 или http://www.mnot.net/blog/2012/09/05/patch), либо в документах xml-patch (см. * 1006). * На мой взгляд, json-patch лучше всего подходит для ваших бизнес-данных.
PATCH с документами JSON / XML patch имеет очень прямолинейную семантику для частичных обновлений. Если вы начнете использовать POST с измененными копиями исходного документа, для частичных обновлений вы вскоре столкнетесь с проблемами, когда вы хотите, чтобы пропущенные значения (или, скорее, нулевые значения) представляли либо «игнорировать это свойство», либо «установите это свойство на «Пустое значение» - и это приводит к кроличьей норе взломанных решений, что в итоге приведет к вашему виду формата патчей.
Более подробный ответ вы можете найти здесь: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html.
Обновление: это RPC?
Что ж, если вы определяете RPC как отправку команд на сервер, то все операции HTTP являются вызовами RPC - независимо от того, получаете ли вы ресурс, ставите новое представление или удаляете его снова - каждая из них состоит из отправки команды ( глагол) GET / PUT / DELETE и т. д. и дополнительная полезная нагрузка. Просто так получилось, что рабочая группа HTTP (или кто бы то ни было) представила новый глагол PATCH, который позволяет клиентам выполнять частичные обновления ресурса.
Если что-либо, кроме отправки полного представления на сервер, считается стилем RPC, то по определению частичные обновления не могут быть RESTful. Можно выбрать такую точку зрения, но люди, стоящие за веб-инфраструктурой, говорят по-другому - и таким образом определили новый глагол для этой цели.
RPC больше относится к туннелированию вызовов методов через HTTP таким способом, который невидим для посредников в сети - например, с использованием SOAP для переноса имен и параметров методов. Эти операции являются «невидимыми», поскольку не существует стандартов, определяющих методы и параметры внутри полезной нагрузки.
Сравните это с PATCH с приложением медиа-типа application / json-patch - цель операции хорошо видна любому посреднику в сети, поскольку глагол PATCH имеет четко определенное значение, а полезная нагрузка закодирована в другом четко определенном общедоступном Доступный формат, принадлежащий общему авторитету в сети (IETF). Итоговый результат - полная видимость для всех и отсутствие секретной семантики конкретного приложения.
REST также относится к «случайному повторному использованию», которое в точности совпадает с PATCH с application / json-patch - повторное использование существующего стандарта вместо изобретения конкретных прикладных протоколов, которые делают более или менее то же самое.