Hispanopedia WikiEn 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 mediante el Identificador Uniforme de Recursos (URI) HTTP. [ 1 ] La lista de cambios se proporciona en forma de un documento PATCH. [ 1 ] Si el recurso solicitado no existe, el servidor puede crearlo según el tipo de medio y los permisos del documento PATCH. [ 1 ] 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. [ 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 usar para crear o reemplazar recursos, es idempotente y solo se puede usar para actualizaciones completas. Los formularios de edición utilizados en las aplicaciones convencionales de Ruby on Rails necesitan crear nuevos recursos aplicando actualizaciones parciales a un recurso padre. 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 permite a los usuarios comunicarse con el servidor para realizar operaciones CRUD . HTTP define varios métodos de solicitud, como PUT , POST y PATCH, para crear o actualizar recursos. [ 5 ]
La principal diferencia entre los métodos PUT y PATCH radica en que el método PUT proporciona una versión modificada del recurso solicitado que reemplaza la versión original, mientras que el método PATCH proporciona un conjunto de instrucciones para modificarlo. Si el documento PATCH es mayor que el tamaño de la nueva versión del recurso enviada por el método PUT , se prefiere este último . [ 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 solo se puede usar cuando está diseñado para dar soporte a las aplicaciones o cuando las aplicaciones admiten su semántica, mientras que el método PATCH se puede usar de forma genérica y no requiere soporte de la aplicación. Si se desconoce el resultado del uso del método PATCH, se prefiere el método POST. [ 1 ] [ 6 ]
Parchear recursos
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. [ 1 ] Hay muchas maneras de comprobar si un parche se aplicó correctamente. Por ejemplo, se puede aplicar la utilidad 'diff' 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 este varía según el tipo de recurso. El servidor debe verificar si el documento PATCH recibido es apropiado para el recurso solicitado. [ 1 ]
Un documento JSON Patch se vería así:
[ { "op" : "add" , "path" : "/count" , "value" : 1 } ]"op" representa la operación realizada en el recurso. "path" representa el recurso que se está modificando. "value" representa la cantidad que se está agregando al recurso existente. [ 7 ] 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. [ 8 ]
Un documento XML PATCH se vería así:
<add sel= "doc/user[@email='xyz@abc.com']" type= "@address" > ABC Road </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.txtHTTP/1.1 Servidor: www.example.com Tipo de contenido: aplicación/ejemplo If-Match : "c0b42b66e" Longitud del contenido: 120 [ Cambios : el documento de parche que contiene todos los cambios que deben realizarse en el recurso example.txt ]Respuesta PATCH exitosa al archivo de texto existente:
HTTP/1.1204No Content Ubicación del contenido: /ejemplo.txt ETag : "dd541480"La respuesta 204 significa que la solicitud se procesó correctamente. [ 10 ]
Ventajas y desventajas de PUT y PATCH
El método PUT consume más ancho de banda que el método PATCH cuando solo se necesitan aplicar algunos cambios a un recurso. Sin embargo, cuando se utiliza el método PATCH, generalmente implica obtener el recurso del servidor, comparar los archivos original y nuevo, y crear y enviar un archivo de diferencias. En el lado del servidor, este debe leer el archivo de diferencias y realizar las modificaciones. Esto implica una sobrecarga considerable en comparación con el método PUT. [ 11 ] Por otro lado, el método PUT requiere que se realice una solicitud GET antes de la 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 de RFC 2616: puede modificar recursos, no necesariamente limitados a los mencionados en la URI . [ 1 ]
El método PATCH no es idempotente . Se puede hacer idempotente mediante una solicitud condicional. [ 1 ] Cuando un cliente realiza una solicitud condicional a un recurso, la solicitud solo tiene éxito si el recurso no se ha actualizado desde la última vez que el cliente accedió a él. Esto también ayuda a prevenir la corrupción del recurso, ya que algunas actualizaciones solo se pueden realizar a partir de un punto base determinado. [ 1 ]
Manejo de errores
Una solicitud PATCH puede fallar si se produce alguno de los siguientes errores:
Documento de parche con formato incorrecto
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 de que el documento PATCH enviado no se puede aplicar al recurso solicitado. [ 1 ]
Solicitud no procesable
El servidor devuelve una respuesta 422 (Entidad no procesable) cuando entiende el documento PATCH pero no puede modificar el recurso solicitado, ya sea porque lo invalida o porque produce algún otro 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 (Precondition Failed) cuando falla la precondición proporcionada por el cliente mediante el encabezado If-Match o If-Unmodified-Since. Si no se proporciona ninguna precondición y existe una modificación conflictiva, el servidor devuelve una respuesta 409 (Conflict). [ 1 ]
Modificación concurrente
El servidor devuelve una respuesta 409 (Conflicto) si las solicitudes PATCH a un recurso determinado deben aplicarse en un orden específico y el servidor no puede gestionar solicitudes PATCH concurrentes. [ 1 ]
Consideraciones de seguridad
La solicitud PATCH necesita utilizar mecanismos como solicitudes condicionales con Etags y el encabezado de solicitud If-Match para garantizar que los datos no se corrompan durante el parcheo. [ 1 ] En caso de fallo de una solicitud PATCH, fallo del canal o tiempo de espera agotado, el cliente puede utilizar una solicitud GET para comprobar el estado del recurso. [ 1 ] El servidor debe garantizar que los clientes maliciosos no utilicen el método PATCH para consumir recursos excesivos del servidor. [ 1 ]
Referencias
- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Dusseault, L.; Snell, J. (2010). "Método PATCH para HTTP" . doi : 10.17487/RFC5789 . S2CID 42062521. Recuperado el 12 de septiembre de 2015 .
{{cite journal}}: Para citar una revista se requiere|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 tu API HTTP" . Por qué PATCH es bueno para tu 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 .
- ↑ "PARCHE" . MDN Web Docs . 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 .
- ↑ "PARCHE" . MDN Web Docs . Consultado el 12 de octubre de 2018 .
- ↑ Darren (7 de mayo de 2014). "Mejores prácticas de la API REST 3: Actualizaciones parciales: PATCH vs PUT" . www.blogger.com . Consultado el 13 de septiembre de 2015 .
- Protocolo de transferencia de hipertexto
