raulmt
commented
5 years ago El request PATCH, como muchas veces se usa – enviando sólo un subset de los atributos de un recurso con sus nuevos valores, en lugar de todos los atributos del recurso como debiese hacerse en un PUT – va a resultar tan idempotente como PUT. Si lo ejecutas el mismo request dos veces, en ambos casos tendrás el mismo estado final del recurso y la misma respuesta que te entrega el servidor.
Sin embargo, PATCH también es a veces usado de manera que el body no corresponde a un set de propiedades-valores a cambiar, sino que especifica operaciones de actualización sobre el recurso. Ahí es donde un PATCH puede dejar de ser idempotente pues dependerá de la operación que estés especificando. Mira el siguiente ejemplo: tu recurso tiene un arreglo de items, ['a', 'b'], y tú quieres que el ítem 0 y 1 cambien de posición. Si tu PATCH es algo del estilo items[0] = 'b' & items[1] = 'a', ese request será idempotente. Pero si lo que envías es algo del estilo operation: { switch: [0, 1] } entonces el primer request hará lo mismo, pero el segundo volverá al estado anterior => no es idempotente.
Entonces, en un PUT, siempre envías el estado completo, por lo que siempre será idempotente. En un PATCH, dependerá estrictamente de cómo estés representando las mutaciones: si es como nuevos valores para un subset de atributos, entonces será idempotente, pero si especificas operaciones a realizar sobre el recurso, dependerá de la idempotencia de aquéllas operaciones. ¿Me entiendes la idea?
Okhan97
Hola,
En las diapo de la clase de HTTP aparece que PATCH es idempotente, sin embargo a buscar online la mayoria de las fuentes dice lo contrario, ¿cual es la respuesta correcta?
Link: https://softwareengineering.stackexchange.com/questions/260818/why-patch-method-is-not-idempotent