NUCBA - Formación profesional digital

Cuando abrís una página web, tu navegador usa HTTP para pedirle al servidor que le envíe el HTML, CSS y JavaScript. Pero HTTP hace mucho más que eso. Las aplicaciones modernas lo usan constantemente para intercambiar información entre distintos servicios, y ahí es donde entran las APIs REST.

Si alguna vez te preguntaste cómo Instagram obtiene tus fotos cuando abrís la app, o cómo Mercado Libre actualiza el precio de un producto en tiempo real, la respuesta está en las APIs REST que usan HTTP como protocolo de comunicación.

Qué es realmente HTTP

HTTP (HyperText Transfer Protocol) es un protocolo de comunicación. Pensalo como un idioma que permite que dos computadoras se entiendan. Una hace pedidos (requests) y la otra responde (responses).

Cuando visitás https://nucba.io, tu navegador envía un request GET al servidor de NUCBA. El servidor responde con el HTML de la página. Pero esa misma mecánica funciona para intercambiar cualquier tipo de datos:

GET /api/cursos HTTP/1.1
Host: api.nucba.io
Authorization: Bearer tu_token_aqui

Esta request podría devolver una lista de cursos en formato JSON, no una página web.

Los métodos HTTP que más vas a usar

HTTP define varios métodos (verbos) que indican qué querés hacer con un recurso:

GET: Obtener información (como leer)
POST: Crear algo nuevo
PUT: Actualizar completamente un recurso
PATCH: Actualizar parcialmente un recurso
DELETE: Eliminar un recurso

Ejemplo práctico con una API de usuarios:

# Obtener todos los usuarios
GET /api/usuarios

# Obtener un usuario específico
GET /api/usuarios/123

# Crear un usuario nuevo
POST /api/usuarios
Content-Type: application/json

{
  "nombre": "Juan",
  "email": "juan@example.com"
}

# Actualizar el email de un usuario
PATCH /api/usuarios/123
Content-Type: application/json

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

# Eliminar un usuario
DELETE /api/usuarios/123

Anatomía de un request HTTP

Todo request HTTP tiene estas partes:

1. Línea de request

Contiene el método, la URL y la versión de HTTP:

POST /api/productos HTTP/1.1

2. Headers

Metadatos sobre el request:

Host: api.tienda.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
User-Agent: MiApp/1.0

3. Body (opcional)

Los datos que enviás, generalmente en JSON:

{
  "nombre": "Notebook Gamer",
  "precio": 150000,
  "categoria": "electronica"
}

Cómo responde el servidor

Las responses HTTP también tienen estructura:

Status codes que importan

200 OK: Todo salió bien
201 Created: Se creó algo nuevo
400 Bad Request: Mandaste datos incorrectos
401 Unauthorized: No tenés permisos
404 Not Found: No existe lo que buscás
500 Internal Server Error: El servidor tuvo un problema

Response completa

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/productos/456

{
  "id": 456,
  "nombre": "Notebook Gamer",
  "precio": 150000,
  "categoria": "electronica",
  "fecha_creacion": "2024-01-15T10:30:00Z"
}

REST: las reglas del juego

REST (Representational State Transfer) no es una tecnología, sino un conjunto de principios para diseñar APIs que usen HTTP de manera consistente.

Recursos con URLs claras

Cada "cosa" en tu API es un recurso con una URL única:

/api/usuarios          # Colección de usuarios
/api/usuarios/123      # Usuario específico
/api/usuarios/123/posts # Posts de ese usuario

Sin estado (stateless)

Cada request debe contener toda la información necesaria. El servidor no "recuerda" requests anteriores:

# Cada request incluye el token de autenticación
GET /api/perfil
Authorization: Bearer tu_token

Usa los métodos HTTP correctamente

GET para leer, nunca para modificar
POST para crear
PUT/PATCH para actualizar
DELETE para eliminar

Ejemplo real: API de una biblioteca

Suponé que estás construyendo una API para una biblioteca. Así se vería:

# Listar todos los libros
GET /api/libros
Response: 200 OK
[
  {
    "id": 1,
    "titulo": "Clean Code",
    "autor": "Robert Martin",
    "disponible": true
  },
  {
    "id": 2,
    "titulo": "JavaScript: The Good Parts",
    "autor": "Douglas Crockford",
    "disponible": false
  }
]

# Buscar libros por autor
GET /api/libros?autor=Robert%20Martin

# Prestar un libro
POST /api/prestamos
{
  "libro_id": 1,
  "usuario_id": 456,
  "fecha_devolucion": "2024-02-15"
}

Testing de APIs con herramientas reales

Para probar estas APIs podés usar:

Postman

Interfaz gráfica donde configurás requests y ves responses.

cURL desde la terminal

# GET simple
curl https://api.ejemplo.com/usuarios

# POST con datos JSON
curl -X POST https://api.ejemplo.com/usuarios \
  -H "Content-Type: application/json" \
  -d '{"nombre": "Ana", "email": "ana@test.com"}'

# Con autenticación
curl -H "Authorization: Bearer tu_token" \
  https://api.ejemplo.com/perfil

HTTPie (más amigable que cURL)

# GET
http GET api.ejemplo.com/usuarios

# POST
http POST api.ejemplo.com/usuarios nombre=Ana email=ana@test.com

# Con headers
http GET api.ejemplo.com/perfil Authorization:"Bearer tu_token"

Las APIs REST son la columna vertebral de las aplicaciones modernas. Netflix las usa para obtener tu lista de series, Spotify para cargar tu música, y prácticamente toda app móvil para sincronizar datos con el servidor. HTTP dejó de ser solo para páginas web hace mucho tiempo.

Preguntas frecuentes

¿Puedo usar otros formatos además de JSON?
Sí, HTTP no obliga a usar JSON. Podés enviar XML, texto plano, imágenes, o cualquier formato. JSON es popular porque es liviano y fácil de parsear.

¿Qué diferencia hay entre PUT y PATCH?
PUT reemplaza completamente el recurso con los datos que enviás. PATCH actualiza solo los campos que especificás, manteniendo el resto sin cambios.

¿Es necesario seguir REST al pie de la letra?
No. REST son principios, no reglas estrictas. Lo importante es ser consistente en tu API y que sea fácil de usar para otros desarrolladores.

¿Cómo funciona HTTP más allá de cargar páginas web?