En informática, el método PATCH es un método de solicitud compatible con el protocolo HTTP ( Protocolo de transferencia de hipertexto ) 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 documento PATCH. [1] Si el recurso solicitado no existe, entonces 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 bien definidos semánticamente, pero pueden tener un tipo de medio diferente al del recurso que se está parcheando. [2] Se pueden utilizar marcos 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 utilizar una representación completa del recurso. El método PUT que se puede usar para la creación o 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 necesitan crear nuevos recursos aplicando 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 admite varios métodos de solicitud como PUT , POST y PATCH para crear o actualizar recursos. [5]
La principal diferencia entre el método PUT y PATCH es que el método PUT usa 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 parche es mayor que el tamaño de la nueva versión del recurso enviado por el PUT método entonces el PUT se prefiere método. [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á escrito para admitir las 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 usar el método PATCH, se prefiere el método POST. [1] [6]
Parchear recursos
El método PATCH es atómico . [1] Se aplican todos los cambios especificados por el método PATCH o 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 usar para las solicitudes GET y HEAD que pueden seguir a la solicitud PATCH. [1]
Los encabezados de entidad en el documento PATCH solo se aplican al documento PATCH y no se pueden aplicar al recurso solicitado. [1]
No existe un formato estándar para el documento PATCH y es diferente para los diferentes tipos de recursos. El servidor debe verificar si el documento PATCH recibido es apropiado para el recurso solicitado. [1]
Un documento de parche JSON se vería así
{ "op" : "agregar" , "variable" : "recuento" , "valor" : 1 }
"op" representa la operación realizada en el recurso. "variable" representa el recurso que se está modificando. "valor" representa la cantidad que se agrega 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í
sel = "doc / user [@ email = 'xyz @ abc.com']" type = "@address" >ABC Road
El elemento
Ejemplo
Un ejemplo simple de solicitud de PATCH
PATCH /example.txt HTTP / 1.1 Anfitrión: www.example.com Tipo de contenido: aplicación / ejemplo If-Match : "c0b42b66e" Longitud del contenido: 120
[cambios]
[cambios] es el documento de parche que contiene todos los cambios que deben realizarse en el recurso example.txt
Respuesta de PATCH exitosa al archivo de texto existente:
HTTP / 1.1 204 Sin contenido Ubicación del contenido: /example.txt ETag : "c0b42b66f"
La respuesta 204 significa que la solicitud se procesó correctamente. [10]
Compensación 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 unos pocos cambios a un recurso. [ cita requerida ] Pero cuando se usa el método PATCH, generalmente implica buscar 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 cantidad de gastos generales 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 de RFC 2616: puede modificar recursos, no necesariamente limitados a los mencionados en el URI . [1]
El método PATCH no es idempotente . Se puede convertir en 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 de PATCH puede fallar si ocurre 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 necesario. [1]
Documento de parche no admitido
El servidor devuelve una respuesta 415 ( Tipo de medio no admitido ) con un encabezado de respuesta Accept-Patch que contiene los tipos de medios admitidos cuando el cliente envía un documento de parche no admitido. 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 el servidor entiende el documento PATCH pero no puede modificar el recurso solicitado ya sea porque hace que el recurso deje de ser válido o da como resultado 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 el servidor no puede aplicar un parche para el estado actual del recurso. [1]
Modificación conflictiva
El servidor devuelve una respuesta 412 (Precondición fallida) cuando falla la precondición 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). [1]
Modificación concurrente
El servidor devuelve una respuesta 409 (Conflicto) si las solicitudes de PATCH a un determinado recurso deben aplicarse en un orden determinado y el servidor no puede manejar solicitudes de PATCH concurrentes. [1]
Consideraciones de Seguridad
La solicitud PATCH necesita utilizar mecanismos como solicitudes condicionales que usan Etags y el encabezado de solicitud If-Match para garantizar que los datos no se corrompan durante la aplicación del parche. [1] En caso de falla de una solicitud de PATCH o falla del canal o un tiempo de espera, el cliente puede usar una solicitud GET para verificar el estado del recurso. [1] El servidor debe asegurarse de que los clientes malintencionados no utilicen el método PATCH para consumir recursos excesivos del servidor. [1]
Referencias
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y "Método PATCH para HTTP" . Consultado el 12 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ "No parchees como un idiota" . No parchees como un idiota . Consultado el 16 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ RFC 5789
- ^ "Historia de PATCH" . weblog.rubyonrails.org . Consultado el 25 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ "Protocolo de transferencia de hipertexto - HTTP / 1.1" . Consultado el 13 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ "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 . CS1 maint: parámetro desalentado ( enlace )
- ^ "Parche JSON: borrador-ietf-appsawg-json-parche-08" . Consultado el 13 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ "PARCHE" . Documentos web de MDN . Consultado el 11 de octubre de 2018 .
- ^ "XML RFC" . tools.ietf.org . Consultado el 25 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )
- ^ "PARCHE" . Documentos web de MDN . Consultado el 12 de octubre de 2018 .
- ^ Darren. "Mejores prácticas de la API REST 3: Actualizaciones parciales - PATCH vs PUT" . www.blogger.com . Consultado el 13 de septiembre de 2015 . CS1 maint: parámetro desalentado ( enlace )