REST-API-Grundlagen#

Eine API (Application Programming Interface) ist eine Programmierschnittstelle, über die Anwendungen miteinander Daten austauschen und Funktionen aufrufen können, ohne die interne Implementierung des jeweils anderen Systems zu kennen. REST (Representational State Transfer) ist der heute meistgenutzte Architekturstil, um solche Schnittstellen über HTTP bereitzustellen — er bildet die Grundlage für den Großteil moderner Web- und Cloud-Anwendungen.

REST-Prinzipien#

REST ist kein Protokoll, sondern ein Satz von Architekturprinzipien für den Entwurf von Web-Schnittstellen:

• Zustandslosigkeit (stateless): Jede Anfrage enthält alle Informationen, die der Server zur Bearbeitung benötigt. Der Server speichert keinen Sitzungszustand zwischen zwei Anfragen — das erleichtert Skalierung, da jede Anfrage unabhängig von einem beliebigen Server beantwortet werden kann.
• Ressourcen über URIs: Jede Ressource (z. B. ein Kunde, eine Bestellung) wird über eine eindeutige Adresse angesprochen, z. B. /api/kunden/42. Ressourcen sind Substantive, keine Aktionen — die Aktion ergibt sich aus der HTTP-Methode.
• Einheitliche Schnittstelle (uniform interface): Alle Ressourcen werden über dieselben, standardisierten HTTP-Methoden angesprochen (GET, POST, PUT, PATCH, DELETE). Das macht APIs vorhersehbar und einheitlich nutzbar.
• Client-Server-Trennung: Client (z. B. Web- oder Mobile-App) und Server (Datenhaltung, Logik) sind strikt getrennt und können unabhängig voneinander weiterentwickelt werden.
• Zustandsrepräsentation: Ressourcen werden in einer Repräsentation übertragen, meist als JSON, seltener XML.

HTTP-Methoden im REST-Kontext#

Jede HTTP-Methode hat im REST-Kontext eine feste, konventionelle Bedeutung:

GET und DELETE gelten als idempotent — mehrfaches Ausführen derselben Anfrage führt zum gleichen Endzustand. PUT ist ebenfalls idempotent (das vollständige Ersetzen mit denselben Daten ändert nichts weiter), POST dagegen nicht — jeder Aufruf legt eine neue Ressource an.

HTTP-Statuscodes#

Der Server signalisiert das Ergebnis einer Anfrage über einen dreistelligen Statuscode, dessen erste Ziffer die Kategorie angibt:

Die häufigsten Codes in der Praxis:

Ablauf einer REST-Anfrage#

sequenceDiagram
  actor Client
  participant API as REST-API
  participant Server
  participant DB as Datenbank

  Client->>API: GET /kunden/42
  API->>Server: Anfrage verarbeiten
  Server->>DB: Kunde mit ID 42 abfragen
  DB-->>Server: Datensatz
  Server-->>API: Ergebnis aufbereiten
  API-->>Client: 200 OK + JSON-Repräsentation

REST vs. SOAP#

Neben REST gibt es mit SOAP (Simple Object Access Protocol) einen älteren, formaleren Ansatz für Web-Services:

Prüfungsbeispiele#

„Ein Client ruft zweimal hintereinander dieselbe PUT-Anfrage auf. Welches REST-Prinzip garantiert, dass der Endzustand der Ressource gleich bleibt?"

→ Die Idempotenz der PUT-Methode: Ein wiederholtes vollständiges Ersetzen mit denselben Daten führt zu keinem weiteren Zustandswechsel.

„Ein Client fragt eine Ressource ab, die nicht existiert. Welchen HTTP-Statuscode sollte die API zurückgeben?"

→ 404 Not Found — die angefragte Ressource ist unter der angegebenen URI nicht vorhanden.

„Warum gilt REST als besser skalierbar als klassische SOAP-Services mit Sitzungszustand?"

→ Weil REST zustandslos (stateless) ist: Jede Anfrage trägt alle nötigen Informationen selbst, sodass beliebige Server sie unabhängig voneinander beantworten können — es muss kein Sitzungszustand zwischen Anfragen auf einem bestimmten Server gehalten werden.

Quiz#

Siehe auch#

• datenformate — JSON als Standardformat für REST-API-Antworten
• api-authentifizierung — wie REST-APIs Zugriffe absichern
• protokolle ports — HTTP als Transportprotokoll für REST
• softwaredokumentation — API-Dokumentation mit Swagger/OpenAPI

Ressourcen#

• Wikipedia: Representational State Transfer
• Wikipedia: SOAP
• Studyflix: REST API einfach erklärt
• SimpleClub: Fachinformatiker Lernbereich