Códigos de estado

2.3 Códigos de estado

Después de comprender cómo se estructura una petición HTTP y qué métodos utiliza el cliente para comunicarse con el servidor, es fundamental entender cómo el servidor responde a esas peticiones. Los códigos de estado HTTP son componentes esenciales de la respuesta que permiten al cliente interpretar el resultado de su solicitud. Cada código transmite información sobre el éxito, el error o la acción requerida, facilitando la comunicación efectiva en la arquitectura cliente-servidor. En el contexto de la administración de servicios web, el dominio de estos códigos es indispensable para diagnosticar problemas, optimizar aplicaciones y garantizar una experiencia de usuario consistente.

La especificación HTTP, definida en las RFCs 7230-7237 y actualizada constantemente por el IETF, organiza los códigos de estado en cinco categorías principales basadas en el dígito de centena. Cada categoría comunica una clase de respuesta diferente: desde confirmaciones de éxito hasta redirecciones, errores de cliente o problemas en el servidor. Como administrador de servicios web, necesitas conocer no solo la clasificación general, sino también los códigos específicos que encontrarás en los logs de tus servidores, las situaciones que los generan y cómo interpretar su presencia para mantener la salud del servicio.

Clasificación de códigos de estado por categoría

Los códigos de estado HTTP se distribuyen en cinco rangos numerados, cada uno representando una categoría de respuesta. Esta estructura es fundamental para que tanto servidores como navegadores y aplicaciones cliente interpreten automáticamente la naturaleza de la respuesta sin necesidad de analizar el cuerpo del mensaje.

Los códigos 1xx (Informativos) son códigos de respuesta provisional que indican que se ha recibido la solicitud y se está procesando. El código 100 Continue informa al cliente que puede continuar enviando el cuerpo de la petición, especialmente importante en solicitudes POST con cuerpos grandes. El código 101 Switching Protocols se utiliza cuando el cliente solicita cambiar el protocolo de comunicación, típicamente para actualizar HTTP a WebSocket. Estos códigos son menos comunes en la administración cotidiana pero son críticos en escenarios de comunicación en tiempo real.

Los códigos 2xx (Éxito) indican que la solicitud se procesó correctamente. El 200 OK es la respuesta más común, indicando que la petición tuvo éxito y la respuesta contiene los datos solicitados. El 201 Created se utiliza cuando una solicitud POST crea un nuevo recurso, mientras que 202 Accepted indica que la solicitud se aceptó para procesamiento pero aún no se completó. El 204 No Content responde satisfactoriamente pero sin cuerpo de respuesta, útil para operaciones DELETE o actualizaciones que no necesitan retornar datos. El 206 Partial Content se utiliza en descargas parciales o reanudables, fundamental para streaming de vídeo y descargas de archivos grandes.

Los códigos 3xx (Redirección) indican que se requieren acciones adicionales para completar la solicitud. El 301 Moved Permanently comunica que el recurso cambió de ubicación permanentemente, y los navegadores actualizan sus referencias. El 302 Found indica una redirección temporal, mientras que 304 Not Modified informa que el recurso no cambió desde la última solicitud, optimizando el ancho de banda al no enviar datos innecesariamente. El 307 Temporary Redirect mantiene el método HTTP original, a diferencia de 302 que algunos navegadores pueden cambiar de POST a GET.

Los códigos 4xx (Error del cliente) señalan que el cliente realizó una solicitud incorrecta o incompleta. El 400 Bad Request indica un error sintáctico en la petición. El 401 Unauthorized requiere autenticación, mientras que 403 Forbidden indica que el servidor rechaza la solicitud aunque el cliente esté autenticado. El 404 Not Found es quizás el más reconocido, indicando que el recurso no existe. El 405 Method Not Allowed comunica que el método HTTP utilizado no está permitido para ese recurso. El 409 Conflict surge cuando hay conflicto de versiones en operaciones PATCH o PUT. El 429 Too Many Requests implementa control de velocidad (rate limiting), indicando que el cliente excedió el límite de peticiones permitidas.

Los códigos 5xx (Error del servidor) indican que el servidor no pudo procesar una solicitud válida. El 500 Internal Server Error es el más genérico, señalando un error no especificado en la aplicación. El 502 Bad Gateway indica que el servidor proxy recibió una respuesta inválida del servidor ascendente. El 503 Service Unavailable comunica que el servicio está temporalmente no disponible, típicamente durante mantenimiento o sobrecarga. El 504 Gateway Timeout indica que el servidor ascendente tardó demasiado en responder. El 505 HTTP Version Not Supported comunica que el servidor no soporta la versión de HTTP utilizada.

Interpretación de códigos en el contexto de la administración de servicios web

