2. Pruebas de API

Los tipos comunes de API incluyen REST (Transferencia de Estado Representacional), SOAP (Protocolo Simple de Acceso a Objetos) y GraphQL. Menciona específicamente con cuáles tienes experiencia práctica.

SOAP es un protocolo que utiliza XML para el formato de mensajes y es más rígido. REST es un estilo arquitectónico que puede utilizar múltiples formatos (XML, JSON, HTML, etc.) y es generalmente más flexible y ligero.

PUT se utiliza para actualizar un recurso por completo (reemplazándolo). PATCH se utiliza para aplicar modificaciones parciales a un recurso.

El encadenamiento de API es el proceso de utilizar la respuesta de una solicitud de API como entrada (parámetro de solicitud) para una solicitud de API posterior. Esto es común al probar flujos de trabajo complejos.

Swagger se utiliza para documentación y pruebas de API a través de una interfaz de usuario. cURL es una herramienta de línea de comandos para transferir datos con URL. Explica tu uso específico, por ejemplo, 'Uso Swagger para entender los endpoints y cURL para verificar respuestas rápidamente desde la terminal'.

Inspecciona la pestaña de red en las herramientas de desarrollo del navegador. Si la solicitud de API envía datos correctos pero devuelve un error o datos incorrectos, es probable que sea un problema del backend. Si la API devuelve datos correctos pero la interfaz de usuario los muestra mal, es un problema del frontend.

No, un código de estado 204 No Content significa que el servidor procesó con éxito la solicitud, pero no devuelve ningún contenido.

1xx informativos, 2xx éxito (200 OK, 201 Created, 204 No Content), 3xx redirección (301/302/304), 4xx error de cliente (400, 401, 403, 404, 422), 5xx error de servidor (500, 502, 503). Como SDET verificas que la API devuelve el código correcto en cada escenario — un código incorrecto (p. ej. 200 en vez de 404) es un bug.

401 Unauthorized significa que no estás autenticado — el servidor no sabe quién eres, debes iniciar sesión. 403 Forbidden significa que estás autenticado pero no tienes permiso para ese recurso. Regla: 401 = ¿quién eres?, 403 = sé quién eres, pero no.

400 Bad Request significa que la petición está mal formada — JSON inválido, faltan campos obligatorios, formato incorrecto. 422 Unprocessable Entity significa que el formato es correcto pero los valores incumplen reglas de negocio (p. ej. email inválido o precio negativo). Ambos son errores de cliente, pero señalan bugs distintos.

Seguro = no cambia el estado del servidor: GET, HEAD, OPTIONS. Idempotente = llamarlo N veces tiene el mismo efecto que una: GET, HEAD, OPTIONS, PUT, DELETE. POST no es ninguno (cada llamada puede crear un recurso). PATCH no se garantiza idempotente. Importa para la lógica de reintentos y el diseño de tests.

PUT reemplaza el recurso completo — cualquier campo que omitas se pierde. PATCH actualiza solo los campos que envías, dejando el resto intacto. Trampa habitual en entrevistas: enviar PUT /users/42 solo con {nombre} borra email y edad; PATCH con {nombre} los conserva.

Usa nombres de recurso en plural (/users, no /getUser); sin verbos en la URL (el método HTTP es el verbo); anida recursos relacionados (/users/42/orders); usa query params para filtrar, ordenar y paginar (?categoria=x&page=2&sort=precio). Así: GET /users, POST /users, GET /users/42, PATCH /users/42, DELETE /users/42.

De más local a más global: data (CSV/JSON para ejecuciones data-driven), local (dentro del script de una request), environment (por dev/stg/prod), collection (compartida en toda la colección), global. Se referencian como {{baseUrl}}/users/{{userId}}. Pon los valores por entorno (baseUrl, credenciales) en environment y las constantes compartidas en collection.

Usa pm.test con pm.expect (Chai): pm.test('Status 200', () => pm.response.to.have.status(200)). Verifica el body JSON con pm.expect(body).to.have.property('id'), tipos con .to.be.a('number'), y que no se exponen secretos con .to.not.have.property('password'). También puedes aseverar que el tiempo de respuesta esté por debajo de un umbral.

La validación de schema comprueba la estructura de una respuesta — campos obligatorios, tipos, rangos, enums, valores permitidos — independientemente de los datos concretos. Detecta regresiones de contrato (un campo renombrado o ausente) que las aserciones de valor no ven. En la práctica usas JSON Schema con un validador como ajv o joi, comprobando que la respuesta encaja antes de verificar valores concretos.