En el diseño de API RESTful, PUT y PATCH son dos métodos HTTP que se utilizan para actualizar recursos en el servidor, pero la diferencia entre PUT y PATCH en las API REST está en cómo realizan las actualizaciones y los escenarios en los que cada uno es más apropiado. Ambos métodos están diseñados para modificar datos existentes, pero comprender la diferencia PUT y PATCH en la API REST puede ayudar a los desarrolladores a tomar la mejor decisión según la naturaleza de la actualización que necesitan realizar. En esta publicación de blog, exploraremos la diferencia PUT y PATCH en la API REST, centrándonos en el debate entre PATCH y REST actualizado, cuándo usar cada uno y brindaremos orientación sobre cómo elegir el método correcto para diferentes casos de uso.
¿Qué es PUT en las API REST?
Para comprender la diferencia entre PUT y PATCH en las API REST, primero necesitaremos saber qué es PUT. Residencia en Sección 9.6 RFC 2616, el método PUT en la API REST solicita que la entidad adjunta se almacene en el URI de solicitud proporcionado.
Si el URI de solicitud 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. Si el URI de solicitud no apunta a un recurso existente y el agente de usuario solicitante puede definir ese URI como un nuevo recurso, el servidor de origen puede crear el recurso con ese URI.
En otras palabras, el método PUT se utiliza para actualizar un recurso completo en el servidor. Esto hace que PUT sea una actualización más “completa”, utilizada a menudo cuando es necesario un reemplazo completo del recurso.
Entonces, PUT es mejor para los siguientes casos de uso:
- Actualizar un recurso completo (por ejemplo, actualizar un perfil de usuario con toda la información nueva).
- Reemplazar un artículo o registro completo.
- Cuando la identidad del recurso es clara y sus datos deben actualizarse por completo.
En sistemas como búsqueda elástica, las operaciones idempotentes son necesarias para garantizar la coherencia de los datos. Por ejemplo, actualizar un documento en Elasticsearch usando PUT garantiza que la misma solicitud pueda repetirse sin efectos secundarios no deseados.
¿Qué es PATCH en las API REST?
Ahora que hemos cubierto PUT en las API REST, echemos un vistazo a qué es PATCH en las API REST y cómo funciona antes de comparar PUT y PATCH en las API REST. Como se define en RFC 5789, el método PATCH en la API REST solicita que se aplique un conjunto de cambios descritos en la entidad de solicitud al recurso identificado por el URI de solicitud.
Esto se alinea con la distinción API PUT vs PATCH REST, donde solo envía los datos que deben modificarse y el servidor aplica esos cambios al recurso existente sin alterar todo el recurso. Los desarrolladores suelen crear parches para representar estos cambios incrementales, asegurando una transferencia de datos mínima y actualizaciones eficientes.
Es por eso que el método PATCH en la API REST es más adecuado para los siguientes casos de uso:
- Actualizar solo un subconjunto de campos en un recurso (por ejemplo, cambiar la dirección de correo electrónico o el número de teléfono de un usuario). Un ejemplo de PATCH API podría implicar enviar solo el nuevo correo electrónico, dejando los demás campos intactos.
- Mejorar el rendimiento minimizando la carga útil de datos.
- Cuando desea actualizar un recurso de forma incremental en lugar de reemplazarlo por completo.
- Cree parches para encapsular cambios de campos específicos, como modificar el correo electrónico de un usuario, sin afectar datos no relacionados.
Para plataformas como CMS sin cabeza que a menudo manejan estructuras de contenido complejas, usar PATCH para actualizaciones más pequeñas (como modificar un solo campo) puede reducir la carga del servidor y mejorar el rendimiento.
Con estos dos métodos cubiertos, debería tener una idea decente de qué son PUT y PATCH en las API REST. Sin embargo, antes de entrar en la diferencia entre PUT y PATCH en las API REST, debemos hablar sobre la idempotencia en estos dos métodos.
Idempotencia en PUT Vs parche en API REST
En las API REST, la idempotencia se refiere a la propiedad de una operación que, cuando se repite varias veces con las mismas entradas, produce el mismo resultado. Esto significa que realizar la misma solicitud varias veces debería tener el mismo efecto en el servidor, independientemente de cuántas veces se ejecute. Esto es importante para garantizar la estabilidad y previsibilidad en una API. Pero, ¿qué importancia tiene para la diferencia PUT y PATCH en la API REST?
Método PUT e Idempotencia
El método PUT en la API REST siempre es idempotente porque está diseñado para reemplazar todo el recurso en un URI específico con los datos proporcionados en la solicitud. En otras palabras, si realiza una solicitud PUT varias veces con los mismos datos de recursos, el resultado siempre será el mismo.
¿Por qué PUT es idempotente? Cuando realiza una solicitud PUT, básicamente le está diciendo al servidor: "Este es el estado completo y exacto que quiero para este recurso". Ya sea que emita la solicitud PUT una o muchas veces, el recurso resultante siempre será idéntico.
Por ejemplo, considere el escenario en el que actualiza la dirección de correo electrónico de un usuario. Si realiza la misma solicitud PUT varias veces, el resultado no se modificará porque el recurso se reemplaza por los mismos datos cada vez.
Ejemplo:
| PUT /usuarios/1{“nombre de usuario”: “john_doe”,”correo electrónico”: “[email protected]”} |
Si envía esta solicitud varias veces, el resultado siempre será el mismo:
| {“nombre de usuario”: “john_doe”,”correo electrónico”: “[email protected]”} |
Aunque los datos del usuario ya sean estos, volver a enviar la solicitud no cambia nada. Reemplaza los datos con los mismos datos, por lo que el efecto de la solicitud sigue siendo el mismo independientemente de cuántas veces se repita. Esto es lo que hace que PUT sea idempotente.
Método PATCH e Idempotencia
El método PATCH en REST API, por otro lado, generalmente también es idempotente, pero con más flexibilidad. Cuando cree parches, asegúrese de que las operaciones sean idempotentes (por ejemplo, establecer un valor) para evitar efectos secundarios no deseados debido a solicitudes repetidas. Si PATCH es idempotente depende de la operación y de los datos que se modifican.
¿Por qué PATCH es idempotente? Para las solicitudes de PATCH, la idempotencia significa que aplicar el mismo parche varias veces tendrá el mismo resultado. Esto es cierto siempre que el parche en sí no cause efectos secundarios o cambios adicionales cuando se aplica repetidamente. Si sigues aplicando el mismo parche con los mismos datos, el resultado no debería cambiar después de la primera aplicación.
Por ejemplo, si solo está actualizando el correo electrónico de un usuario, enviar repetidamente la misma solicitud PATCH no cambiará el resultado después de la primera vez, incluso si la solicitud se realiza varias veces. El correo electrónico del usuario seguirá siendo el mismo y el estado del recurso no cambiará.
Ejemplo de API de PATCH:
| PARCHE /usuarios/1{“correo electrónico”: “[email protected]”} |
Si el correo electrónico ya era [email protected], aplicar este PARCHE nuevamente no producirá ningún cambio, lo que lo hará idempotente.
Sin embargo, PATCH también puede ser no idempotente en algunos casos. Por ejemplo, si una operación PATCH modifica un contador o agrega elementos a una lista (como incrementar un número o agregar a una matriz), las aplicaciones repetidas del mismo PATCH podrían generar resultados diferentes. Esto violaría la propiedad de idempotencia.
Ejemplo de PATCH REST de API no idempotente:
| PARCHE /counter/1{“incremento”: 1} |
Si aplica este PARCHE repetidamente, el contador seguirá aumentando, lo que dará como resultado valores diferentes cada vez. Esto no es idempotente porque el resultado cambia con cada aplicación.
Ahora que conoce lo esencial, podemos ver algunos escenarios de ejemplo para comprender mejor la diferencia entre PUT y PATCH en las API REST.
Escenarios de ejemplo: PUT vs PATCH en API REST
Dejando a un lado la teoría, veamos la diferencia entre PUT y PATCH con ejemplos, incluidas operaciones idempotentes y no idempotentes.
Escenario 1: Solicitud PUT: sustitución de un recurso completo
Imagine un punto final API para administrar productos en un sistema de comercio electrónico. Debe actualizar todos los detalles de un producto, incluido su nombre, precio y descripción. Este es un ejemplo típico del método HTTP PUT vs PATCH, donde PUT se utiliza para reemplazar el recurso completo del producto.
Producto inicial:
| OBTENER /products/1001{“id”: 1001,”nombre”: “Laptop”,”price”: 999.99,”description”: “Una computadora portátil poderosa.”} |
Quiere actualizar el precio y la descripción del producto. Envías una solicitud PUT con el recurso completo:
Solicitud de colocación:
| PUT /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “Un potente portátil con descuento.”} |
Si realiza esta solicitud PUT una o varias veces, el resultado siempre será el mismo. Los detalles del producto se actualizarán para reflejar el nuevo precio y descripción, y se obtendrá el mismo resultado cada vez. Esto asegura la naturaleza idempotente de PUT.
Resultado (después de la solicitud PUT):
| {“id”: 1001,”nombre”: “Laptop”,”price”: 899.99,”description”: “Una computadora portátil potente con descuento.”} |
Escenario 2: Solicitud de PATCH: actualización de parte de un recurso
Ahora, consideremos una solicitud de PATCH para actualizar solo una parte de los detalles del producto, como la descripción. Ejemplo de PATCH API: si desea cambiar la descripción del producto pero no su precio, PATCH es la mejor opción. Para implementar esto, crearía parches que contengan solo los campos que requieren modificación, como la descripción en este ejemplo de API REST PATCH.
Producto inicial:
| OBTENER /products/1001{“id”: 1001,”nombre”: “Laptop”,”price”: 999.99,”description”: “Una computadora portátil poderosa.”} |
Solicitud de PARCHE:
| PATCH /products/1001{“descripción”: “Una computadora portátil liviana y potente”.} |
Cuando envíe esta solicitud de PATCH, solo se actualizará el campo de descripción. Si envía la misma solicitud PATCH varias veces, la descripción permanecerá sin cambios después de la primera actualización, lo que hará que la solicitud sea idempotente.
Resultado (después de la solicitud de PATCH):
| {“id”: 1001,”nombre”: “Laptop”,”price”: 999.99,”description”: “Una laptop liviana y potente.”} |
Si aplica el mismo PARCHE nuevamente, la descripción del producto seguirá siendo la misma que después del primer PARCHE. El resultado es consistente, lo que hace que PATCH sea idempotente en este escenario.
Escenario 3: Solicitud de PATCH – Operación no idempotente
Veamos una operación PATCH no idempotente. Supongamos que hay un punto final para el saldo de la billetera de un usuario y desea incrementar el saldo. Aquí se puede ilustrar un ejemplo de diferencia entre PUT y PATCH: PATCH agregará un valor al saldo cada vez
Cartera inicial:
| OBTENER /usuarios/1/wallet{“id”: 1,”saldo”: 100.00} |
Solicitud de PARCHE:
| PARCHE /usuarios/1/billetera{“incremento”: 50.00} |
Esta solicitud de PATCH aumentará el saldo de la billetera en $50. Si envía esta solicitud de PATCH varias veces, el saldo seguirá aumentando con cada PATCH, lo que generará un resultado diferente cada vez. Esto no es idempotente porque aplicar el mismo PATCH repetidamente provocará un resultado diferente.
Resultado (después de la primera solicitud de PATCH):
| {“id”: 1,”saldo”: 150.00} |
Resultado (después de la segunda solicitud de PATCH):
| {“id”: 1,”saldo”: 200.00} |
Aquí, PATCH no es idempotente porque solicitudes repetidas con los mismos datos producen resultados diferentes.
Resumen: diferencias clave entre PUT y PATCH en las API REST
La diferencia clave entre PUT y PATCH en REST API es cómo manejan las actualizaciones. PUT reemplaza todo el recurso, por lo que los campos faltantes se eliminan, lo que puede provocar la pérdida de datos. Es por eso que los desarrolladores crean parches para actualizaciones parciales, para evitar sobrescribir campos sin cambios y mantener la integridad de los datos.
Esto hace que PATCH sea más eficiente para actualizaciones parciales. Un ejemplo de PATCH API es que si desea actualizar solo el correo electrónico de un usuario, la creación de parches solo enviará el campo de correo electrónico, a diferencia de una solicitud PUT que requeriría todos los datos del usuario.
Con PUT, se requiere la carga útil de datos completa. Esto significa que se deben enviar todos los campos y los campos faltantes se borrarán. PATCH, sin embargo, solo envía los campos que deben actualizarse, lo que lo hace más eficiente, especialmente para recursos grandes con cambios mínimos. El método PATCH en REST API permite solicitudes más pequeñas y más enfocadas, lo que reduce la transferencia de datos.
Tanto PUT como PATCH son idempotentes. Esto significa que repetir la misma solicitud dará como resultado el mismo resultado. Sin embargo, PUT es más predecible ya que reemplaza todo el recurso. PATCH, cuando se usa para modificar solo campos específicos, puede generar resultados diferentes dependiendo de cómo maneja las actualizaciones el servidor.
Por ejemplo, si un PATCH incrementa un contador, las solicitudes repetidas podrían generar resultados diferentes. No obstante, las operaciones de la API PATCH también se pueden diseñar para que sean idempotentes.
En conclusión, la diferencia PUT y PATCH en la API REST se reduce a la naturaleza de las actualizaciones: PATCH es para cambios parciales, mientras que PUT es para el reemplazo completo de recursos. Ambos son idempotentes, pero PATCH puede ser más complejo.
Pensamientos finales
Tanto PUT como PATCH son métodos HTTP fundamentales en el diseño de API REST, pero tienen propósitos diferentes, que es la esencia de la diferencia PUT y PATCH en API REST. Puedes mejorar significativamente la eficiencia, la claridad y la funcionalidad de tu API si comprendes la diferencia entre PUT y PATCH con los ejemplos que cubrimos anteriormente en este artículo. Al elegir el método correcto (PATCH o actualizar REST) según tu caso de uso, puedes hacer que tu API sea más eficiente, fácil de mantener y fácil de usar. Considere siempre la naturaleza de la actualización (ya sea completa o parcial) junto con el impacto en el rendimiento y la integridad de los datos, y seleccione el método que mejor se adapte a sus necesidades.