Como administrador, debes interpretar estos códigos en los logs de acceso y error. Los logs de Apache o Nginx registran el código de estado de cada petición, permitiéndote identificar patrones problemáticos. Un aumento repentino de códigos 500 puede indicar un problema en la aplicación web o base de datos. Un pico de 429 sugiere que necesitas ajustar la política de rate limiting o que estás bajo ataque. Un exceso de 404 puede indicar enlaces rotos o cambios en la estructura de URLs que no se documentaron.

Los códigos 3xx requieren especial atención: demasiadas redirecciones consumen recursos innecesariamente y ralentizan la experiencia del usuario. Una cadena de redirecciones 301 puede indicar que la configuración de rewrite de URLs está mal implementada. Los códigos 4xx tipo 401 o 403 pueden señalar problemas con autenticación, certificados o permisos de archivos. El 502 y 504 son críticos en arquitecturas con balanceadores de carga, indicando servidores ascendentes caídos o lentos.

Ejemplo práctico: análisis de códigos en un escenario real

Supongamos que administras un servidor web que aloja una tienda online. Durante la mañana, los logs muestran patrones normales: 200 para acceso a productos, 301 para URLs antiguas que redirigen a nuevas. A las 14:00, observas un aumento masivo de 429 Too Many Requests durante 10 minutos. Esto puede indicar: (a) un bot scrapeando sin respetar robots.txt, (b) un cliente legítimo con un problema de reintento automático, o (c) un usuario ejecutando herramientas de testing. Aumentas temporalmente el límite de rate limiting y activas registros detallados. Encuentras que la mayoría de 429 proviene de un rango IP específico, confirmando un bot.

Posteriormente, un cliente reporta que ciertos productos no se cargan correctamente en su móvil. Verificas los logs y encuentras 206 Partial Content con frecuencia anormal. Esto sugiere que el cliente está usando descarga reanudable, pero probablemente hay una incompatibilidad con el servidor de caché o los encabezados Range no se procesan correctamente. Revisas la configuración de compresión y los headers de control de caché, encontrando que falta el header Accept-Ranges. Después de corregir la configuración, los 206 desaparecen y la experiencia del usuario mejora.

Finalmente, durante un despliegue de actualización, el servidor retorna múltiples 503 Service Unavailable durante 2 minutos. Aunque esperado, los logs muestran que algunos clientes no respetaron estos códigos y continuaron reintentando. Configuras un archivo 503.html más agresivo con información clara sobre el mantenimiento y un tiempo de reintento sugerido usando el encabezado Retry-After.

Códigos de estado en diferentes contextos HTTP

Los códigos de estado tienen comportamientos diferentes según el método HTTP utilizado. Un GET que retorna 200 contiene datos solicitados. Un POST que retorna 201 Created incluye la ubicación del nuevo recurso en el encabezado Location. Un DELETE que retorna 204 No Content confirma la eliminación sin necesidad de respuesta adicional. Un PUT que retorna 409 Conflict puede indicar que la versión del recurso cambió desde la lectura, común en APIs RESTful con control de concurrencia.

En APIs modernas, los códigos 2xx no solo comunican éxito, sino también el tipo de respuesta: 200 para retorno de datos, 201 para creación, 202 para procesamiento asincrónico, 204 para éxito sin datos. El cliente puede así procesarlos de manera diferenciada. Los códigos 4xx dan información específica al cliente sobre qué corregir: 400 para corregir sintaxis, 401 para autenticarse, 403 para solicitar permisos, 404 para cambiar la URL. Esta distinción es esencial para una integración efectiva entre servicios.

Ideas clave

• Los códigos de estado HTTP se organizan en cinco categorías: 1xx informativos, 2xx éxito, 3xx redirección, 4xx error del cliente y 5xx error del servidor, cada una comunicando un tipo diferente de resultado.
• El código 200 OK es la respuesta más común para solicitudes exitosas, mientras que 404 Not Found, 500 Internal Server Error y 429 Too Many Requests son frecuentes en diagnóstico de problemas de servicios web.
• Analizar patrones de códigos de estado en logs de acceso es fundamental para identificar problemas: picos de 500 sugieren errores de aplicación, aumentos de 429 pueden indicar ataques o clientes defectuosos.
• Los códigos 3xx requieren atención especial porque redirecciones excesivas ralentizan servicios; cadenas de 301 mal configuradas consumen recursos innecesarios y afectan el rendimiento.
• Diferentes métodos HTTP generan códigos esperados diferentes: POST → 201 Created, DELETE → 204 No Content, GET a recurso versionado → 409 Conflict si cambió, permitiendo al cliente procesar respuestas de manera específica.
• Configurar encabezados como Retry-After, Accept-Ranges y Location mejora la experiencia de cliente: los navegadores y aplicaciones entienden estos códigos y encabezados para reintentabilidad, descargas parciales y ubicación de nuevos recursos.