PATCH (HTTP)

En informática, el método PATCH es un método de solicitud en el protocolo de transferencia de hipertexto (HTTP) para realizar cambios parciales en un recurso existente. El método PATCH proporciona una entidad que contiene una lista de cambios que se aplicarán al recurso solicitado mediante el identificador uniforme de recursos (URI) de HTTP. La lista de cambios se proporciona en forma de documento PATCH. Si el recurso solicitado no existe, el servidor puede crear el recurso según el tipo de medio y los permisos del documento PATCH. Los cambios descritos en el documento PATCH deben estar bien definidos semánticamente, pero pueden tener un tipo de medio diferente al del recurso que se está parcheando. Se pueden usar lenguajes como XML, JSON para describir los cambios en el documento PATCH.

Historia de PATCH

Según la semántica definida en el protocolo HTTP, los métodos GET, PUT y POST deben usar una representación completa del recurso. El método PUT que se puede usar para la creación o el reemplazo de recursos es idempotente y solo se puede usar para actualizaciones completas. Los formularios de edición utilizados en la aplicación Ruby on Rails convencional deben crear nuevos recursos mediante la aplicación de actualizaciones parciales a un recurso principal. Debido a este requisito, el método PATCH se agregó al protocolo HTTP en 2010.

PONER vs PARCHE vs POST

HTTP es la base de la comunicación de datos para la World Wide Web. Es un protocolo de solicitud-respuesta que ayuda a los usuarios a comunicarse con el servidor para realizar operaciones CRUD. HTTP define una serie de métodos de solicitud como PUT, POST y PATCH para crear o actualizar recursos.

La principal diferencia entre el método PUT y PATCH es que el método PUT utiliza el URI de solicitud para proporcionar una versión modificada del recurso solicitado que reemplaza la versión original del recurso, mientras que el método PATCH proporciona un conjunto de instrucciones para modificar el recurso. Si el documento PATCH es más grande que el tamaño de la nueva versión del recurso enviado por el método PUT, se prefiere el método PUT.

El método POST se puede utilizar para enviar actualizaciones parciales a un recurso. La principal diferencia entre los métodos POST y PATCH es que el método POST se puede usar solo cuando está escrito para admitir aplicaciones o las aplicaciones admiten su semántica, mientras que el método PATCH se puede usar de forma genérica y no requiere soporte de aplicaciones. Si no se conoce el resultado de utilizar el método PATCH, se prefiere el método POST.

Recursos de parches

El método PATCH es atómico. Se aplican todos los cambios especificados por el método PATCH o el servidor no aplica ninguno de los cambios. Hay muchas formas de comprobar si un parche se ha aplicado correctamente. Por ejemplo, la utilidad 'diff' se puede aplicar a la versión anterior y la versión más nueva de un archivo para encontrar las diferencias entre ellos.

Una respuesta PATCH almacenada en caché se considera obsoleta. Solo se puede usar para las solicitudes GET y HEAD que pueden seguir a la solicitud PATCH.

Los encabezados de entidad en el documento PATCH solo se aplican al documento PATCH y no se pueden aplicar al recurso solicitado.

No existe un formato estándar para el documento PATCH y es diferente para diferentes tipos de recursos. El servidor debe verificar si el documento PATCH recibido es apropiado para el recurso solicitado.

Un documento JSON Patch se vería así

[ 
  {  "op" :  "agregar",  "ruta" :  "/recuento",  "valor" :  1  } 
]

"op" representa la operación realizada en el recurso. "ruta" representa el recurso que se está modificando. "valor" representa la cantidad que se agrega al recurso existente. Antes de aplicar los cambios en el documento PATCH, el servidor debe verificar si el documento PATCH recibido es apropiado para el recurso solicitado. Si la solicitud PATCH tiene éxito, devuelve una respuesta 204.

Un documento XML PATCH se vería como

<add  sel= "doc/usuario[@email='xyz@abc.com']"  type= "@dirección" >
Carretera ABC
</añadir>

El elemento <usuario> se encuentra utilizando el atributo 'email'. Se agrega un nuevo atributo 'dirección' con el valor "ABC Road" al elemento <usuario>.

Ejemplo

