REST-API

Eine REST-API stellt die Daten einer Anwendung als Ressourcen bereit, etwa /orders oder /orders/42, und lässt Clients mit Standard-HTTP-Methoden darauf zugreifen. REST (Representational State Transfer) ist eher ein Architekturstil als ein Standard, daher folgen reale APIs ihm in unterschiedlichem Maß. Die Kernideen sind ressourcenorientierte URLs, eine sinnvolle Verwendung von HTTP-Methoden und Statuscodes sowie zustandslose Anfragen: Jede Anfrage enthält alles, was der Server braucht, einschließlich der Authentifizierung.

Beispiel

Anfrage	Bedeutung	Typischer Erfolg
GET /orders?status=open	Offene Bestellungen auflisten	200 OK
GET /orders/42	Eine Bestellung lesen	200 OK
POST /orders	Eine Bestellung anlegen	201 Created + Location-Header
PUT /orders/42	Die Bestellung ersetzen	200 OK oder 204 No Content
PATCH /orders/42	Einige Felder ändern	200 OK
DELETE /orders/42	Die Bestellung löschen	204 No Content

Ein Test mit 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"));

Was Sie an einer REST-API testen sollten

• Statuscodes für den Erfolgsfall und jeden Fehlerpfad: fehlende Authentifizierung, falsche Rolle, ungültiger Body, unbekannte ID, Konflikte.
• Response-Body und Schema: Feldnamen, Typen, Pflichtfelder und dass sensible Felder nicht offengelegt werden.
• Header: Content-Type, Location nach dem Anlegen, Caching- und CORS-Header, wo relevant.
• Semantik der Methoden: GET hat keine Seiteneffekte, PUT und DELETE sind idempotent.
• Autorisierung auf Objektebene: Nutzer A darf /orders/{id} von Nutzer B nicht lesen können.
• Paginierung, Filterung und Sortierung, einschließlich leerer und letzter Seiten.

Wie sie sich von anderen API-Stilen unterscheidet

GraphQL stellt meist einen einzigen Endpunkt bereit, an dem der Client die gewünschten Daten beschreibt, und liefert oft 200, selbst wenn ein Teil der Abfrage fehlgeschlagen ist; Tests müssen daher das Feld errors prüfen. SOAP verwendet XML-Envelopes und einen formalen WSDL-Vertrag. gRPC nutzt HTTP/2 und Protocol Buffers. Eine REST-Testsuite stützt sich stark auf HTTP selbst, und deshalb sind HTTP-Grundlagen für API-Tester so wichtig.