El ciclo request-response de HTTP
Todo lo que pasa en la web es un pedido y una respuesta, los dos con la misma forma: una línea, unos encabezados y un cuerpo. Entender esa forma es lo que convierte «no anda» en «devuelve 403 porque falta la cookie».
Un sitio que no carga, una API que devuelve algo raro, un formulario que se pierde: el noventa por ciento de esos problemas se resuelven mirando dos textos, el pedido y la respuesta.
HTTP es más simple de lo que parece. El cliente manda un texto con una forma fija, el servidor contesta con un texto con la misma forma, y entre medio no hay estado: cada pedido llega sin memoria de los anteriores.
Los dos textos tienen la misma forma
El pedido y la respuesta se arman igual: una primera línea, encabezados y, si hace falta, un cuerpo.
| Pedido | Respuesta | |
|---|---|---|
| Primera línea | Método, ruta y versión: GET /productos?page=2 HTTP/1.1 | Versión y estado: HTTP/1.1 200 OK |
| Encabezados | Quién pide, qué acepta, con qué credenciales | Qué tipo de contenido es, cuánto dura en caché, qué cookies deja |
| Cuerpo | Sólo cuando manda datos: un POST con JSON, un archivo | Casi siempre: el HTML, el JSON, la imagen |
El método dice qué se pretende hacer
El método no es decorativo: los intermediarios —cachés, proxies, el navegador— se comportan distinto según cuál sea.
Lo que hay que saber de cada uno
- GET pide y no cambia nada. Se puede repetir, cachear y guardar en un favorito. Si un GET borra algo, el primer robot que recorra el sitio lo va a borrar.
- POST manda datos y no es repetible. Por eso el navegador pregunta antes de reenviar un formulario, y por eso existe redirigir después de un POST.
- PUT reemplaza y es idempotente. Mandarlo dos veces deja lo mismo que mandarlo una.
- PATCH cambia una parte. Idempotente sólo si vos lo hacés idempotente.
- DELETE borra, y también es idempotente: borrar dos veces deja el mismo estado final, aunque la segunda conteste 404.
El número de la respuesta es una familia
El primer dígito ya dice casi todo, y es lo primero que hay que mirar antes de leer el cuerpo.
| Familia | Qué significa | De quién es el problema |
|---|---|---|
| 2xx | Salió bien | De nadie |
| 3xx | Está en otro lado o no cambió | De nadie: seguí la redirección o usá tu caché |
| 4xx | El pedido está mal | De quien pide: falta la credencial, el dato o el permiso |
| 5xx | El pedido estaba bien y el servidor no pudo | De quien responde |
Los cuatro que más aparecen: 401 es «no sé quién sos», 403 es «sé quién sos y no podés», 404 es «eso no existe» y 429 es «pediste demasiado rápido». Confundir 401 con 403 manda a quien depura a buscar un problema de login que no existe.
Antes de seguir, predecí
Lo que hay entre el pedido y la respuesta
Entre el navegador y la aplicación hay más piezas de las que se ven, y cada una puede contestar por su cuenta: un DNS que resuelve, una CDN que puede responder sin llegar al origen, un balanceador que elige a quién mandarlo.
Escena 1 — El pedido, salto por salto
tocá las cajas
Cargando la escena…
Cómo se mira, en la práctica
Los cuatro pasos que resuelven casi todo
- Abrí la pestaña de red del navegador y mirá el pedido que falla: método, ruta y estado.
- Leé los encabezados que mandaste, no los que creés que mandaste. Falta de
Authorizationy falta deContent-Typeson el primer y el segundo motivo de un 4xx inesperado. - Repetilo desde afuera del navegador, con
curlo con el cliente que uses. Si ahí anda, el problema es del navegador: CORS, una cookie que no viaja, una extensión. - Recién entonces mirá el cuerpo. El cuerpo es lo último porque, cuando el estado es 4xx, casi siempre explica una consecuencia y no la causa.
Autoevaluación