API REST

Une API REST expose les données d’une application sous forme de ressources, comme /orders ou /orders/42, et permet aux clients d’agir dessus avec les méthodes HTTP standard. REST (Representational State Transfer) est un style d’architecture plutôt qu’un standard : les API réelles le suivent donc plus ou moins fidèlement. Les idées centrales sont des URL orientées ressources, un usage pertinent des méthodes et des codes de statut HTTP, et des requêtes sans état (stateless) : chaque requête contient tout ce dont le serveur a besoin, y compris l’authentification.

Exemple

Requête	Signification	Succès typique
GET /orders?status=open	Lister les commandes ouvertes	200 OK
GET /orders/42	Lire une commande	200 OK
POST /orders	Créer une commande	201 Created + en-tête Location
PUT /orders/42	Remplacer la commande	200 OK ou 204 No Content
PATCH /orders/42	Modifier certains champs	200 OK
DELETE /orders/42	Supprimer la commande	204 No Content

Un test avec 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"));

Que tester dans une API REST

• Les codes de statut du succès et de chaque chemin d’échec : authentification absente, mauvais rôle, corps invalide, id inconnu, conflits.
• Le corps de réponse et le schéma : noms des champs, types, champs obligatoires, et absence d’exposition des champs sensibles.
• Les en-têtes : Content-Type, Location après une création, en-têtes de cache et CORS le cas échéant.
• La sémantique des méthodes : GET n’a pas d’effet de bord, PUT et DELETE sont idempotents.
• L’autorisation au niveau de l’objet : l’utilisateur A ne doit pas pouvoir lire une ressource /orders/{id} appartenant à l’utilisateur B.
• La pagination, le filtrage et le tri, y compris les pages vides et la dernière page.

Ce qui la distingue des autres styles d’API

GraphQL expose généralement un seul endpoint où le client décrit les données qu’il veut, et renvoie souvent 200 même quand une partie de la requête a échoué : les tests doivent donc inspecter le champ errors. SOAP utilise des enveloppes XML et un contrat WSDL formel. gRPC utilise HTTP/2 et Protocol Buffers. Une suite de tests REST s’appuie fortement sur HTTP lui-même, c’est pourquoi les fondamentaux d’HTTP comptent autant pour les testeurs d’API.