Clases de estados HTTP 2xx y 4xx

Este artículo es una explicación conceptual sobre los códigos de estado 2xx y 4xx más importantes, incluyendo preguntas de examen y etiquetas.

En pocas palabras

2xx indica procesamiento exitoso. 4xx marca errores del cliente. Los códigos correctos mejoran la claridad, el caché, la idempotencia y las APIs robustas.

Descripción técnica compacta

2xx típicos:

• 200 OK (lectura/éxito)
• 201 Created + Location (recurso creado)
• 202 Accepted (iniciado de forma asincrónica)
• 204 No Content (sin cuerpo)

4xx típicos:

• 400 Bad Request (sintaxis/validación)
• 401 Unauthorized (autenticación ausente)
• 403 Forbidden (sin autorización)
• 404 Not Found
• 409 Conflict
• 422 Unprocessable Content (semánticamente inválido)
• 429 Too Many Requests (Rate Limit) + Retry-After

Los objetos de error uniformes según RFC 7807 (Problem Details) facilitan el debugging y la documentación.

Puntos clave para el examen

• 201 siempre con Location
• 204 solo cuando realmente no hay cuerpo
• 202 + endpoint de estado (Location) para async
• Separar claramente 401 vs 403
• 409/412 en concurrencia/ETag
• Sin detalles sensibles en errores
• Documentar códigos de estado por endpoint en OpenAPI

Componentes principales

1. 2xx: 200/201/202/204
2. 4xx: 400/401/403/404/409/422/429
3. Headers: Location, Retry-After, ETag, Content-Type
4. Requests condicionales (If-Match)
5. Problem Details (type/title/status/detail/instance)
6. Tests (tests negativos/contract tests)

Ejemplo práctico

POST /orders
→ 201 Created
Location: /orders/42
ETag: W/"7c9"

PUT /orders/42 (If-Match: W/"7c9")
→ 412 Precondition Failed en conflicto de versión

GET /orders/9999
→ 404 Not Found

Ventajas e inconvenientes

Ventajas

• Semántica clara
• Menos errores de integración
• Mejor comportamiento de caché/reintentos

Inconvenientes

• Códigos incorrectos generan confusión
• Los valores por defecto del framework causan inconsistencias
• Requiere más cuidado y pruebas

Preguntas típicas de examen (con respuesta breve)

1. ¿Cuándo 201 y qué header? En creación; Location muestra la nueva URI.
2. ¿200 vs 204? 200 con cuerpo, 204 sin cuerpo.
3. ¿401 vs 403? 401 cuando falta autenticación o es inválida; 403 sin permisos.
4. ¿Cuándo 422 en lugar de 400? JSON sintácticamente correcto, pero semánticamente inválido.

Respuesta abierta

Define por endpoint cuáles son los códigos permitidos, cuándo ocurren, qué headers se configuran y cómo se ven los objetos de error. De esta forma reduces significativamente la carga de soporte.

Estrategia de aprendizaje

1. Analiza los códigos de estado de una API pública.
2. Dibuja un diagrama de secuencia para el flujo 202.
3. Practica con tarjetas (código → significado → headers).
4. No uses 200 “para todo”.

Fuentes más importantes

1. https://www.rfc-editor.org/rfc/rfc9110
2. https://developer.mozilla.org/docs/Web/HTTP/Status
3. https://www.rfc-editor.org/rfc/rfc7807