restful - Cómo soportar actualizaciones parciales(PARCHE) en REST

restful patch

Question

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

Verbo HTTP MODIFICAR para REST?

¿Cómo enviar actualizaciones parciales RESTful?

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 alguna solución válida para esto.

Answer 1

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 un recurso como:

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

Puedes lograr esto enviando:

 PATCH /target HTTP/1.1
Host: example.org
Content-Type: application/merge-patch+json
{
"a":"z",
"c": {
"f": null
}
}

Answer 2

PATCH se utilizará con un formato de parche, solo para parchear a nivel de documento (también conocido como un diferencial en la representación real). Su uso para otros propósitos es dudoso y discutible, y no está claro que el método haya sido diseñado para usos que no sean de tipo multimedia.

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

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

Answer 3

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

Varias aplicaciones que extienden el Protocolo de transferencia de hipertexto (HTTP) requieren una función para realizar una modificación parcial de los recursos. El método HTTP PUT existente solo permite una sustitución completa de un documento. Esta propuesta agrega un nuevo método HTTP, PATCH, para modificar un recurso HTTP existente.

La distinción entre PATCH y PUT se describe como:

La diferencia entre las solicitudes PUT y PATCH se refleja en la forma en que el servidor procesa la entidad adjunta para modificar el recurso identificado por el URI de solicitud. 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 describen cómo un recurso que actualmente reside en el servidor de origen debe modificarse 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 nuevo cuerpo completo y no se puede reutilizar para hacer cambios parciales. De lo contrario, los servidores proxy y los cachés, e incluso los clientes y servidores, pueden confundirse con el resultado de la operación. POST ya está en uso, pero sin una amplia interoperabilidad (por un lado, no hay una forma estándar de descubrir el soporte de formato de parche) [...]

Le sugeriría que leyera el RFC y se decidiera, pero para mí esto parece bastante claro: las solicitudes de PATCH deben procesarse como actualizaciones parciales. (NB NO son idempotentes, a diferencia de PUT.)

EDICIÓN: como lo señaló Eugene en los comentarios, aunque las solicitudes de PATCH "neither safe nor idempotent as defined by [RFC2616]" , pueden hacerse así:

Se puede emitir una solicitud de PARCHE de forma tal que sea idempotente, lo que también ayuda a prevenir los malos resultados de las colisiones entre dos solicitudes de PARCHE en el mismo recurso en un marco de tiempo similar. Las colisiones de múltiples solicitudes de PATCH pueden ser más peligrosas que las colisiones PUT porque algunos formatos de parches necesitan operar desde un punto base conocido o bien dañarán el recurso. Los clientes que usan este tipo de aplicación de parche DEBERÍAN utilizar una solicitud condicional tal que la solicitud fallará si el recurso se ha actualizado desde la última vez que el cliente accedió al recurso. Por ejemplo, el cliente puede usar una ETag fuerte [RFC2616] en un encabezado If-Match en la solicitud PATCH.