explained - ¿Cómo enviar actualizaciones parciales RESTful?

rest post example

Question

Sam Ruby, autor de "RESTful Web Services" parece estar en contra del uso de HTTP PUT para actualizaciones parciales: http://intertwingly.net/blog/2008/02/15/Embrace-Extend-then-Innovate

Lo que no está claro es cómo deberían tener lugar las actualizaciones parciales. Como comenté cerca de la parte inferior de su blog, no está claro cómo usar HTTP PATCH es mejor que usar un "documento de parche" contra HTTP PUT.

Vale la pena señalar que, si bien Sam se opone al uso indebido de HTTP PUT, tampoco parece abogar por el uso de HTTP PATCH.

¿Cómo debería uno enviar actualizaciones parciales RESTful?

Answer 1

HTTP PATCH ahora tiene un RFC - HTTP PATCH RFC

Answer 2

En lugar de crear un tipo de medio de actualización parcial y utilizar el método PATCH, que aún no es estándar, podría dar a sus partes su propio URI.

Answer 3

Como puede ver en los comentarios en la publicación de blog a la que se hace referencia, no existe una forma acordada de realizar actualizaciones parciales. Si pesos pesados ​​como Sam Ruby, Joe Gregario, Mark Nottingham, Mark Pilgrim, Bill de hóra, etc. no pueden llegar a un acuerdo, qué esperanza tenemos.

En lo que a mí respecta, no me preocuparía demasiado. Cree un tipo de medio de actualización parcial que funcione para usted, use PATCH para indicar su intención y cuando finalmente se llegue a un acuerdo en un tipo de medio de uso general, cambie su servidor para aceptar ambos formatos.

Se agradecido de que si el peor pecado que comete tu REST api es abusar de PUT / PATCH, entonces lo estás haciendo bastante bien.

Answer 4

Ahora es el año 2013, debe usar PATCH para actualizaciones parciales, ya sea usando json-patch (vea http://tools.ietf.org/html/rfc6902 o http://www.mnot.net/blog/2012/09 / 05 / patch ) o los documentos xml-patch (vea http://tools.ietf.org/html/rfc7351 ). En mi opinión, sin embargo, json-patch es la mejor opción para su clase de datos comerciales.

PATCH con documentos de parche JSON / XML tiene una semántica directa muy estrecha para actualizaciones parciales. Si comienza a usar POST, con copias modificadas del documento original, para actualizaciones parciales, pronto se encontrará con problemas en los que desea valores perdidos (o, mejor dicho, valores nulos) para representar "ignorar esta propiedad" o "establecer esta propiedad en el valor vacío "- y eso lleva a un agujero de conejo de soluciones pirateadas que al final dará como resultado su propio tipo de formato de parche.

Puede encontrar una respuesta más detallada aquí: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html .

Actualización: ¿Es esto RPC?

Bueno, si define RPC como enviar comandos a un servidor, todas y cada una de las operaciones HTTP son llamadas RPC, ya sea que OBTENGA un recurso, PONGA una nueva representación o lo BORRUE nuevamente, cada una de ellas consiste en enviar un comando (verbo) OBTENER / PUT / DELETE, etc. y una carga útil opcional. Simplemente sucede que el grupo de trabajo HTTP (o quien sea) ha introducido un nuevo verbo PATCH que permite a los clientes realizar actualizaciones parciales a un recurso.

Si algo más que enviar la representación completa al servidor se considera estilo RPC, entonces, por definición, las actualizaciones parciales no pueden ser RESTful. Uno puede elegir tener este punto de vista, pero las personas detrás de la infraestructura web dicen de manera diferente, y así se ha definido un nuevo verbo para este propósito.

RPC se trata más de llamadas de método de túnel a través de HTTP de una manera que es invisible para los intermediarios en la web, por ejemplo, utilizando SOAP para ajustar los nombres y parámetros de los métodos. Estas operaciones son "invisibles" ya que no existen estándares que definan los métodos y parámetros dentro de la carga útil.

Compare esto con PATCH con la aplicación de tipo de medio / json-patch: la intención de la operación es claramente visible para cualquier intermediario en la web ya que el verbo PATCH tiene un significado bien definido y la carga está codificada en otro formato públicamente disponible bien definido. por autoridad común en la web (IETF). El resultado neto es la visibilidad total para todos y ninguna semántica secreta específica de la aplicación.

REST también se trata de "reutilización fortuita", que es exactamente lo que es PATCH con application / json-patch: reutilización de un estándar existente en lugar de inventar protocolos específicos de aplicación que hacen más o menos lo mismo.