Código de estado HTTP

Un código de estado HTTP es la respuesta breve del servidor a una petición. El primer dígito indica la clase: 1xx informativa, 2xx éxito, 3xx redirección, 4xx error del cliente (la petición era incorrecta) y 5xx error del servidor (puede que la petición estuviera bien, pero el servidor falló). Comprobar el código de estado exacto suele ser la primera verificación de cualquier prueba de API.

Los códigos que más usan los testers

Código	Significado	Uso típico
200 OK	Éxito con cuerpo	GET, o una actualización que devuelve el recurso
201 Created	Se creó un recurso	POST, con una cabecera Location
204 No Content	Éxito, sin cuerpo	DELETE, algunos PUT
301 / 302 / 304	Movido, encontrado en otro sitio, no modificado	Redirecciones y caché
400 Bad Request	Petición mal formada o inválida	JSON roto, tipos incorrectos
401 Unauthorized	No autenticado	Token ausente, caducado o inválido
403 Forbidden	Autenticado pero sin permiso	Usuario válido, rol incorrecto
404 Not Found	No existe el recurso	Id desconocido, u ocultar uno prohibido
409 Conflict	Choca con el estado actual	Email duplicado, conflicto de versiones
422 Unprocessable Content	Bien formada pero no pasa la validación	Incumplimiento de reglas de negocio
429 Too Many Requests	Se superó el límite de peticiones	A menudo con Retry-After
500 / 502 / 503 / 504	Error del servidor, bad gateway, no disponible, timeout del gateway	Bugs e infraestructura

401 frente a 403

A pesar de su nombre, 401 Unauthorized trata de la autenticación: el servidor no sabe quién eres. La solución es iniciar sesión o enviar un token válido, y la respuesta debería incluir una cabecera WWW-Authenticate. 403 Forbidden trata de la autorización: el servidor sabe quién eres y no tienes permiso para hacer esto. Volver a iniciar sesión no servirá. Una suite de pruebas debería cubrir ambos casos: sin token, con un token caducado y con un token válido de un usuario sin el permiso adecuado.

Errores comunes

• Comprobar solo el 200. La mayoría de los defectos están en los caminos de error. Una entrada inválida debería recibir un 4xx; un 500 significa una entrada no controlada y merece un reporte de bug.
• Errores con estado 200. Un mensaje de error dentro de un cuerpo con 200 rompe a los clientes y a la monitorización.
• Convenciones inconsistentes. Algunas APIs usan 400 para cualquier entrada incorrecta; otras reservan 422 para los fallos de validación. Cualquiera de las dos vale; mezclarlas dentro de una misma API es el bug.