Was ist eine REST-API?

REST (Representational State Transfer) ist ein Architekturstil für vernetzte Anwendungen, den Roy Fielding im Jahr 2000 in seiner Dissertation definiert hat. In der Theorie sind die Constraints protokollunabhängig; in der Praxis ist eine REST-API eine HTTP-API, die ein System als über URLs identifizierte Ressourcen modelliert, diese über standardisierte HTTP-Methoden manipuliert und dabei in der Regel JSON austauscht.

Die REST-Constraints

Trennung von Client und Server

Der Client übernimmt die Präsentation, der Server die Daten und die Logik. Beide Seiten können sich unabhängig voneinander weiterentwickeln und separat deployt werden, solange die Schnittstelle stabil bleibt.

Statelessness (Zustandslosigkeit)

Jede Anfrage enthält alles, was der Server zu ihrer Verarbeitung benötigt — das Authentifizierungstoken, den Ressourcenbezeichner, die Parameter. Der Server hält zwischen den Anfragen keinen clientspezifischen Sitzungszustand vor. Genau das erlaubt es jeder Instanz hinter einem Load Balancer, jede beliebige Anfrage zu bedienen, und macht horizontales Skalieren so unkompliziert.

Cachebarkeit

Antworten deklarieren über Header wie Cache-Control und ETag selbst, ob sie gecacht werden dürfen. So können Browser, CDNs und Gateways wiederholte GET-Anfragen bedienen, ohne den Origin-Server zu berühren — einer der handfestesten praktischen Vorteile von REST gegenüber RPC-artigen APIs.

Uniform Interface (Einheitliche Schnittstelle)

Ressourcen werden über URIs identifiziert, über Repräsentationen (heute JSON) manipuliert und mit einem kleinen Satz von Methoden angesprochen, deren Semantik standardisiert ist: GET ist sicher und wiederholbar, PUT und DELETE sind idempotent, POST ist keines von beidem. Diese Einheitlichkeit ist der Grund, warum generisches Tooling — Clients, Proxys, API-Gateways — mit jeder REST-API funktioniert. (Fieldings vollständiges Constraint umfasst zusätzlich Hypermedia-Links in den Antworten, also HATEOAS, was die meisten realen APIs auslassen.)

Schichtenarchitektur (Layered System)

Ein Client kann nicht erkennen, ob er mit dem Origin-Server spricht oder mit einem dazwischengeschalteten Load Balancer, Cache oder Gateway. Dadurch lassen sich Schichten hinzufügen — TLS-Terminierung, Rate Limiting, Caching —, ohne die Clients zu ändern, was das System modular und wartbar hält.

CRUD-Operationen

REST-APIs bilden CRUD (Create, Read, Update, Delete) typischerweise auf HTTP-Methoden ab. Für eine Buchhandlungsanwendung:

• Create: POST /books, um ein neues Buch anzulegen
• Read: GET /books/42, um ein bestimmtes Buch anzuzeigen
• Update: PUT /books/42, um es zu ersetzen, oder PATCH /books/42, um einzelne Felder zu ändern
• Delete: DELETE /books/42, um es zu entfernen

Häufig verwendete Statuscodes

Code	Bedeutung	Beschreibung
200	OK	Die Anfrage wurde erfolgreich verarbeitet
201	Created	Die Ressource wurde erfolgreich erstellt
204	No Content	Erfolg ohne Antwort-Body, typisch nach DELETE
400	Bad Request	Die Anfrage war fehlerhaft formatiert oder scheiterte an der Validierung
401	Unauthorized	Die Authentifizierung fehlt oder ist ungültig
403	Forbidden	Authentifiziert, aber ohne Berechtigung für die Ressource
404	Not Found	Die angeforderte Ressource wurde nicht gefunden
429	Too Many Requests	Der Client hat ein Rate Limit überschritten
500	Internal Server Error	Auf dem Server ist ein unerwarteter Fehler aufgetreten

REST vs. GraphQL vs. gRPC

REST ist der Standard für öffentliche, ressourcenorientierte APIs: cachebar, mit curl debugbar und von jedem Gateway und Werkzeug unterstützt. GraphQL passt, wenn unterschiedliche Clients flexible Abfragen benötigen, die viele Ressourcen in einem einzigen Round Trip aggregieren — typisch für Mobile-Apps und Backend-for-Frontend-Schichten —, um den Preis, die HTTP-Caching-Semantik zu verlieren. gRPC glänzt bei internen Service-zu-Service-Aufrufen: binäre Protocol Buffers, Streaming und Contract-first-Codegenerierung. Das sind Ergänzungen, keine Konkurrenten; ein gängiges Setup im Jahr 2026 ist REST an der öffentlichen Edge und gRPC zwischen den Services.

Welchen Stil Sie auch nach außen anbieten — die Themen an der Edge bleiben dieselben: Authentifizierung, TLS, Rate Limiting, Eingabevalidierung. Unser Leitfaden zur API-Sicherheit behandelt diese Checkliste im Detail, und das Entwerfen und Betreiben produktiver API-Plattformen gehört zum Kerngeschäft unseres DevOps-Engineering-Teams.

Soll das in Produktion laufen? Unser AWS Managed Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab 3.000 €/Monat.