PARCHE (HTTP)
| HTTP |
|---|
 |
| Métodos de solicitud |
| Campos de encabezado |
| Códigos de estado de respuesta |
| Métodos de control de acceso de seguridad |
| Vulnerabilidades de seguridad |
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.
Historia de 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]
PUT vs PATCH 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. [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]
Recursos de parcheo
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]
Ejemplo
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]
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 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.
Precaución
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]
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. [1]
Documento de parche no compatible
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]
Solicitud no procesable
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]
Recurso no encontrado
El servidor devuelve una respuesta 404 (No encontrado) cuando el documento PATCH no se puede aplicar a un recurso inexistente. [1]
Estado en conflicto
El servidor devuelve una respuesta 409 (Conflicto) cuando no puede aplicar un parche para el estado actual del recurso. [1]
Modificación conflictiva
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]
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. [1]
Consideraciones de seguridad
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]
Referencias
- ^ abcdefghijklmnopqrstu vwxy Dusseault, L.; Snell, J. (2010). "Método PATCH para HTTP". doi :10.17487/RFC5789. S2CID 42062521 . Consultado el 12 de septiembre de 2015 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "No parchees como un idiota". No parchees como un idiota . 14 de febrero de 2014. Consultado el 16 de septiembre de 2015 .
- ^ RFC 5789
- ^ "Historia de PATCH". weblog.rubyonrails.org . Consultado el 25 de septiembre de 2015 .
- ^ "Protocolo de transferencia de hipertexto - HTTP/1.1" . Consultado el 13 de septiembre de 2015 .
- ^ "Por qué PATCH es bueno para su API HTTP". Por qué PATCH es bueno para su API HTTP . Consultado el 16 de septiembre de 2015 .
- ^ "Parche JSON - draft-ietf-appsawg-json-patch-08". Ietf Datatracker . Consultado el 13 de septiembre de 2015 .
- ^ "PATCH". Documentos web de MDN . Consultado el 11 de octubre de 2018 .
- ^ Urpalainen, J. (2008). "XML RFC". tools.ietf.org . doi :10.17487/RFC5261 . Consultado el 25 de septiembre de 2015 .
- ^ "PATCH". Documentos web de MDN . Consultado el 12 de octubre de 2018 .
- ^ Darren (7 de mayo de 2014). "REST API Best Practices 3: Partial Updates - PATCH vs PUT" (Mejores prácticas de la API REST 3: actualizaciones parciales: PATCH frente a PUT). www.blogger.com . Consultado el 13 de septiembre de 2015 .
