En informática, el método PATCH es un método de solicitud en HTTP para realizar cambios parciales en un recurso existente. [1] El método PATCH proporciona una entidad que contiene una lista de cambios que se aplicarán al recurso solicitado utilizando el Identificador uniforme de recursos (URI) de HTTP. [1] La lista de cambios se proporciona en forma de un documento PATCH. [1] Si el recurso solicitado no existe, el servidor puede crear el recurso según el tipo de medio y los permisos del documento PATCH. [1] Los cambios descritos en el documento PATCH deben estar semánticamente bien definidos, pero pueden tener un tipo de medio diferente al del recurso que se está parcheando. [2] Se pueden utilizar lenguajes como XML o JSON para describir los cambios en el documento PATCH.
Según la semántica definida en el protocolo HTTP , los métodos GET , PUT y POST deben utilizar una representación completa del recurso. El método PUT, que se puede utilizar para la creación o el reemplazo de recursos, es idempotente y solo se puede utilizar para actualizaciones completas. Los formularios de edición utilizados en aplicaciones Ruby on Rails convencionales necesitan 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. [3] [4]
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. [5]
La principal diferencia entre el método PUT y el método PATCH es que el método PUT utiliza la URI de la 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. [1]
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 utilizar solo cuando está escrito para admitir aplicaciones o las aplicaciones admiten su semántica, mientras que el método PATCH se puede utilizar de forma genérica y no requiere el soporte de la aplicación. Si no se conoce el resultado del uso del método PATCH, se prefiere el método POST. [1] [6]
El método PATCH es atómico . [1] O bien se aplican todos los cambios especificados por el método PATCH o bien el servidor no aplica ninguno de los cambios. [1] Hay muchas formas de comprobar si un parche se aplicó correctamente. Por ejemplo, la utilidad 'diff' se puede aplicar a la versión anterior y a la versión más reciente de un archivo para encontrar las diferencias entre ellas. [1]
Una respuesta PATCH almacenada en caché se considera obsoleta. Solo se puede utilizar para las solicitudes GET y HEAD que puedan seguir a la solicitud PATCH. [1]
Los encabezados de entidad en el documento PATCH solo son aplicables al documento PATCH y no se pueden aplicar al recurso solicitado. [1]
No existe un formato estándar para el documento PATCH y varía según el tipo de recurso. El servidor debe comprobar si el documento PATCH recibido es adecuado para el recurso solicitado. [1]
Un documento de parche JSON se vería así
[ { "op" : "add" , "path" : "/count" , "value" : 1 } ] "op" representa la operación realizada sobre el recurso. "path" representa el recurso que se está modificando. "value" representa la cantidad que se está añadiendo al recurso existente. [7] Antes de aplicar los cambios en el documento PATCH, el servidor tiene que comprobar si el documento PATCH recibido es adecuado para el recurso solicitado. Si la solicitud PATCH tiene éxito, devuelve una respuesta 204. [8]
Un documento XML PATCH se vería así
<add sel= "doc/usuario[@email="[email protected]"]" type= "@address" > Calle
ABC </add> El elemento <user> se localiza mediante el atributo 'email'. Se añade un nuevo atributo 'address' con el valor "ABC Road" al elemento <user>. [9]
Un ejemplo sencillo de solicitud PATCH
PATCH /example.txt HTTP/1.1 Anfitrión: www.example.com Tipo de contenido: aplicación/ejemplo Si coincide: "c0b42b66e" Contenido-Longitud: 120 [ Cambios : el documento del parche que contiene todos los cambios que deben realizarse en el recurso example.txt]Respuesta PATCH exitosa al archivo de texto existente:
HTTP/1.1 204 No Content Ubicación del contenido: /ejemplo.txt Etiqueta electrónica : "dd541480"La respuesta 204 significa que la solicitud se procesó con éxito. [10]
El uso del método PUT consume más ancho de banda en comparación con el método PATCH cuando solo se necesitan aplicar unos pocos cambios a un recurso. [ cita requerida ] 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 realizar las modificaciones. Esto implica una gran sobrecarga en comparación con el método PUT. [11] Por otro lado, el método PUT requiere que se realice un GET antes del PUT y es difícil garantizar que el recurso no se modifique entre las solicitudes GET y PUT.
El método PATCH no es "seguro" en el sentido del RFC 2616: puede modificar recursos, no necesariamente limitados a aquellos mencionados en la URI . [1]
El método PATCH no es idempotente . Puede volverse idempotente mediante una solicitud condicional. [1] Cuando un cliente realiza una solicitud condicional a un recurso, la solicitud tiene éxito 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. [1]
Una solicitud PATCH puede fallar si ocurre alguno de los siguientes errores:
El servidor devuelve una respuesta 400 (solicitud incorrecta) si el documento PATCH no tiene el formato requerido. [1]
El servidor devuelve una respuesta 415 ( Tipo de medio no compatible ) con un encabezado de respuesta Accept-Patch que contiene los tipos de medios compatibles 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. [1]
El servidor devuelve una respuesta 422 (entidad no procesable) cuando comprende el documento PATCH pero no puede modificar el recurso solicitado ya sea porque esto hace que el recurso se vuelva inválido o genera algún otro estado de error. [1]
El servidor devuelve una respuesta 404 (No encontrado) cuando el documento PATCH no se puede aplicar a un recurso inexistente. [1]
El servidor devuelve una respuesta 409 (Conflicto) cuando no puede aplicar un parche para el estado actual del recurso. [1]
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 conflictiva, el servidor devuelve una respuesta 409 (Conflicto). [1]
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. [1]
La solicitud PATCH debe utilizar mecanismos como solicitudes condicionales que utilizan etiquetas E y el encabezado de solicitud If-Match para garantizar que los datos no se corrompen durante la aplicación del parche. [1] En caso de una falla de una solicitud PATCH o una falla del canal o un tiempo de espera, el cliente puede utilizar una solicitud GET para verificar el estado del recurso. [1] El servidor debe asegurarse de que los clientes maliciosos no utilicen el método PATCH para consumir recursos excesivos del servidor. [1]
{{cite journal}}: Requiere citar revista |journal=( ayuda )