HTTP PUT vs PATCH: ¿Cuál es la diferencia?

Las peticiones HTTP son la columna vertebral del desarrollo web moderno. Nos permiten interactuar con las APIs y recuperar datos de los servidores. Dos de las peticiones HTTP más utilizadas son PUT y PATCH. En esta entrada del blog, exploraremos las diferencias entre estas dos peticiones y cuándo utilizarlas.

¿Qué es una API?

Antes de profundizar en las diferencias entre PUT y PATCH, definamos primero qué es una API. Una API significa Application Programming Interface (Interfaz de Programación de Aplicaciones). Es un conjunto de reglas definidas que permiten que diferentes aplicaciones se comuniquen entre sí. Las APIs actúan como una capa intermediaria que procesa las transferencias de datos entre sistemas, permitiendo a las empresas abrir los datos y la funcionalidad de sus aplicaciones a desarrolladores externos, socios comerciales y departamentos internos dentro de sus empresas.

Las definiciones y los protocolos dentro de una API ayudan a las empresas a conectar las muchas aplicaciones diferentes que utilizan en las operaciones diarias, lo que ahorra tiempo a los empleados y rompe los silos que dificultan la colaboración y la innovación. Para los desarrolladores, la documentación de la API proporciona la interfaz para la comunicación entre aplicaciones, simplificando la integración de aplicaciones. Las APIs se utilizan para cerrar las brechas entre pequeños fragmentos de código discretos para crear aplicaciones que sean potentes, resistentes, seguras y capaces de satisfacer las necesidades de los usuarios.

¿Visión general de los métodos HTTP?

HTTP (Hypertext Transfer Protocol) es un protocolo de capa de aplicación utilizado para transmitir documentos de hipermedia, como HTML, a través de Internet. Facilita la comunicación entre navegadores web y servidores web, pero también puede utilizarse para otros fines. HTTP funciona como un protocolo cliente-servidor, con peticiones iniciadas normalmente por el destinatario, normalmente el navegador web. El documento completo se reconstruye a partir de diferentes subdocumentos recuperados, incluyendo texto, descripción del diseño, imágenes, vídeos, scripts y más.

Los clientes y los servidores se comunican intercambiando mensajes individuales (en lugar de un flujo continuo de datos). Los mensajes enviados por el cliente (normalmente un navegador web) se denominan peticiones, y los mensajes enviados por el servidor en respuesta se denominan respuestas. HTTP es un protocolo extensible que ha evolucionado con el tiempo y se envía a través de TCP o a través de una conexión TCP cifrada con TLS. Debido a su extensibilidad, se utiliza no sólo para obtener documentos de hipertexto, sino también para recuperar imágenes y vídeos o para publicar contenido en servidores, como con los resultados de formularios HTML. Además, HTTP puede utilizarse para obtener partes de documentos para actualizar páginas web bajo demanda.

Introducción de HTTP PUT

HTTP PUT es un método HTTP utilizado para crear un nuevo recurso o sobrescribir una representación del recurso de destino que es conocido por el cliente. Es similar al método HTTP POST, que se utiliza para añadir un recurso en el servidor.

Sin embargo, a diferencia de POST, PUT es idempotente, lo que significa que llamarlo una o varias veces sucesivamente tiene el mismo efecto (es decir, no tiene efectos secundarios). Si el Request-URI se refiere a un recurso ya existente, la entidad adjunta debe considerarse como una versión modificada de la que reside en el servidor de origen.

Entendiendo HTTP PATCH

HTTP PATCH es un método de petición utilizado para realizar modificaciones parciales a un recurso existente. Es similar al método HTTP PUT, que se utiliza para crear un nuevo recurso o sobrescribir una representación del recurso de destino que es conocido por el cliente. Sin embargo, a diferencia de PUT, PATCH se utiliza para modificar sólo una parte del recurso, mientras que PUT reemplaza todo el recurso.

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) HTTP. La lista de cambios se proporciona en forma de documento PATCH. El método PATCH se utiliza para actualizar recursos con datos JSON parciales.

