El método HTTP Patch se utiliza para solicitar un conjunto de modificaciones en la entidad de solicitud que se aplicarán al recurso reconocido por Request-URI. Este método juega un papel vital en la mejora de la interoperabilidad y la prevención de errores al realizar cambios parciales en el recurso. El conjunto de cambios descrito se representa en un formato identificado como Documento de parche por tipo de medio.
El parche es un método único en el que se aplican todos los cambios solicitados por el servidor o ninguno. Si se pasa una solicitud PATCH usando un caché, el URI de solicitud identifica una o más entidades almacenadas en caché. Luego, las entradas se designan como entradas «obsoletas». No existe un formato predeterminado para la documentación de parches y se requieren servidores para crear un documento que se ajuste a las necesidades del recurso identificado. Este método de solicitud debe emitirse de tal manera que sea idempotente, ya que evita los malos resultados de la colisión de dos requests de parche en el mismo recurso en un marco de tiempo similar.
El parche es muy diferente ya que el servidor procesa la entidad adjunta para modificar el recurso identificado por la URI de solicitud. La entidad adjunta contiene un conjunto de instrucciones que describen el procedimiento para modificar la versión actual del recurso existente en el servidor de origen. Este método afecta al recurso identificado por Request-URI y también puede convertirse en la causa de posibles efectos secundarios en otros recursos.
Ejemplo: Este ejemplo ha sido tomado de RFC 5789 . Describe el uso de Patch Document en un recurso existente y la respuesta exitosa recibida para el archivo de texto existente. En respuesta, se usa el código 204 debido a la falta de cuerpo del mensaje y el campo de encabezado de respuesta ETag se usa para indicar la entidad creada en http://www.example.com/file.txt mediante la aplicación de Patch.
Solicitud:
PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100
Respuesta:
HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"
Manejo de errores en el parche:
Una solicitud de parche puede fallar debido a la ocurrencia de cualquiera de los errores mencionados.
- Documento de parche con formato incorrecto : este error ocurre cuando el cliente envía un documento de parche con formato incorrecto. Se especifica mediante la respuesta 400 (Solicitud incorrecta).
- Documento de parche no admitido: este error ocurre cuando el cliente envía un formato de documento de parche que no es compatible con el servidor para el recurso actual identificado por URI de solicitud. Se especifica mediante la respuesta 415 (Tipo de medio no compatible).
- Solicitud no procesable: este error ocurre cuando el servidor considera que la sintaxis es válida y comprende el documento, pero no puede procesar la solicitud. Se especifica mediante la respuesta 422 (Entidad no procesable).
- Recurso no encontrado: este tipo de error ocurre cuando el documento de parche no se puede aplicar a un recurso que no existe. Se especifica mediante la respuesta 404 (No encontrado).
- Estado en conflicto: este error ocurre cuando la solicitud no se puede aplicar dado el estado del recurso. Se especifica mediante la respuesta 409 (Conflicto).
- Modificación en conflicto: este error ocurre cuando el cliente usa el encabezado If-Match o If-Unmodified-Since para definir una condición previa que falla. Se especifica mediante la respuesta 412 (Error de condición previa). Cuando el servidor detecta una posible modificación en conflicto y no se define ninguna condición previa en la solicitud, se envía la respuesta 409 (Conflicto).
- Modificación simultánea: este error ocurre cuando el servidor no puede poner en cola requests simultáneas para modificar el recurso cuando está operando bajo restricciones. Se especifica mediante la respuesta 409 (Conflicto). Se especifica mediante la Respuesta 409 (Conflicto).
Publicación traducida automáticamente
Artículo escrito por shreyanshisingh28 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA