Metodos HTTP, Codigos de Estado y Cabeceras

Metodos HTTP #

Los metodos HTTP (tambien llamados verbos) definen la accion a realizar sobre un recurso. Entenderlos en profundidad es fundamental para el testing de API porque usar el metodo incorrecto o testear el comportamiento equivocado es uno de los errores mas comunes.

GET — Recuperar Datos #

Los GET requests recuperan datos sin modificar nada en el servidor. Son tanto seguros (sin efectos secundarios) como idempotentes (mismo resultado sin importar cuantas veces se llame).

GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

Checklist de testing para GET:

• Retorna 200 OK con datos para recursos existentes
• Retorna 404 Not Found para recursos inexistentes
• Nunca modifica el estado del servidor (verificar base de datos sin cambios despues del GET)
• Soporta filtrado via query parameters
• Retorna paginacion adecuada para endpoints de lista
• El formato de respuesta coincide con el header Accept

POST — Crear Nuevos Recursos #

POST envia datos al servidor para crear un nuevo recurso. No es seguro ni idempotente — llamarlo multiples veces puede crear multiples recursos.

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "developer"
}

Checklist de testing para POST:

• Retorna 201 Created con el nuevo recurso (incluyendo ID generado)
• Retorna header Location apuntando al nuevo recurso
• Valida campos requeridos (retorna 400 para datos faltantes)
• Rechaza entradas duplicadas apropiadamente (409 Conflict)
• Maneja tipos de datos invalidos graciosamente

PUT — Reemplazar Recurso Completo #

PUT reemplaza el recurso completo con los datos proporcionados. Es idempotente — enviar el mismo PUT request multiples veces produce el mismo resultado.

PUT /api/users/42 HTTP/1.1
Content-Type: application/json

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com",
  "role": "senior-developer"
}

Checklist de testing para PUT:

• Reemplaza todos los campos (campos no incluidos se eliminan o establecen en valores por defecto)
• Retorna 200 OK con recurso actualizado o 204 No Content
• Crea el recurso si no existe (algunas APIs retornan 201)
• Es idempotente — el mismo request dos veces produce resultado identico

PATCH — Actualizacion Parcial #

PATCH aplica modificaciones parciales a un recurso. Solo se actualizan los campos incluidos en el request.

PATCH /api/users/42 HTTP/1.1
Content-Type: application/json

{
  "role": "senior-developer"
}

Checklist de testing para PATCH:

• Solo actualiza los campos especificados
• Los campos no mencionados permanecen sin cambios
• Retorna 200 OK con el recurso actualizado
• Maneja nombres de campos invalidos apropiadamente

DELETE — Eliminar un Recurso #

DELETE elimina el recurso especificado del servidor. Es idempotente — eliminar un recurso ya eliminado no deberia causar un error (aunque el status code puede diferir).

DELETE /api/users/42 HTTP/1.1
Authorization: Bearer <token>

Checklist de testing para DELETE:

• Retorna 204 No Content (o 200 OK con confirmacion)
• El recurso ya no es accesible despues de la eliminacion (GET retorna 404)
• DELETE subsecuente del mismo recurso retorna 404 o 204
• El comportamiento en cascada es correcto (recursos relacionados manejados adecuadamente)

Metodos Menos Comunes #

Codigos de Estado HTTP #

Los codigos de estado son numeros de tres digitos que comunican el resultado de un API request. Se organizan en cinco clases.

1xx — Informacional #

Rara vez vistos en testing de API:

• 100 Continue — servidor recibio headers, cliente debe enviar body
• 101 Switching Protocols — servidor cambiando a WebSocket

2xx — Exito #

3xx — Redireccion #

4xx — Errores del Cliente #

5xx — Errores del Servidor #

Headers HTTP #

Los headers transportan metadata sobre el request o response. Son pares clave-valor enviados junto al body.

Headers de Request Esenciales #

Authorization — transporta credenciales de autenticacion:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
Authorization: Basic dXNlcjpwYXNzd29yZA==
Authorization: ApiKey sk-1234567890abcdef

Content-Type — describe el formato del body del request:

Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data; boundary=----FormBoundary

Accept — dice al servidor que formato de respuesta prefiere el cliente:

Accept: application/json
Accept: application/xml
Accept: text/html, application/json;q=0.9

Headers de Response Esenciales #

Content-Type — describe el formato del body de la respuesta:

Content-Type: application/json; charset=utf-8

Cache-Control — directivas de caching:

Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: public, max-age=3600

Headers de Rate Limit (no estandar pero ampliamente usados):

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1625097600

Headers CORS — Cross-Origin Resource Sharing:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type

Headers de Seguridad para Testear #

Estrategias de Testing #

Matriz de Verificacion de Status Codes #

Crea una matriz para cada endpoint mapeando inputs a status codes esperados:

Checklist de Testing de Headers #

1. Enviar requests sin headers requeridos — esperar 400 o 401
2. Enviar requests con Content-Type invalido — esperar 415 Unsupported Media Type
3. Verificar que los headers CORS permitan los origenes esperados
4. Verificar que los headers de seguridad esten presentes en todas las respuestas
5. Verificar que los headers de rate limit sean precisos y consistentes
6. Testear content negotiation del header Accept

Ejercicio Practico #

Usando JSONPlaceholder o cualquier API de prueba:

1. Testing de metodos: Envia GET, POST, PUT, PATCH y DELETE a /posts/1. Documenta el status code y la respuesta para cada uno.
2. Busqueda de status codes: Encuentra requests que disparen al menos 5 status codes diferentes (200, 201, 204, 404 y uno mas).
3. Inspeccion de headers: Para un GET request a /posts, lista todos los headers de respuesta e identifica cuales se relacionan con caching, tipo de contenido y seguridad.
4. PUT vs PATCH: Actualiza un post con PUT (enviando todos los campos) y luego con PATCH (enviando un campo). Compara los resultados.

Puntos Clave #

• Los metodos HTTP definen la accion: GET (leer), POST (crear), PUT (reemplazar), PATCH (actualizar), DELETE (eliminar)
• Los metodos seguros (GET, HEAD, OPTIONS) nunca modifican el estado del servidor; los metodos idempotentes (GET, PUT, DELETE) producen el mismo resultado al ser llamados multiples veces
• Los status codes comunican resultados: 2xx exito, 4xx error del cliente, 5xx error del servidor — cada codigo tiene significado especifico
• Los headers transportan metadata critica: autenticacion, formato de contenido, caching, seguridad y rate limiting
• Un enfoque sistematico de testing — mapeando endpoints a metodos esperados, status codes y headers — asegura cobertura completa