Un ejemplo simple de solicitud de PATCH

  PARCHE /ejemplo.txt HTTP/1.1
  Anfitrión: www.ejemplo.com
  Tipo de contenido: aplicación/ejemplo
  Si coincide: "c0b42b66e"
  Longitud del contenido: 120

  [cambios]

[cambios] es el documento del parche que contiene todos los cambios que deben realizarse en el recurso ejemplo.txt

Respuesta exitosa de PATCH al archivo de texto existente:

  HTTP/1.1 204 Sin contenido
  Ubicación del contenido: /example.txt
  Etiqueta electrónica: "c0b42b66f"

La respuesta 204 significa que la solicitud se procesó con éxito.

Compensaciones entre PUT y PATCH

El uso del método PUT consume más ancho de banda en comparación con el método PATCH cuando solo es necesario aplicar algunos cambios a un recurso. Pero cuando se utiliza el método PATCH, generalmente implica obtener el recurso del servidor, comparar los archivos originales y nuevos, crear y enviar un archivo diff. En el lado del servidor, el servidor tiene que leer el archivo diff y hacer las modificaciones. Esto implica una gran cantidad de gastos generales en comparación con el método PUT. Por otro lado, el método PUT requiere que se realice un GET antes que PUT y es difícil asegurar que el recurso no se modifique entre las solicitudes GET y PUT.

Precaución

El método PATCH no es "seguro" en el sentido de RFC 2616: puede modificar recursos, no necesariamente limitados a los mencionados en el URI.

El método PATCH no es idempotente. Se puede hacer idempotente mediante el uso de una solicitud condicional. Cuando un cliente realiza una solicitud condicional a un recurso, la solicitud se realiza correctamente solo si el recurso no se ha actualizado desde la última vez que el cliente accedió a ese recurso. Esto también ayuda a prevenir la corrupción del recurso, ya que algunas actualizaciones de un recurso solo se pueden realizar a partir de un punto base determinado.

Manejo de errores

Una solicitud PATCH puede fallar si ocurre alguno de los siguientes errores:

Documento de parche mal formado

El servidor devuelve una respuesta 400 (Solicitud incorrecta) si el documento PATCH no tiene el formato requerido.

Documento de parche no compatible

El servidor devuelve una respuesta 415 (Tipo de medio no admitido) con un encabezado de respuesta Aceptar parche que contiene tipos de medios admitidos cuando el cliente envía un documento de parche en un formato no implementado por el servidor. Esto informa al cliente que el documento PATCH enviado por el cliente no se puede aplicar al recurso solicitado.

Solicitud no procesable

El servidor devuelve una respuesta 422 (Entidad no procesable) cuando el servidor comprende el documento PATCH pero no puede modificar el recurso solicitado porque hace que el recurso se vuelva inválido o porque genera algún otro estado de error.

Recurso no encontrado

El servidor devuelve una respuesta 404 (No encontrado) cuando el documento PATCH no se puede aplicar a un recurso inexistente.

Estado en conflicto

El servidor devuelve una respuesta 409 (Conflicto) cuando el servidor no puede aplicar un parche para el estado actual del recurso.

Modificación en conflicto

El servidor devuelve una respuesta 412 (Error de condición previa) cuando falla la condición previa proporcionada por el cliente mediante el encabezado If-Match o If-Unmodified-Since. Si no se proporciona ninguna condición previa y hay una modificación en conflicto, el servidor devuelve una respuesta 409 (Conflicto).

Modificación concurrente

El servidor devuelve una respuesta 409 (Conflicto) si las solicitudes PATCH a un determinado recurso deben aplicarse en un orden determinado y el servidor no puede manejar solicitudes PATCH simultáneas.

Consideraciones de Seguridad

La solicitud PATCH debe usar mecanismos como solicitudes condicionales que usan Etags y el encabezado de solicitud If-Match para garantizar que los datos no se dañen durante la aplicación de parches. En caso de falla de una solicitud PATCH o falla del canal o un tiempo de espera, el cliente puede usar una solicitud GET para verificar el estado del recurso. El servidor debe asegurarse de que los clientes malintencionados no utilicen el método PATCH para consumir demasiados recursos del servidor.