Los códigos de estado

Toda respuesta HTTP lleva un código de tres cifras. El primer dígito basta para saber qué ha pasado y, sobre todo, de quién es el problema si lo hay.

La frontera que hay que tener clarísima está entre el 4 y el 5: en la familia 4xx la culpa es de quien pregunta, y en la 5xx de quien contesta.

Los 1xx son provisionales: no cierran el intercambio. El 100 Continue le dice al cliente que puede seguir enviando el cuerpo, y el 101 Switching Protocols confirma un cambio de protocolo sobre la misma conexión, que es como arranca una conexión WebSocket.

Los códigos 204 y 206 se añaden aquí porque entran a examen con frecuencia. La confusión típica es entre 200 y 201: si la petición ha creado algo nuevo, lo correcto es 201 y no 200.

Salvo el 304, todos los 3xx llevan la cabecera Location con la nueva dirección, y el navegador la sigue sin preguntar. Lo que distingue a unos de otros es si el cambio es definitivo y si se conserva el método original.

301 permanente y 302 temporal. Y el 304 es el intruso de la familia: no redirige a ninguna parte, es la respuesta a una petición condicional.

Es la familia más numerosa y la que más cae. Casi todos sus códigos tienen una cabecera asociada que convierte el error en algo accionable.

El par 401 y 403 es la pregunta clásica y se resuelve con dos frases: el 401 dice «no sé quién eres», y el 403 dice «sé quién eres y aun así no puedes». Un ejemplo del 405 en esta plataforma: la dirección de un intento admite GET, pero si alguien intenta un POST contra ella el servidor responde 405 y devuelve Allow con los métodos que sí valen.

Aquí la petición era correcta y el fallo está del otro lado. Distinguirlos importa porque cada uno apunta a una pieza distinta de la infraestructura.

502, 503 y 504 hablan de intermediarios y de disponibilidad, no del código de la aplicación. El que señala a la aplicación es el 500.