Cómo soportar Actualizaciones parciales (PARCHE) en REST

Question

Cómo soportar Actualizaciones parciales (PARCHE) en REST

Quiero implementar las actualizaciones parciales para mi recurso ya que tengo un recurso grande y quiero actualizar la información parcial de él.He pasado por los siguientes enlaces pero no
capaz de averiguar si utilizar HTTP POST o PATCH métodos.

HTTP MODIFICAR verbo para REST?

Cómo enviar RESTful parcial ¿actualizaciones?

Http://jacobian.org/writing/rest-worst-practices /

Https://github.com/archiloque/rest-client/issues/79

Http://tools.ietf.org/html/draft-dusseault-http-patch-16

Http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-06.html

Http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch

Http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates

Https://github.com/dharmafly/jsonpatch.js

Por favor sugiera cualquier solución válida para esto.

26

rest patch partial openrasta

Author: Community, 2011-11-15

Source

3 answers

Debe usar el método PATCH como se describe en RFC-7386 "json merge PATCH".

Por ejemplo, si desea cambiar el valor de "a" y eliminar "f" en el recurso como:

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

Puedes conseguir esto enviando:

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

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

0

Author: TechnoPriest,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-11-09 09:03:54

El PARCHE se debe usar con un formato de parche, solo para parches a nivel de documento (también conocido como una diferencia en la representación real). Su uso para otros fines es dudoso y discutible, y no está claro que el método fue diseñado para usos no mediáticos.

En general, una PUBLICACIÓN será el enfoque correcto, pero es posible que desee dividir su recurso en varios recursos y modificarlos en su lugar.

[Editado para mayor claridad, ya que algunos no leen comentarios]

-16

Author: SerialSeb,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-10-31 13:55:22

score 91 · Accepted Answer

Según RFC5789 ( http://tools.ietf.org/html/rfc5789 ), esto es precisamente para lo que es el PARCHE:

Varias aplicaciones que extienden el Protocolo de Transferencia de Hipertexto (HTTP) requerir una característica para realizar una modificación parcial de recursos. El actual El método HTTP PUT solo permite un reemplazo completo de un documento. Esta propuesta añade un nuevo método HTTP, PATCH, para modificar un Recurso HTTP.

La distinción entre PATCH y PUT es descrito como:

La diferencia entre las peticiones PUT y PATCH se refleja en el forma en que el servidor procesa la entidad cerrada para modificar el recurso identificado por la Solicitud-URI. En una solicitud PUT, la entidad se considera una versión modificada del recurso almacenado en el servidor de origen, y el cliente está solicitando que la versión almacenada ser reemplazado. Con PATCH, sin embargo, la entidad cerrada contiene un conjunto de instrucciones describiendo cómo un recurso que reside actualmente en el el servidor de origen debe ser modificado para producir una nueva versión.

Las limitaciones de POST también se describen:

El método PUT ya está definido para sobrescribir un recurso con un cuerpo completamente nuevo, y no puede ser reutilizado para hacer cambios parciales. De lo contrario, los proxies y cachés, e incluso los clientes y servidores, pueden obtener confundido en cuanto al resultado de la operación. PUESTO ya se utiliza, pero sin amplia interoperabilidad (por un lado, no hay una forma estándar de discover patch format support) [...]

Le sugeriría que lea el RFC y tome su propia decisión, pero para mí esto parece bastante claro: las solicitudes de PARCHES deben procesarse como actualizaciones parciales. (NOTA: NO son idempotentes, a diferencia de PUT.)

EDITAR: como señaló Eugene en los comentarios, aunque las solicitudes de PARCHES son "neither safe nor idempotent as defined by [RFC2616]", se pueden hacer así:

Una solicitud de PARCHE se puede emitir de tal manera que sea idempotent, que también ayuda a prevenir los malos resultados de las colisiones entre dos PATCH requests on the same resource in a similar time frame. Las colisiones de múltiples solicitudes de PARCHES pueden ser más peligrosas que Colisiones porque algunos formatos de parche necesitan operar desde un punto base conocido o de lo contrario corromperán el recurso. Cliente el uso de este tipo de aplicación de parches DEBE usar una solicitud condicional tal que la solicitud fallará si el recurso ha sido actualizar desde la última vez que el cliente accedió al recurso. Por ejemplo, el cliente puede usar un ETag fuerte [RFC2616] en un encabezado If-Match en el PARCHE solicitud.