HTTP y APIs por dentro
El protocolo, los códigos de estado, el diseño REST y todo lo que pasa entre el cliente y el servidor.
13 aulas · 8 horas de práctica · en el navegador, sin instalar nada
Temario
- Un pedido es texto — Qué viaja de verdad cuando el navegador pide una página: una línea, unas cabeceras, una línea vacía y a veces un cuerpo. Y cómo convertirlo en un diccionario.
- Respuestas y códigos de estado — La respuesta también es texto, y su primera línea lleva un número de tres cifras que dice qué pasó. Cuándo va cada uno, y por qué la centena es lo que importa.
- Métodos y semántica — GET, POST, PUT, PATCH y DELETE no son cinco nombres para lo mismo: cada uno promete algo. Seguro, idempotente, y por qué un GET jamás puede borrar.
- Taller — El parser — De pedido a respuesta, con las herramientas de las primeras tres aulas: parsear texto crudo con CRLF, aplicar la semántica de los métodos sobre un almacén en memoria, y armar la respuesta completa.
- URLs y query strings — Una URL tiene siete partes y cada una tiene reglas. Cómo partirla con urllib.parse, por qué el espacio es %20, y qué pasa con un parámetro que viene dos veces.
- JSON como contrato — El cuerpo de un pedido es texto que dice ser JSON. Leerlo sin confiar, validar cada campo, y devolver errores con una forma que el cliente pueda programar.
- Enrutar — De la ruta a la función: patrones con parámetros, un despachador que distingue 404 de 405, y la cadena de middlewares que el pedido atraviesa antes de llegar al manejador.
- Cabeceras que importan — Content-Type y Accept dicen qué formato viaja y cuál se espera. ETag e If-None-Match evitan mandar de nuevo lo que el cliente ya tiene. Y CORS decide qué sitios pueden leer tu respuesta desde el navegador.
- Taller — La API de tareas — Una API de tareas en memoria, de verdad: crear con validación, leer con ETag y revalidación, actualizar con control de concurrencia optimista (If-Match), borrar, y un despachador con rutas por expresión regular que junta todo.
- Autenticación — Quién sos, probado de tres formas: Basic (usuario y clave en cada pedido), Bearer con un token firmado que nadie puede falsificar sin la clave del servidor, y cookies con una sesión guardada del lado del servidor.
- Diseñar una API que otros usen — Nombrar los recursos, paginar en vez de devolver todo, filtrar con la query, versionar sin romper a nadie, y frenar antes de que un cliente tumbe el servidor: rate limiting con un balde de tokens.
- Clientes que no rompen — Un timeout que corta a tiempo, reintentos que esperan cada vez más —con algo de azar para no sincronizarse con nadie—, un circuit breaker que deja de insistir con un servicio caído, y la clave de idempotencia que hace seguro reintentar un POST.
- Taller — El gateway — Un gateway de verdad: autenticación con un token firmado, rate limiting con balde de tokens por cliente, reintentos con backoff hacia un backend inestable, pedidos seguros con idempotencia, y el registro de cada paso.