Guía interactiva de APIs para principiantes

Aprende HTTP
sin complicarte la vida

¿Qué diablos es un endpoint? ¿Para qué sirve un GET vs un POST? ¿Por qué me aparece un error 404? Aquí lo explicamos en lenguaje humano, con ejemplos reales y nada de tecnicismos raros.

GETPOSTPUTPATCHDELETEHEAD
6
Métodos HTTP
14+
Códigos de respuesta
100%
Sin jerga técnica
Métodos HTTP

Los 6 verbos que necesitas conocer

Cada método le dice al servidor QUÉ quieres hacer. Son como verbos del idioma HTTP. Haz clic en uno para enfocarte, o desplázate para verlos todos.

GET — Pedir información

Solo mira, no toca nada

GET es como ir a una tienda y ver los productos en la vitrina. Solamente PIDES información al servidor, no cambias ni borras nada. El servidor te responde con los datos que pediste.

Analogía del mundo real

Imagina que le preguntas a Google Maps '¿Dónde está el McDonald's más cercano?' — solo pides información, no cambias el mapa.

¿Cuándo usarlo?

Ver una lista de usuarios, obtener el perfil de alguien, cargar las publicaciones de un blog.

Seguro (no modifica datos)Idempotente (repetible)Sin cuerpo (body)

POST — Crear algo nuevo

Agrega cosas nuevas al servidor

POST es como llenar un formulario de registro. Envías datos al servidor para que CREE algo nuevo. Cada vez que haces un POST, se crea un recurso diferente.

Analogía del mundo real

Es como cuando te registras en una app — completas el formulario con tu nombre y correo, y la app crea tu cuenta nueva.

¿Cuándo usarlo?

Crear una cuenta, publicar un tweet, subir una foto, enviar un mensaje.

No seguro (modifica datos)No idempotenteTiene cuerpo (body)

PUT — Reemplazar todo

Borra el viejo y pone el nuevo completo

PUT es como cambiar toda tu ficha de perfil. Envías la información COMPLETA del recurso y reemplaza todo lo anterior. Si dejas un campo vacío, ese campo se borra.

Analogía del mundo real

Es como borrar toda tu biografía de Instagram y escribirla de nuevo desde cero. Todo lo viejo desaparece y se reemplaza con lo nuevo.

¿Cuándo usarlo?

Actualizar el perfil completo de un usuario, reemplazar un documento entero.

No seguro (modifica datos)Idempotente (repetible)Tiene cuerpo (body)

PATCH — Cambiar solo un pedacito

Modifica solo lo que necesitas

PATCH es como editar solo una línea de tu perfil. Solo envías lo que quieres MODIFICAR, no tienes que mandar todo el recurso completo. Lo demás queda igual.

Analogía del mundo real

Imagina que solo quieres cambiar tu foto de perfil sin tocar tu nombre ni tu bio. PATCH hace exactamente eso.

¿Cuándo usarlo?

Cambiar solo el email, actualizar el precio de un producto, marcar una tarea como completada.

No seguro (modifica datos)No idempotenteTiene cuerpo (body)

DELETE — Eliminar algo

Borra un recurso del servidor

DELETE es exactamente lo que suena. Le dices al servidor que ELIMINE un recurso específico. Una vez que lo borras, ya no está (a menos que tengan backup).

Analogía del mundo real

Es como vaciar la papelera de reciclaje. Le estás diciendo al servidor: 'quiero que este dato deje de existir'.

¿Cuándo usarlo?

Eliminar tu cuenta, borrar un comentario, quitar un producto del carrito.

No seguro (modifica datos)Idempotente (repetible)Sin cuerpo (body)

HEAD — Solo los encabezados

Como GET pero sin el contenido

HEAD es como preguntarle a un mesero '¿cuánto pesa el menú?' sin que te lo traiga. Obtienes solo la INFORMACIÓN sobre el recurso (headers), pero no el contenido en sí.

Analogía del mundo real

Como ver el tamaño de un archivo antes de descargarlo. Usas HEAD para saber qué recibirás sin gastar ancho de banda en el contenido completo.

¿Cuándo usarlo?

Saber si un archivo existe, verificar el tamaño de una imagen, comprobar si algo fue modificado.

Seguro (no modifica datos)Idempotente (repetible)Sin cuerpo (body)
Códigos de respuesta

¿Qué me está diciendo el servidor?

Cada número que devuelve el servidor tiene un significado. Una vez que los entiendes, debuggear se vuelve mucho más fácil.

Flujo de petición

¿Qué pasa cuando haces una petición?

Detrás de cada llamada a una API hay toda una cadena de pasos. Aquí puedes ver el flujo paso a paso de forma animada.

Tu App / Browser
El cliente
Internet / DNS
La red
Servidor API
El backend
Base de datos
Los datos

Presiona "Animar flujo" para ver cómo viaja la petición GET

En la realidad: ~50-500ms
1
1. Resuelve el dominio

Tu navegador pregunta '¿cuál es la IP de api.ejemplo.com?' y el DNS responde.

2
2. GET /api/usuarios/1

Tu browser manda la petición HTTP GET al servidor con la URL y los headers.

3
3. SELECT * FROM usuarios

El servidor busca el usuario en la base de datos.

4
4. Devuelve los datos

La base de datos devuelve la fila del usuario.

5
5. 200 OK + JSON

El servidor empaqueta los datos en JSON y te los manda de vuelta con código 200.

Tip: Autenticación

En peticiones protegidas, el cliente también envía un token en los headers (como Authorization: Bearer eyJ...). El servidor verifica ese token antes de responder. Si es inválido, te llega un 401.

Playground

Prueba peticiones sin romper nada

Selecciona un escenario, mira la petición que se armaría y simula la respuesta del servidor. Cero riesgo, 100% aprendizaje.

Escenarios

Pedimos los datos del usuario con ID 1.

GET