El método, el código de estado y los encabezados son tres de las señales más útiles de las solicitudes y respuestas HTTP. A menudo QA puede comprender gran parte de un problema antes de leer el cuerpo, simplemente examinando estos tres elementos.
Los principiantes suelen centrarse en los datos de la respuesta: si llegó JSON y si un campo está presente o ausente. Importa, pero antes hay que entender algo más fundamental: qué intentaba hacer el cliente, cómo lo interpretó el servidor y qué contexto técnico acompañaba la solicitud. El método, el código de estado y los encabezados proporcionan esa información.
Aprender a interpretarlos con confianza acelera mucho la investigación de defectos.
Método
El método HTTP expresa la intención del cliente: qué intentaba hacer, no el resultado.
- →GET — recuperar datos.
- →POST — crear una entidad o activar una acción.
- →PUT — sustituir un recurso por completo.
- →PATCH — actualizar parte de un recurso.
- →DELETE — eliminar un recurso o marcarlo como inactivo.
En la práctica, los equipos no siempre utilizan los métodos perfectamente y debes tenerlo en cuenta. Aun así, QA necesita comprender su significado. Si un cliente envía GET y los datos cambian como resultado, merece atención. Crear una entidad mediante GET incumple convenciones de API y expectativas sobre caché, repetibilidad y seguridad del método.
Otro concepto importante es la idempotencia. Algunos métodos pueden repetirse sin modificar el resultado previsto; otros no. Esto importa para reintentos, clics repetidos, redes inestables y pruebas automatizadas. Enviar accidentalmente dos veces la misma solicitud puede tener consecuencias distintas con POST y PUT, y las comprobaciones deben considerarlo.
Código de estado
Un código de estado resume brevemente cómo se procesó una solicitud desde el punto de vista técnico. No lo explica todo, pero identifica inmediatamente la categoría del resultado.
- →1xx — información técnica provisional.
- →2xx — la solicitud se procesó correctamente.
- →3xx — se requiere una redirección o un paso adicional.
- →4xx — problema con la solicitud, los datos o el acceso del cliente.
- →5xx — error del servidor.
Estas categorías bastan para que QA se haga una primera idea de la situación. Un probador competente va más allá y comprende los códigos individuales más habituales.
- →200 OK — la solicitud se completó correctamente.
- →201 Created — se creó una entidad.
- →204 No Content — la operación se completó correctamente, sin cuerpo de respuesta.
- →301 / 302 / 307 / 308 — redirecciones.
- →400 Bad Request — el servidor no acepta la solicitud en su forma actual.
- →401 Unauthorized — el cliente no está autenticado correctamente.
- →403 Forbidden — se reconoce al cliente, pero no tiene acceso.
- →404 Not Found — no se encontró el recurso.
- →409 Conflict — conflicto de estado.
- →422 Unprocessable Content — la estructura de la solicitud es válida, pero su significado de negocio o sus datos no superan la validación.
- →500 Internal Server Error — error interno del servidor.
- →502, 503, 504 — problemas entre servicios, de sobrecarga o de disponibilidad.
El objetivo es comprender cómo ayudan los códigos a aislar problemas, no memorizar toda la tabla.
Por ejemplo, 401 y 403 significan cosas distintas. Un 404 puede significar «esta URL no existe» o «esta entidad no existe». Un 200 no garantiza que la lógica de negocio sea correcta. Un 500 no identifica el punto exacto del fallo, pero muestra rápidamente que el problema va más allá del formulario del frontend.
Por qué 200 OK garantiza poco por sí solo
Una de las trampas más habituales es suponer que, si una API devuelve 200, todo está bien.
- →Devolver datos incorrectos.
- →Devolver una lista vacía cuando se esperaba un objeto.
- →Ocultar un error de negocio en un campo de error.
- →Ejecutar una operación solo parcialmente.
- →Devolver datos obsoletos de una caché.
Por eso QA siempre interpreta el código junto con el cuerpo de la respuesta y el contexto del escenario. El éxito técnico no implica necesariamente un comportamiento correcto del producto.
Encabezados
Los encabezados aportan contexto adicional a solicitudes y respuestas. A menudo parecen secundarios hasta que investigas problemas reales.
- →Tipo de datos (Content-Type).
- →Formato de respuesta esperado (Accept).
- →Autorización (Authorization).
- →Cookies.
- →Idioma o configuración regional.
- →Caché (Cache-Control, ETag, If-None-Match).
- →Identificadores de correlación.
- →Políticas de CORS.
- →Políticas de seguridad.
Los encabezados son especialmente importantes para QA porque suelen explicar errores aparentemente «extraños».
- →El backend espera application/json, pero el cliente envía otro Content-Type.
- →Existe un token, pero se envió en el encabezado equivocado.
- →Una cookie no llegó o no se guardó.
- →La caché devolvió una versión antigua de los datos.
- →El navegador bloqueó una solicitud por CORS.
- →Un proxy inverso reescribió algunos encabezados.
- →La solicitud especifica una configuración regional y la respuesta usa otra.
Los encabezados son una parte sustancial del protocolo: transportan contexto esencial. Sin él, una solicitud puede ser técnicamente válida y lógicamente incorrecta.
Cómo ayuda esto a QA en la práctica
Considera un defecto: el usuario no puede guardar su perfil.
La UI solo muestra un mensaje de error. Las señales HTTP pueden revelar situaciones muy distintas:
- →Se envió una solicitud PATCH, pero el servidor devolvió 400 porque un campo era inválido.
- →La solicitud se envió como POST aunque el backend espera PATCH.
- →El servidor devolvió 403 porque el rol carece del permiso necesario.
- →El cliente envió un Content-Type incorrecto.
- →La operación se completó correctamente, pero el frontend no sabe gestionar 204 No Content.
- →La solicitud funciona, pero la caché o una recarga de página muestra datos antiguos.
Todo ello puede parecer un único defecto de «el perfil no se guarda». Para el equipo son seis clases distintas de problemas. El método, el código de estado y los encabezados ayudan a identificar dónde investigar.
Qué debe comprobar QA
- →Qué método se utilizó.
- →A qué URL se llamó.
- →Qué encabezados clave se enviaron.
- →Qué código de estado se devolvió.
- →Qué encabezados regresaron.
- →Si el cuerpo corresponde al significado del escenario.
Con un enfoque sistemático, los registros de red dejan de parecer «ruido» y empiezan a revelar una estructura clara.
Ideas clave para QA
- →El método expresa la intención del cliente.
- →El código de estado informa del resultado técnico del procesamiento.
- →Los encabezados comunican contexto esencial de solicitudes y respuestas.
- →200 OK no garantiza que un escenario de negocio se completara correctamente.
- →Muchos defectos son más fáciles de aislar interpretando conjuntamente método, estado y encabezados.
Lecturas adicionales
- →En esta base de conocimiento: HTTP y HTTPS
- →En esta base de conocimiento: autenticación y autorización
- →Recurso externo: MDN: códigos de estado de respuestas HTTP