¿Cómo enviar actualizaciones parciales RESTful?

Question

Sam Ruby, autor de "Servicios web RESTful" parece oponerse al 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 deben realizarse las actualizaciones parciales . Como comenté cerca del final 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, aunque Sam se opone al uso indebido de HTTP PUT, tampoco parece abogar por el uso de HTTP PATCH.

¿Cómo se deben enviar actualizaciones parciales RESTful?

Answer 1

Como puede ver en los comentarios en la publicación de blog a la que hizo referencia, no hay una forma acordada de hacer actualizaciones parciales. Si los 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 sobre un tipo de medio de propósito general, cambie su servidor para que acepte ambos formatos.

Agradezca que si el peor pecado que cometió su API REST es abusar de PUT / PATCH, entonces lo está haciendo bastante bien.

Answer 2

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

PATCH con documentos de parches JSON / XML tiene una semántica muy estricta para actualizaciones parciales. Si comienza a utilizar POST, con copias modificadas del documento original, para las actualizaciones parciales pronto se encontrará con problemas en los que desea que los valores faltantes (o, en su lugar, los valores nulos) representen a cualquiera de los " ignorar esta propiedad " o " establezca esta propiedad en el valor vacío " - y eso conduce a un agujero de conejo de soluciones pirateadas que al final resultará en 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 este RPC?

Bueno, si define RPC como enviar comandos a un servidor, entonces todas y cada una de las operaciones HTTP son llamadas RPC, ya sea que OBTENGA un recurso, PONGA una nueva representación o ELIMINE de nuevo, cada una de ellas consiste en un envío de un comando ( verbo) GET / 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 de 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 REST. Uno puede elegir tener este punto de vista, pero las personas que están detrás de la infraestructura web dicen lo contrario, y por lo tanto, han definido un nuevo verbo para este propósito.

RPC es más acerca de las llamadas a métodos de tunelización a través de HTTP de una manera que es invisible para los intermediarios en la web, por ejemplo, usar SOAP para envolver los nombres y parámetros de los métodos. Estas operaciones son " invisibles " ya que no hay 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 medios / 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 útil está codificada en otro público bien definido. Formato disponible propiedad de la autoridad común en la web (IETF). El resultado neto es una 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 PATCH con application / json-patch es: reutilizar un estándar existente en lugar de inventar protocolos específicos de la aplicación que hagan más o menos lo mismo.

Answer 3

En lugar de elaborar un tipo de medio de actualización parcial y utilizar el método PATCH aún no estándar, puede asignar a sus partes de sus recursos su propio URI.

Answer 4

HTTP PATCH ahora tiene un RFC - HTTP PATCH RFC