Cuándo usar HTTP PUT

HTTP PUT se utiliza para crear un nuevo recurso o sobrescribir una representación del recurso de destino que es conocido por el cliente. Es adecuado para escenarios en los que se tiene control total sobre el reemplazo de recursos.

La diferencia entre HTTP PUT y HTTP POST es que PUT es idempotente, lo que significa que llamarlo una o varias veces sucesivamente tiene el mismo efecto (es decir, no tiene efectos secundarios). Si el Request-URI se refiere a un recurso ya existente, la entidad adjunta debe considerarse como una versión modificada de la que reside en el servidor de origen.

HTTP PUT se utiliza mejor cuando se desea reemplazar completamente un recurso existente con nuevos datos. Por ejemplo, si tienes un perfil de usuario que contiene múltiples campos como nombre, correo electrónico y número de teléfono, y deseas actualizar todos estos campos a la vez, utilizarías una petición PUT.

Aquí tienes un ejemplo de cómo podrías utilizar una petición HTTP PUT para actualizar el contenido de un archivo existente en un servidor:

PUT /example.html HTTP/1.1
Host: sample.com
Content-Type: text/html
Content-Length: 20

<p>Archivo Actualizado</p>

En este ejemplo, la petición PUT se envía al recurso ubicado en /example.html. La cabecera Content-Type especifica que el cuerpo de la petición está en formato HTML. La cabecera Content-Length indica el tamaño del cuerpo de la petición, que en este caso es de 20 bytes. El cuerpo de la petición contiene el nuevo contenido para el archivo, que es un simple elemento de párrafo HTML con el texto "Archivo Actualizado". Si el archivo existe y el servidor procesa la petición con éxito, reemplazará el contenido de example.html con el nuevo contenido proporcionado en el cuerpo de la petición.

Cuándo usar HTTP PATCH

HTTP PATCH se utiliza para realizar modificaciones parciales a un recurso existente. Es adecuado para escenarios en los que sólo se necesita actualizar una parte del recurso, mientras que PUT reemplaza todo el recurso.

Por ejemplo, al actualizar un solo campo del recurso, enviar la representación completa del recurso puede ser engorroso y utiliza mucho ancho de banda innecesario. Una petición PATCH se considera un conjunto de instrucciones sobre cómo modificar un recurso.

HTTP PATCH se utiliza mejor cuando se desea actualizar un solo campo o algunos campos en un recurso existente. Por ejemplo, si tienes un perfil de usuario que contiene múltiples campos como nombre, correo electrónico y número de teléfono, y sólo deseas actualizar el campo de correo electrónico, utilizarías una petición PATCH.

Aquí tienes un ejemplo de cómo podrías utilizar una petición HTTP PATCH para actualizar la dirección de correo electrónico de un usuario en un sistema:

PATCH /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
If-Match: "e0023aa4e"

{
  "email": "newemail@example.com"
}

En este ejemplo, la petición PATCH se envía al recurso ubicado en /api/users/123. La cabecera Content-Type especifica que el cuerpo de la petición está en formato JSON. La cabecera If-Match se utiliza para asegurar que la actualización sólo se aplica si el eTag (un identificador de versión para el recurso) coincide con el proporcionado. El cuerpo de la petición contiene el cambio que se aplicará, que en este caso es una actualización de la dirección de correo electrónico del usuario. El servidor procesaría entonces esta petición y aplicaría la actualización a la información del usuario. Si tiene éxito, el servidor podría responder con un código de estado 200 OK y posiblemente incluir el recurso actualizado en el cuerpo de la respuesta.

Diferencias entre HTTP PUT y PATCH

HTTP PUT y HTTP PATCH son ambos métodos HTTP utilizados para modificar recursos, pero difieren en cómo actualizan el recurso.

