Einheit 1 — Was ist eine REST API?
Was du nach dieser Einheit weißt: Du verstehst das Denkmodell hinter REST — was eine Ressource ist, wie Endpunkte funktionieren und warum APIs so gebaut sind wie sie sind.
Das Problem das APIs lösen
Stell dir vor, zwei Unternehmen wollen Daten austauschen. Unternehmen A hat ein ERP-System auf einem Server in Bielefeld. Unternehmen B hat ein CRM-System auf einem Server in München. Wie kommt eine Bestellung aus dem ERP in das CRM?
Die naive Antwort: direkter Datenbankzugriff. B bekommt Zugangsdaten zur Datenbank von A und liest direkt aus den Tabellen.
Das ist in der Praxis fast nie möglich und nicht gewollt — aus mehreren Gründen:
Sicherheit — Wer direkten Datenbankzugriff hat, kann alles sehen, ändern und löschen. Kein Unternehmen gibt das freiwillig aus der Hand.
Abhängigkeit — Wenn A seine Datenbankstruktur ändert (Tabelle umbenennen, Spalte hinzufügen), bricht der Zugriff von B sofort. A kann seine eigene Software nicht mehr weiterentwickeln ohne B zu fragen.
Kontrolle — A kann nicht steuern welche Daten B sehen darf, wie viele Anfragen B stellen darf, ob B gerade aktiv oder gesperrt ist.
Eine API löst all das. Sie ist eine definierte Schnittstelle — eine Art Serviceschalter — über die System A genau kontrolliert was System B tun und sehen darf.
REST — das Architekturprinzip
REST steht für Representational State Transfer. Es ist kein Protokoll, kein Standard, kein Format — sondern ein Architekturstil, ein Set von Prinzipien für den Aufbau von Web-APIs.
Die wichtigsten Prinzipien:
Ressourcen statt Aktionen — Eine REST API denkt in Objekten, nicht in Befehlen. Es gibt nicht den Befehl "getCustomerById(42)" sondern die Ressource "Kunde mit ID 42". Wie man auf diese Ressource zugreift (lesen, ändern, löschen), wird durch die HTTP-Methode ausgedrückt.
Einheitliche URLs — Jede Ressource hat eine eindeutige Adresse (URL). https://api.example.com/customers/42 ist immer dieser eine Kunde. Die URL identifiziert das Objekt.
Zustandslos — Jede Anfrage ist in sich vollständig. Der Server merkt sich nichts zwischen zwei Anfragen. Wenn B zweimal dieselbe Anfrage schickt, muss B beide Male alle nötigen Informationen mitschicken — wer es ist, was es will, mit welchen Zugangsdaten.
Standardformate — REST APIs antworten fast immer mit JSON. Das macht sie für jede Programmiersprache und jedes System nutzbar.
Was ist ein Endpunkt?
Ein Endpunkt (Endpoint) ist eine bestimmte URL-Adresse über die man mit einer API interagieren kann. Jeder Endpunkt repräsentiert eine Ressource oder eine Sammlung von Ressourcen.
https://api.example.com/v1/customers → alle Kunden
https://api.example.com/v1/customers/42 → Kunde mit ID 42
https://api.example.com/v1/customers/42/orders → alle Bestellungen von Kunde 42
https://api.example.com/v1/orders/101 → Bestellung mit ID 101
Man erkennt die Hierarchie: Kunden sind eine Sammlung, ein einzelner Kunde ist ein Element darin, seine Bestellungen sind eine Unterressource.
Was ist eine Ressource?
Eine Ressource ist ein beliebiges Objekt über das die API Informationen bereitstellt — ein Kunde, eine Bestellung, ein Produkt, ein Dokument, ein Benutzer.
Eine Ressource hat:
- eine eindeutige ID (oft numerisch, manchmal eine UUID wie
b143a5f2-...) - Eigenschaften (Felder: Name, Datum, Status, ...)
- mögliche Beziehungen zu anderen Ressourcen
In der API-Antwort wird eine Ressource als JSON-Objekt dargestellt:
{
"id": 42,
"name": "Muster GmbH",
"email": "einkauf@muster.de",
"status": "active",
"created_at": "2024-03-15T09:22:00Z"
}
Warum "REST" und nicht einfach "API"?
Es gibt verschiedene API-Stile. REST ist heute der dominante, aber nicht der einzige:
SOAP — ein älterer, XML-basierter Standard. Sehr formal, sehr ausführlich, noch in vielen älteren Enterprise-Systemen (SAP, ältere ERP-Systeme). Komplizierter zu nutzen als REST.
GraphQL — ein neuerer Ansatz, bei dem der Client genau spezifiziert welche Felder er braucht. Effizienter bei komplexen Datenstrukturen, aber aufwendiger zu implementieren.
gRPC — hochperformant, binäres Format, vor allem für interne Microservice-Kommunikation. Für Integrationsszenarien wie in 42°OS selten relevant.
In der Praxis: wenn jemand von "der API" eines Systems spricht, meint er fast immer eine REST API.
Eine vollständige Erklärung von REST APIs findest du in der Dokumentation unter REST APIs ansprechen.