Seite 2 - REST-API

Ein Skript, das bei der ersten 429-Antwort einfach abbricht, ist keine Automatisierung, sondern eine tickende Zeitbombe. Rate-limitierte API-Abfragen mit Retry in Bash respektieren Retry-After-Header, nutzen exponentielles Backoff mit Jitter und liefern zuverlässige Ergebnisse, auch bei strengen API-Limits.

Sobald mehrere Microservices eigene REST-APIs anbieten, wiederholt sich dieselbe Querschnittslogik überall: Authentifizierung prüfen, Rate-Limits durchsetzen, Requests loggen. Ein API-Gateway zieht diese Logik an eine zentrale Stelle, mit klaren Vorteilen, aber auch neuen Fragen zu Ausfallsicherheit und Latenz.

Der klassische OAuth2 Authorization Code Flow setzt voraus, dass der Client einen Browser öffnen und einen Redirect empfangen kann, was für ein CLI-Tool, einen Smart-TV oder ein IoT-Gerät ohne Bildschirmtastatur praktisch nicht funktioniert. Der OAuth2 Device Authorization Grant, spezifiziert in RFC 8628, löst dieses Problem, indem der Nutzer die Autorisierung auf einem separaten Gerät mit vollwertigem Browser durchführt, während das ursprüngliche Gerät im Hintergrund auf das Ergebnis wartet.

Wer API-Tests in einem separaten Tool pflegt und E2E-Tests in Cypress oder Playwright, verdoppelt Wartungsaufwand und verliert Kontext zwischen beiden Welten. Mit cy.request() und der Playwright APIRequestContext lassen sich Testdaten in Millisekunden statt über Formulare aufbauen, Auth-Sessions zwischen API und Browser teilen und ganze Testsuiten spürbar beschleunigen, ohne die Zuverlässigkeit zu verlieren.

Nicht jede asynchrone Anforderung braucht Webhooks. Polling ist manchmal die richtigere Wahl. Und REST Callbacks existieren als Hybridansatz, den viele nicht kennen. Wer den Unterschied versteht, trifft bessere Architekturentscheidungen – und baut keine Webhook-Infrastruktur auf, wo ein einfaches 30-Sekunden-Polling die sauberere Lösung wäre.

Sobald ein System asynchrone Nachrichten über RabbitMQ, Kafka oder WebSockets austauscht, fehlt eine Beschreibung wie OpenAPI: Welche Nachrichten fließen über welchen Kanal, in welchem Format, mit welcher Payload-Struktur. AsyncAPI schließt genau diese Lücke, mit einer Spezifikation, die sich bewusst an OpenAPI orientiert.

Paginierung wirkt zunächst wie ein triviales Detail, entscheidet in API Platform aber über Antwortzeiten bei großen Tabellen, Konsistenz während paralleler Schreibzugriffe und Ergonomie für Client Entwickler. Wer nur die Standard Offset Paginierung kennt, verschenkt Performance und riskiert doppelte oder fehlende Datensätze bei stark frequentierten Endpunkten.

Wer HTTP-Clients testet, ohne echte Netzwerkaufrufe auszufuehren, braucht realistische Test Doubles. Der Guzzle MockHandler erlaubt es, Erfolgsantworten, Fehlerstatus, Timeouts und kaputte JSON-Payloads praezise zu simulieren und so alle Codepfade eines Clients zuverlaessig abzudecken.

Ein Breaking Change in einer REST-API ist kein Versionsproblem – es ist ein Vertragsproblem. Wenn Konsumenten sich auf ein Schema verlassen und der Provider es still verändert, entstehen Produktionsausfälle ohne Vorwarnung. Technische Absicherung bedeutet: Breaking Changes automatisch erkennen, Deprecation-Zyklen durchsetzen und Consumer-Driven Contract Tests als strukturelles Sicherheitsnetz einzusetzen.

HATEOAS ist das Prinzip, das REST von einem einfachen HTTP-Datentransport trennt – und gleichzeitig das meistdiskutierte und seltenst umgesetzte REST-Constraint. Dieser Artikel erklärt, was Hypermedia wirklich bedeutet, welche Formate sich bewährt haben und wann der Pragmatismus über die Reinheit geht.