Как поддерживать частичные обновления (патч) в REST

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

HTTP изменить глагол для отдыха?

как отправить RESTful частичный предложите любое действительное решение для этого.

26
openrasta partial patch rest

3 ответов

согласно RFC5789 (http://tools.ietf.org/html/rfc5789), это именно то, что патч для:

несколько приложений, расширяющих протокол передачи гипертекста (HTTP) требуется функция для частичной модификации ресурсов. Существование Метод HTTP PUT позволяет только полную замену документа. Это предложение добавляет новый метод HTTP, PATCH, для изменения существующего Ресурс HTTP.

различие между патчем и PUT описывается как:

разница между запросами PUT и PATCH отражается в способ обработки сервером вложенной сущности для изменения ресурса идентифицируется по запросу-URI. В запросе PUT вложенный объект считается измененной версией ресурса, хранящегося на исходный сервер и клиент запрашивают сохраненную версию быть заменен. С PATCH, однако, закрытый объект содержит набор инструкции, описывающие, как ресурс, в настоящее время проживающий на сервер origin должен быть изменен для создания новой версии.

ограничения POST также описаны:

метод PUT уже определен для перезаписи ресурса с полным новым телом и не может быть повторно использован для частичных изменений. В противном случае прокси и кэши, а также клиенты и серверы могут получить смущенный результатом операция. POST уже используется, но без широкой совместимости (для одного, нет стандартного способа открыть поддержка формата патч) [...]

Я бы предложил вам прочитать RFC и принять собственное решение, но мне кажется, что это довольно четкие запросы патча должны обрабатываться как частичные обновления. (NB они не идемпотентны, в отличие от PUT.)

EDIT: как отметил Евгений в комментариях, хотя запросы патча "neither safe nor idempotent as defined by [RFC2616]", их можно сделать Итак:

запрос исправления может быть выдан таким образом, чтобы быть идемпотентным, что также помогает предотвратить плохие результаты от столкновений между двумя Запросы исправлений на том же ресурсе в аналогичные временные рамки. Столкновения из нескольких запросов исправлений могут быть более опасными, чем Поместите коллизии, потому что некоторые форматы патчей должны работать из известная базовая точка, иначе они испортят ресурс. Клиенты использование такого приложения patch должно использовать условный запрос таким образом, запрос завершится ошибкой, если ресурс был обновлен с момента последнего обращения клиента к ресурсу. Например, клиент может использовать сильный ETag [RFC2616] в заголовке If-Match на патче запрос.

91

вы должны использовать метод PATCH, как описано в RFC-7386 "JSON merge PATCH".

например. если вы хотите изменить значение " a "и удалить" f " в ресурсе, например:

   {
     "a": "b",
     "c": {
       "d": "e",
       "f": "g"
     }
   }

вы можете достичь этого, отправив:

       PATCH /target HTTP/1.1
       Host: example.org
       Content-Type: application/merge-patch+json

       {
         "a":"z",
         "c": {
           "f": null
         }
       }
0

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

В общем, сообщение будет правильным подходом, но вы можете разделить свой ресурс на несколько ресурсов и изменить их вместо этого.

[отредактировано для ясности, так как некоторые не читают комментарии]

-16