Códigos de estado de éxito 2xx

Qué cubre la familia 2xx

El éxito no es una única condición. Un navegador que obtiene una página, un formulario que publica un registro nuevo, una tarea en segundo plano que acepta trabajo para más tarde, y un reproductor de vídeo que pide los bytes del 5.000.000 al 6.000.000 son todos casos de éxito, pero necesitan respuestas distintas. Eso es lo que codifican los códigos 2xx. El RFC 9110 define del 200 al 206; un puñado más vienen de extensiones como WebDAV.

Para el tráfico web del día a día, la abrumadora mayoría de las respuestas correctas son simples 200. El resto importa sobre todo a los clientes de API, las rutas de subida y la entrega de medios.

Los códigos 2xx y cuándo aparece cada uno

• 200 OK. El éxito estándar. Para un GET el cuerpo es el recurso pedido; para un POST es el resultado de la acción. Esto es lo que devuelve una página sana.
• 201 Created. La petición creó un recurso nuevo. Una API bien diseñada devuelve 201 con una cabecera Location que apunta a lo que acaba de crear. Se ve en registros de API, rara vez en un navegador.
• 202 Accepted. La petición se aceptó para procesarse pero no ha terminado. Se usa para trabajo asíncrono como una importación masiva o un informe que se va a generar en segundo plano. Un 202 es una promesa, no un resultado, así que el cliente normalmente tiene que sondear una URL de estado.
• 203 Non-Authoritative Information. Éxito, pero un proxy u otro intermediario que transforma modificó la respuesta por el camino. Poco habitual en sitios modernos.
• 204 No Content. Éxito sin ningún cuerpo de forma deliberada. Típico de un DELETE, un PUT que se guardó sin necesitar devolver nada, o un endpoint de autoguardado. El navegador se queda en la página actual.
• 205 Reset Content. Éxito, y el cliente debería reiniciar el formulario o la vista del documento que envió la petición. Se usa raramente en la práctica.
• 206 Partial Content. El servidor está devolviendo solo el rango de bytes que pidió el cliente con una cabecera Range. Así es como funcionan la búsqueda en vídeo, las descargas reanudables y las transferencias de archivos grandes, así que un 206 es normal y esperable en endpoints de medios.
• 207 Multi-Status y 208 Already Reported vienen de WebDAV, donde una petición puede actuar sobre muchos recursos y necesita reportar un resultado por recurso. 226 IM Used viene de la extensión de codificación delta y se despliega muy raramente.

Por qué un 200 no demuestra que la página esté sana

Un código de estado describe el resultado de la transacción HTTP, no la corrección de lo que volvió. Una página de marca de "estamos en mantenimiento" se sirve con un 200. También lo hace una página de error de aplicación, cuando el framework atrapa la excepción y renderiza una disculpa amistosa a través de la plantilla normal con su estado por defecto. Una página renderizada del lado del cliente cuya llamada a la API falló devuelve 200 para la cáscara vacía alrededor del contenido que falta, y un 404 suave devuelve 200 para un mensaje de "página no encontrada", que además confunde a los buscadores.

En todos esos casos una comprobación de código de estado reporta éxito mientras tus visitantes ven un sitio roto. La solución es una comprobación de contenido: haz una aserción de que una cadena conocida está presente en el cuerpo de la respuesta, o de que una cadena de error conocida está ausente, además de comprobar el código.

Cómo comprobar lo que devuelve de verdad una URL

1. Pide solo cabeceras y lee la línea de estado:

   curl -sI https://example.com/ | head -n 1

2. Si es un 200, obtén también el cuerpo y confirma que contiene lo que debería. Busca con grep una cadena que solo aparezca en una página que funciona, como un encabezado o una marca de pie de página.
3. Para un endpoint de API, verifica que el código coincide con la semántica: una creación debería ser 201 con un Location, una eliminación debería ser 204, y una tarea de larga duración debería ser 202 con una URL de estado.
4. Para medios, confirma que el servidor anuncia Accept-Ranges: bytes y responde a una petición con rango con un 206. Si responde 200 a una petición con rango, la búsqueda será lenta porque se reenvía el archivo entero.
5. Repite la comprobación desde una red distinta. Una respuesta que es 200 para ti y un error en otro sitio señala al DNS, la CDN o el enrutamiento geográfico y no a la aplicación.

Comprobar el cuerpo, no solo el código

Una comprobación de código de estado va a reportar un sitio en verde que está sirviendo una página de error, así que combínala con una aserción de contenido sobre la misma petición. HostTracker monitoriza sitios web desde 2004 y ofrece 13 tipos de monitor, así que una URL se puede vigilar por su código de estado, por una palabra clave en la respuesta y por el tiempo de respuesta a la vez. Pasa una URL por la herramienta de comprobación HTTP para ver el código y las cabeceras que devuelve ahora mismo, y luego lee qué significa de verdad un 200 OK y los códigos de error de servidor 5xx para los fallos que puede esconder un 200.