Cómo admitir las actualizaciones parciales (PATCH) en RESTO

Question

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 para averiguar si usar los métodos HTTP POST o PATCH.

HTTP MODIFY verb for REST?

How to submit RESTful partial updates?

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

Para sugerir una solución válida para esto.

Answer 1

De acuerdo con RFC5789 (http://tools.ietf.org/html/rfc5789), esto es precisamente lo parche es para:

Varias aplicaciones de la prórroga del Protocolo de transferencia de hipertexto (HTTP) requieren una función para realizar modificaciones parciales de recursos. El método HTTP PUT existente solo permite el reemplazo completo de un documento. Esta propuesta agrega un nuevo método HTTP, PATCH, para modificar un recurso HTTP existente.

La distinción entre el parche y PUT se describe como:

La diferencia entre las peticiones PUT y el parche se refleja en la forma el servidor procesa la entidad adjunta para modificar el recurso identificado por el Request-URI. En una solicitud PUT, la entidad incluida se considera una versión modificada del recurso almacenado en el servidor de origen , y el cliente solicita que se reemplace la versión almacenada . Sin embargo, con PATCH, la entidad adjunta contiene un conjunto de instrucciones que describe cómo se debe modificar un recurso que actualmente reside en el servidor de origen para producir una nueva versión.También se describen

Las limitaciones de POST:

El método PUT ya está definido para sobrescribir un recurso con un nuevo cuerpo completo, y no se puede volver a utilizar para hacer cambios parciales. De lo contrario, los servidores proxy y las memorias caché, e incluso los clientes y servidores, pueden obtener confundidos en cuanto al resultado de la operación. POSTAL ya se utiliza, pero sin amplia interoperabilidad (por mi parte, no hay manera estándar de descubrir el soporte de formato de parche) [...]

que sugeriría leer el RFC y hacer su propia decisión, pero para mí esto parece bastante claro, las solicitudes de PATCH deben procesarse como actualizaciones parciales. (Nota: No son idempotente, a diferencia de PUT.)

EDIT: como señala Eugene en los comentarios, a pesar de las solicitudes de parche se "neither safe nor idempotent as defined by [RFC2616]", que se pueden hacer de manera:

Una solicitud parche puede ser emitido de tal manera que sea idempotente, , que también ayuda a evitar malos resultados de colisiones entre dos solicitudes de PATCH en el mismo recurso en un marco de tiempo similar. Las colisiones de varias solicitudes de PATCH pueden ser más peligrosas que colisiones PUT porque algunos formatos de parches deben operar desde un punto base conocido o estropearán el recurso. Los clientes que utilizan este tipo de aplicación de parche DEBERÍAN usar una solicitud condicional de modo que la solicitud fallará si el recurso se ha actualizado desde que el cliente accedió por última vez al recurso. Por ejemplo, el cliente puede usar un ETag fuerte [RFC2616] en un encabezado If-Match en la solicitud PATCH .

Answer 2

PATCH se debe utilizar con un formato de parche, solo para el parche a nivel de documento (también conocido como un diff en la representación real). Su uso para otros fines es dudoso y discutible, y no está claro si el método fue diseñado para usos no relacionados con los medios.

En general, un POST será el enfoque correcto, pero es posible que desee dividir su recurso en varios recursos y modificarlos en su lugar.

[Editado por claridad, ya que algunos no leen los comentarios]

Answer 3

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

E.g. si desea cambiar el valor de "a" y la eliminación de "f" en el recurso como:

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

Puede achive esto enviando:

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

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