HTTP: peticiones, respuestas y estados
Lee una petición y una respuesta reales, entiende qué prometen de verdad los códigos de estado y por qué HTTP finge no recordarte.
HTTP es una conversación de texto sobre una conexión TCP ya establecida. El cliente envía una petición; el servidor responde con exactamente una respuesta. Una petición es línea de petición, cabeceras, línea vacía y cuerpo opcional. Una respuesta es línea de estado, cabeceras, línea vacía y cuerpo opcional.
Conexión cerrada. Todavía no hay nada conectado.
- Paquetes enviados
- 0
- Reenvíos
- 0
- Estado
- Aún no establecida
GET /articles/42 HTTP/1.1
Host: api.example.org
Accept: application/json
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60
{"id": 42, "title": "..."}Las familias de estados dicen quién debe actuar. 2xx — funcionó. 3xx — el recurso se movió y la cabecera Location dice a dónde. 4xx — la culpa es de la petición: 400 mal formada, 401 sin autenticar, 403 prohibido, 404 no existe, 429 demasiadas peticiones. 5xx — la culpa es del servidor. Un 502 o un 503 merece un reintento; un 400 nunca.
Práctica
Construye una petición HTTP correcta que cree un pedido nuevo con cuerpo JSON {"item":"book"}.
Pistas
- La línea de petición responde a tres preguntas: qué acción, qué recurso y qué versión del protocolo.
- En HTTP/1.1 una petición sin cabecera Host no le dice al servidor qué sitio quieres.
15 XP
POST /orders devuelve 503. ¿Qué debería hacer el cliente?
Pistas
- Mira el método, no solo el código: el código dice qué hizo el servidor, no quién tiene la culpa.
- Solo conviene reintentar automáticamente cuando repetir la petición es seguro.
13 XP
Escribe una función loadUser(id) que pida /users/{id} como JSON, compruebe el estado y lance un error con 404.
Pistas
- Envía la cabecera Accept en el mismo objeto de opciones que pasas a fetch.
- Devuelve el objeto ya parseado, no la Response, y lanza el error antes de parsear si la petición falló.
16 XP