¿Cuáles son los 5 métodos API?

¿Cuáles son los 5 métodos API? Funciones de GET, POST y PATCH

Entender cuáles son los 5 métodos api es esencial para cualquier desarrollador web. Conocer las diferencias entre GET, POST y PATCH permite crear aplicaciones eficientes y evitar errores en la comunicación cliente-servidor. Dominar estos conceptos mejora la calidad del código y facilita el diseño de APIs robustas.

Los cinco métodos HTTP fundamentales en una API REST

Cuando hablamos de API REST, nos referimos a un conjunto de reglas que permiten a dos sistemas comunicarse. Y en el corazón de esta comunicación están los verbos http más usados (o métodos HTTP). Son las acciones que le indicamos al servidor qué hacer con un recurso (un usuario, un producto, un pedido, etc.). Existen muchos métodos, pero cinco son los que te encuentras en prácticamente cualquier API moderna. Vamos a verlos uno por uno.

GET: El método para obtener información

Para entender qué es un método http, el método GET es el más común y sencillo. Su función es solicitar un recurso o una colección de recursos. Cuando escribes una dirección en tu navegador y presionas Enter, estás haciendo una petición GET. Es un método seguro e idempotente, lo que significa que no debería modificar el estado del servidor y que hacer la misma petición varias veces produce el mismo resultado. Por ejemplo, una petición GET /usuarios devolvería la lista de usuarios, mientras que GET /usuarios/123 devolvería los datos del usuario con ID 123.

POST: Creando nuevos recursos

Si GET sirve para leer, POST sirve para crear. Es el método que utilizamos para enviar datos al servidor con la intención de que cree un nuevo recurso. Por ejemplo, al rellenar un formulario de registro y hacer clic en Enviar, tu navegador (si el formulario está bien configurado) enviará una petición POST con los datos del nuevo usuario. A diferencia de GET, POST no es idempotente: si envías la misma petición dos veces, crearás dos recursos (por ejemplo, dos usuarios con la misma información, algo que generalmente no queremos).

PUT y PATCH: Actualizando información (con una diferencia clave)

Aquí es donde muchos desarrolladores principiantes se confunden sobre la diferencia entre post y put o entre PUT y PATCH. Ambos se usan para actualizar recursos, pero lo hacen de forma distinta. Vamos a desglosarlo. La confusión es tan común que una rápida búsqueda en foros como Stack Overflow muestra cientos de preguntas preguntando exactamente lo mismo.

PUT: Reemplazo completo del recurso

El método PUT se utiliza para reemplazar por completo un recurso existente. Piensa en ello como una operación de reescritura. Cuando envías una petición PUT a, digamos, /usuarios/123, estás diciendo: este es el nuevo estado completo del usuario 123; todo lo que había antes debe ser reemplazado por esto.

Si en el cuerpo de la petición solo incluyes el nombre y el email, y el recurso original también tenía un campo teléfono, ese campo teléfono se perderá (se establecerá a null o a su valor por defecto). Es un método idempotente: hacer la misma petición PUT una o cien veces tiene el mismo efecto final.

PATCH: Actualización parcial

Si te preguntas para qué sirve el método patch, es la opción ideal para realizar modificaciones parciales. Siguiendo el ejemplo anterior, si solo quieres cambiar el email de un usuario, con PATCH enviarías únicamente el campo email. El resto de los campos (nombre, teléfono, etc.) permanecen intactos. Es la opción más eficiente cuando solo necesitas modificar unos pocos atributos de un recurso grande. A diferencia de PUT, PATCH no es inherentemente idempotente. Dependiendo de cómo esté implementada la lógica de actualización, aplicar la misma petición varias veces podría tener efectos diferentes (por ejemplo, si la operación incrementa un valor en lugar de establecerlo).

DELETE: Eliminando recursos

El nombre lo dice todo. El método delete api rest se utiliza para eliminar un recurso específico. Una petición exitosa a DELETE /usuarios/123 debería eliminar al usuario con ese identificador. Es un método idempotente: si eliminas un recurso y luego vuelves a intentar eliminarlo, el servidor probablemente te devolverá un error 404 (No encontrado), pero el estado final del sistema (el recurso no existe) es el mismo después de la primera y la segunda petición.

Idempotencia y seguridad: conceptos clave

Para elegir bien y entender cuáles son los 5 métodos api en profundidad, es crucial entender dos conceptos: seguridad e idempotencia. Un método es seguro si no modifica el estado del servidor (solo lectura). GET y HEAD (otro método, pero no es de los 5 principales) son seguros.

Un método es idempotente si hacer la misma petición una o varias veces produce el mismo efecto en el servidor. PUT y DELETE son idempotentes. POST no lo es. PATCH puede serlo o no, dependiendo de su implementación. Esta distinción no es teoría aburrida; tiene implicaciones prácticas. Por ejemplo, si tu conexión a internet falla justo después de enviar una petición, saber si el método es idempotente te permite reenviarla sin miedo a duplicar una operación.

Errores comunes al usar métodos HTTP

Para dominar cuáles son los 5 métodos api, es importante evitar errores frecuentes, como recibir un código 405 Method Not Allowed. Esto significa que el endpoint (la URL) existe, pero no soporta el método HTTP que intentaste usar. Por ejemplo, intentar enviar un DELETE a un endpoint que solo acepta GET.

Otro error común es usar POST para todo (crear, actualizar, eliminar), lo que resulta en una API que no sigue las convenciones REST y es más difícil de entender y mantener. Usar PUT cuando se debería usar PATCH puede causar la pérdida accidental de datos (los campos no incluidos en la petición se borran), mientras que usar PATCH cuando se debería usar PUT podría llevar a un estado inconsistente si la lógica de parche no es idempotente.

Resumen visual: Los 5 métodos API

Comparativa rápida de los métodos HTTP

Para que lo tengas siempre a mano, aquí tienes una tabla que resume la función, seguridad e idempotencia de los cinco métodos principales.

GET

- Sí

- Obtener un recurso o colección

- Sí

- Generalmente no (aunque la especificación no lo prohíbe)

POST

- No

- Crear un nuevo recurso

- No

- Sí

PUT

- No

- Reemplazar completamente un recurso

- Sí

- Sí

PATCH

- No

- Actualizar parcialmente un recurso

- No inherentemente

- Sí

DELETE

- No

- Eliminar un recurso

- Sí

- Generalmente no

El dilema de Carlos con PUT y PATCH

Carlos, un desarrollador backend en una startup de Madrid, estaba construyendo la API para una aplicación de gestión de tareas. Tenía un endpoint /tareas/456 y necesitaba permitir a los usuarios marcar una tarea como 'completada'.

Su primer instinto fue usar PUT. Envió una petición con { "titulo": "Revisar informe", "descripcion": "...", "completada": true }. Funcionó, pero era ineficiente: tenía que enviar todos los datos de la tarea, incluso los que no cambiaban. Además, si otro usuario hubiera cambiado el título mientras tanto, su PUT lo sobrescribiría con el título antiguo.

Tras leer la documentación, se dio cuenta de que PATCH era la herramienta correcta. Modificó el endpoint para aceptar PATCH y el cliente comenzó a enviar solo { "completada": true }. Problema resuelto.

La lección: PUT para reemplazar, PATCH para actualizar. Un mes después, Carlos implementó un endpoint PUT para la configuración global de la aplicación, donde cada petición debía contener la configuración completa para evitar estados inconsistentes. Había aprendido la diferencia de la mejor manera: equivocándose primero.