Guía de inglés para developers
Códigos de estado HTTP que todo developer debería conocer
27 de julio de 2026
Entender los códigos de estado HTTP es esencial para depurar APIs, escribir respuestas de error claras y comunicarte con tus compañeros de equipo. Esta guía cubre los códigos más comunes con definiciones en inglés accesible y escenarios reales de desarrollo.
2xx: Éxito
El servidor recibió la solicitud, la entendió y la procesó correctamente. Estos son los códigos que quieres ver.
OK
La solicitud fue exitosa. El servidor devuelve el recurso solicitado en el cuerpo de la respuesta. Es el estado de éxito por defecto para solicitudes GET, PUT y PATCH.
Escenario real
GET /api/users/42 returns 200 with the user object in the body.
Created
Se creó un nuevo recurso correctamente. El servidor suele incluir un encabezado Location apuntando al nuevo recurso. Úsalo para solicitudes POST que crean registros.
Escenario real
POST /api/users with a valid body returns 201 and a Location: /api/users/43 header.
No Content
La solicitud fue exitosa pero no hay nada que devolver en el cuerpo. Es común para operaciones DELETE y solicitudes PUT en las que el cliente ya conoce el nuevo estado.
Escenario real
DELETE /api/users/42 returns 204 with an empty body — the record is gone.
3xx: Redirección
El recurso se ha movido o el cliente necesita dar un paso adicional para completar la solicitud. El navegador o el cliente HTTP suele gestionarlos automáticamente.
Moved Permanently
El recurso tiene una nueva URL permanente. Los motores de búsqueda actualizan su índice a la nueva URL. Úsalo cuando renombras un endpoint o migras un sitio web y necesitas que se transfiera el valor SEO.
Escenario real
GET /api/v1/customers redirects 301 to /api/v2/customers after an API version bump.
Found
El recurso está temporalmente en una URL diferente. A diferencia del 301, la URL original sigue siendo válida. Los clientes deben seguir usando la URL original en futuras solicitudes. Es común en flujos de login OAuth.
Escenario real
GET /auth/google redirects 302 to Google's OAuth consent screen.
Not Modified
El recurso no ha cambiado desde la versión que el cliente ya tiene en caché. El servidor no envía cuerpo: el cliente usa su copia en caché. Esto reduce el ancho de banda y acelera las solicitudes repetidas.
Escenario real
GET /api/config with an If-None-Match header returns 304 when the config has not changed.
4xx: Errores del cliente
Algo está mal en la solicitud en sí. El servidor la entendió, pero no la cumplirá por un problema del lado del cliente: datos incorrectos, autenticación faltante o un recurso que no existe.
Bad Request
El servidor no puede procesar la solicitud porque la sintaxis es incorrecta o falta un campo obligatorio. Siempre incluye un mensaje de error en el cuerpo de la respuesta explicando qué está mal.
Escenario real
POST /api/orders with a missing "quantity" field returns 400: { "error": "quantity is required" }.
Unauthorized
El cliente no está autenticado. El nombre es confuso: en realidad significa no autenticado. Falta un token válido o el token expiró. El cliente debe iniciar sesión y reintentar.
Escenario real
GET /api/orders without an Authorization header returns 401 with a WWW-Authenticate hint.
Forbidden
El cliente está autenticado pero no tiene permiso para acceder a este recurso. A diferencia del 401, volver a enviar credenciales no ayudará. Es un error de autorización, no de autenticación.
Escenario real
GET /api/admin/users by a regular user returns 403 — they are logged in but not an admin.
Not Found
El recurso solicitado no existe en esta URL. Puede haber sido eliminado, nunca haber existido, o la URL es incorrecta. También se usa para ocultar la existencia de recursos privados a usuarios no autorizados.
Escenario real
GET /api/users/9999 returns 404 when no user with ID 9999 exists in the database.
Conflict
La solicitud entra en conflicto con el estado actual del servidor. Causas típicas: intentar crear un recurso que ya existe, o un conflicto de bloqueo optimista cuando dos clientes actualizan el mismo registro.
Escenario real
POST /api/users with an email that is already registered returns 409: { "error": "email already in use" }.
Unprocessable Entity
El cuerpo de la solicitud es sintácticamente válido (a diferencia del 400) pero semánticamente incorrecto. Los datos no pueden procesarse porque violan reglas de negocio o restricciones de validación. FastAPI y Rails lo usan mucho.
Escenario real
POST /api/transfers with { amount: -50 } returns 422 — JSON is valid, but a negative amount makes no sense.
Too Many Requests
El cliente ha enviado demasiadas solicitudes en un período de tiempo determinado. El servidor está limitando la tasa del cliente. La respuesta suele incluir un encabezado Retry-After indicando cuánto tiempo esperar.
Escenario real
Hitting a public API 100 times in one second returns 429 with Retry-After: 60.
5xx: Errores del servidor
El servidor no pudo cumplir una solicitud válida. El problema está del lado del servidor, no es culpa del cliente. Estos siempre justifican investigación y deben activar alertas en producción.
Internal Server Error
Algo salió mal de forma inesperada en el servidor. Es el código genérico para excepciones no manejadas. Si lo ves en producción, hay un bug. Revisa tus logs de inmediato.
Escenario real
An unhandled NullPointerException in the order service causes every POST /api/orders to return 500.
Bad Gateway
Un servidor que actúa como puerta de enlace recibió una respuesta no válida de un servidor upstream. Es común cuando tu load balancer o reverse proxy no puede llegar al backend, o cuando el backend falla a mitad de la respuesta.
Escenario real
Your Nginx proxy returns 502 when the Node.js process behind it crashes during a deploy.
Service Unavailable
El servidor no puede manejar solicitudes temporalmente. Causas típicas: el servidor está sobrecargado, iniciándose o en modo de mantenimiento. Suele ser temporal. El encabezado Retry-After indica a los clientes cuándo reintentar.
Escenario real
During a database migration, the API returns 503 with Retry-After: 300 to tell clients to wait 5 minutes.
Gateway Timeout
Un servidor que actúa como puerta de enlace no recibió respuesta a tiempo de un servidor upstream. Similar al 502, pero el servidor upstream no respondió en absoluto, en lugar de responder con un error.
Escenario real
Your API gateway returns 504 when a slow database query exceeds the 30-second timeout.
Puntos clave
2xx significa éxito. 201 Created es más preciso que 200 OK cuando creas un nuevo recurso.
401 significa no autenticado (sin credenciales válidas). 403 significa no autorizado (credenciales válidas, pero sin permiso). No son lo mismo.
400 Bad Request significa que la sintaxis es incorrecta. 422 Unprocessable Entity significa que la sintaxis es correcta pero los datos violan reglas de negocio.
Los errores 5xx son siempre bugs del servidor. Si los ves en producción, revisa tus logs de inmediato.
429 Too Many Requests significa que estás siendo limitado por rate limiting. Siempre implementa exponential backoff en tu cliente HTTP.
304 Not Modified es tu aliado para el caché. Usa los encabezados ETag e If-None-Match para evitar enviar datos que el cliente ya tiene.
Related articles
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.