API REST

Una API REST expone los datos de una aplicación como recursos, por ejemplo /orders o /orders/42, y permite a los clientes actuar sobre ellos con métodos HTTP estándar. REST (Representational State Transfer, transferencia de estado representacional) es un estilo arquitectónico más que un estándar, así que las APIs reales lo siguen en distintos grados. Las ideas centrales son URLs orientadas a recursos, un uso con sentido de los métodos y códigos de estado HTTP, y solicitudes sin estado (stateless): cada solicitud incluye todo lo que el servidor necesita, autenticación incluida.

Ejemplo

Solicitud	Significado	Éxito típico
GET /orders?status=open	Listar los pedidos abiertos	200 OK
GET /orders/42	Leer un pedido	200 OK
POST /orders	Crear un pedido	201 Created + Location header
PUT /orders/42	Reemplazar el pedido	200 OK o 204 No Content
PATCH /orders/42	Cambiar algunos campos	200 OK
DELETE /orders/42	Eliminar el pedido	204 No Content

Un test con REST Assured 5:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .baseUri("https://api.example.com")
    .header("Accept", "application/json")
.when()
    .get("/orders/42")
.then()
    .statusCode(200)
    .body("id", equalTo(42))
    .body("status", equalTo("open"));

Qué probar en una API REST

• Códigos de estado para el éxito y para cada ruta de fallo: falta de autenticación, rol incorrecto, cuerpo no válido, id desconocido, conflictos.
• Cuerpo y esquema de la respuesta: nombres y tipos de campos, campos obligatorios, y que no se expongan campos sensibles.
• Cabeceras: Content-Type, Location después de una creación, y cabeceras de caché y CORS cuando corresponda.
• Semántica de los métodos: GET no tiene efectos secundarios; PUT y DELETE son idempotentes.
• Autorización a nivel de objeto: el usuario A no debe poder leer un /orders/{id} que pertenece al usuario B.
• Paginación, filtrado y ordenación, incluidas las páginas vacías y la última página.

En qué se diferencia de otros estilos de API

GraphQL suele exponer un único endpoint donde el cliente describe los datos que quiere, y a menudo devuelve 200 incluso cuando parte de la consulta falló, así que los tests deben inspeccionar el campo errors. SOAP usa sobres XML y un contrato formal WSDL. gRPC usa HTTP/2 y Protocol Buffers. Una suite de tests REST se apoya mucho en el propio HTTP, y por eso los fundamentos de HTTP son tan importantes para quienes prueban APIs.