HTTP PUT se utiliza para crear un nuevo recurso o sobrescribir una representación del recurso de destino que es conocido por el cliente. Es adecuado para escenarios en los que se tiene control total sobre el reemplazo de recursos. Si el Request-URI se refiere a un recurso ya existente, la entidad adjunta debe considerarse como una versión modificada de la que reside en el servidor de origen.

HTTP PATCH se utiliza para realizar modificaciones parciales a un recurso existente. Es adecuado para escenarios en los que sólo se necesita actualizar una parte del recurso, mientras que PUT reemplaza todo el recurso. 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) HTTP. La lista de cambios se proporciona en forma de documento PATCH.

La principal diferencia entre HTTP PUT y PATCH es la cantidad de datos que se envían en la petición. PUT envía todo el recurso, mientras que PATCH sólo envía los campos que se están actualizando. Esto significa que las peticiones PUT son más costosas en términos de ancho de banda y potencia de procesamiento que las peticiones PATCH.

Ventajas de HTTP PUT

HTTP PUT es un método de petición que se utiliza para actualizar o reemplazar un recurso existente en el servidor. Algunas de las ventajas de utilizar HTTP PUT incluyen:

• Idempotencia: HTTP PUT es un método idempotente, lo que significa que la misma petición puede hacerse varias veces sin causar ningún efecto secundario.
• Atomicidad: HTTP PUT es una operación atómica, lo que significa que o bien tiene éxito completamente o bien falla completamente. Esto lo hace útil para actualizar recursos que tienen múltiples campos.
• Interfaz uniforme: HTTP PUT sigue la restricción de interfaz uniforme de los servicios web RESTful, lo que lo hace fácil de usar y entender.
• Almacenamiento en caché: Las peticiones HTTP PUT pueden ser almacenadas en caché por intermediarios como los proxies, lo que puede ayudar a reducir el tráfico de red y mejorar el rendimiento.

Ventajas de HTTP PATCH

El método PATCH en HTTP se utiliza para actualizar parcialmente un recurso en el servidor. Permite enviar sólo los datos que necesitan ser actualizados, en lugar de enviar todo el recurso. Esto puede ser ventajoso en situaciones en las que se desea realizar pequeños cambios específicos en un recurso sin tener que volver a enviar todo el recurso.

Las ventajas de utilizar el método HTTP PATCH incluyen:

1. Eficiencia: PATCH permite un uso más eficiente de los recursos de red enviando sólo los cambios que necesitan ser realizados, reduciendo la cantidad de datos transmitidos.
2. Actualizaciones parciales: PATCH permite actualizar partes específicas de un recurso sin afectar al resto del recurso, proporcionando un control granular sobre las actualizaciones.
3. Idempotente: Cuando se utilizan correctamente, las peticiones PATCH son idempotentes, lo que significa que múltiples peticiones idénticas producirán el mismo resultado que una sola petición, reduciendo el riesgo de efectos secundarios no deseados.

Estas ventajas hacen que HTTP PATCH sea particularmente útil para casos de uso específicos donde sólo un subconjunto de datos de recursos necesita ser actualizado.

Cómo usar Apidog para enviar peticiones con HTTP PUT y HTTP PATCH

Apidog es una plataforma de colaboración integrada diseñada para agilizar el proceso de trabajo con APIs. Combina características de herramientas como Postman, Swagger, Mock y JMeter para proporcionar una solución integral para la documentación, depuración, simulación y pruebas automatizadas de APIs.

Apidog te permite enviar peticiones HTTP para probar y depurar tus APIs sin necesidad de redefinirlas si ya están documentadas. El uso de Apidog para enviar peticiones PUT y PATCH implica algunos pasos.

Enviar petición HTTP PUT con Apidog

Para enviar una petición HTTP PUT con Apidog, puedes seguir estos pasos:

1. Abrir Apidog: Empieza por abrir Apidog y crear una nueva petición.

2. Especificar el método HTTP: Elige PUT como el método HTTP para tu petición.

3. Introducir la URL: Introduce la URL del recurso que deseas actualizar, incluye cualquier cabecera necesaria, como Content-Type o Authorization y añade los datos que deseas enviar en el cuerpo de la petición. Puedes utilizar el parámetro json para enviar datos JSON o el parámetro data para enviar datos codificados en formulario.

4. Enviar la petición: Una vez que hayas configurado tu petición, envíala al servidor.

Comprueba la respuesta del servidor a tu petición PUT y gestiónala en consecuencia.

Al utilizar Apidog, puedes mantener la consistencia de los datos en diferentes sistemas y asegurar que el desarrollo de tu API está en estricta conformidad con la documentación de tu API, lo que lleva a una colaboración más efectiva y menos inconsistencias.

Enviar petición HTTP PATCH con Apidog

1. Abrir Apidog: Inicia la aplicación Apidog y empieza por crear una nueva petición dentro de la aplicación.

2. Seleccionar el método HTTP: Elige PATCH de la lista de métodos HTTP.

3. Introducir la URL: Introduce la URL del punto final donde deseas enviar la petición PATCH, añade cabeceras si es necesario y en el cuerpo de la petición, incluye los datos que deseas actualizar parcialmente.

Ejecuta la petición y espera la respuesta del servidor.

Analiza la respuesta del servidor para asegurar que la petición PATCH fue exitosa.

Mejores prácticas para usar peticiones HTTP PUT y HTTP PATCH

Cuando se trabaja con métodos HTTP como PUT y PATCH, es importante seguir las mejores prácticas para asegurar que tu API es fiable, eficiente y fácil de usar. Aquí hay algunas mejores prácticas para usar peticiones PUT y PATCH:

Mejores prácticas para usar peticiones HTTP PUT

• Usar PUT para actualizaciones completas: PUT debe usarse cuando deseas actualizar un recurso por completo. Reemplaza todo el recurso con la carga útil proporcionada en el cuerpo de la petición.
• Asegurar la idempotencia: Las peticiones PUT deben ser idempotentes, lo que significa que hacer múltiples peticiones idénticas debe tener el mismo efecto que hacer una sola petición.
• Incluir el recurso en la URL: La URL debe contener el identificador del recurso a actualizar.

Mejores prácticas para usar peticiones HTTP PATCH

• Usar PATCH para actualizaciones parciales: PATCH debe usarse para actualizaciones parciales, es decir, cuando sólo necesitas actualizar campos específicos de un recurso.
• Gestionar la no idempotencia apropiadamente: No se requiere que las peticiones PATCH sean idempotentes. Si tu implementación es idempotente, debe comportarse en consecuencia.
• Usar un formato Delta: Enviar sólo los cambios (el delta) que deseas aplicar al recurso, en lugar del recurso completo.

Mejores prácticas generales para usar HTTP PUT y HTTP PATCH

• Validar la entrada: Siempre validar los datos de entrada para ambas peticiones PUT y PATCH para prevenir actualizaciones de datos inválidas.
• Usar ETags para el control de concurrencia: Implementar ETags para gestionar actualizaciones concurrentes y evitar el problema de la "actualización perdida".
• Devolver códigos de estado apropiados: Usar los códigos de estado HTTP correctamente para indicar el resultado de la petición (por ejemplo, 200 OK, 204 No Content, 400 Bad Request).
• Documentar tu API: Documentar claramente el comportamiento esperado de tus puntos finales PUT y PATCH, incluyendo los campos requeridos y las reglas de validación.

Conclusión

En conclusión, HTTP PUT y PATCH son ambas peticiones HTTP importantes que se utilizan para actualizar recursos en un servidor. PUT se utiliza mejor cuando deseas reemplazar completamente un recurso existente con nuevos datos, mientras que PATCH se utiliza mejor cuando deseas actualizar un solo campo o algunos campos en un recurso existente. Ambas peticiones tienen sus ventajas y desventajas, y la elección entre ellas depende del caso de uso específico.

Al usar Apidog, tienes la capacidad de enviar sin esfuerzo tus peticiones HTTP para probar y depurar tus APIs.