Einheit 2 — REST vs. SQL: Was ist der Unterschied?
Was du nach dieser Einheit weißt: Du verstehst den grundlegenden Unterschied zwischen direktem Datenbankzugriff und API-Zugriff — und warum API-Endpunkte keine einfache Umbenennung von SQL-Tabellen sind.
Die Intuition stimmt — und stimmt nicht
Deine Vermutung ist verständlich: Ein API-Endpunkt /customers/42 ruft offensichtlich irgendetwas ab das intern in einer Datenbanktabelle namens customers mit dem Primary Key 42 liegt. Die Spalten der Tabelle entsprechen den Feldern in der JSON-Antwort. Wo ist da der Unterschied?
Die Intuition ist nicht falsch — aber sie greift zu kurz. Hier ist warum.
Was SQL direkt tut
SQL ist eine Sprache für den direkten Zugriff auf Datenbankstrukturen. Wer SQL ausführt, spricht direkt mit der Datenbank-Engine:
SELECT c.id, c.name, c.email, a.street, a.city
FROM customers c
JOIN addresses a ON c.id = a.customer_id
WHERE c.id = 42
AND c.status = 'active'
Das passiert direkt — kein Zwischensystem, keine Logik dazwischen. Wer das ausführt, sieht genau was in den Tabellen steht. Inklusive Felder die vielleicht nie nach außen sollen (interne Notizen, Passwort-Hashes, gelöschte Datensätze die nur als "deleted" markiert sind).
Was eine REST API tut — und was dazwischen liegt
Eine REST API ist eine Anwendungsschicht. Wenn du GET /customers/42 aufrufst, passiert folgendes:
Deine Anfrage
↓
API-Server empfängt die Anfrage
↓
Authentifizierung prüfen: Wer bist du? Hast du Rechte?
↓
Autorisierung prüfen: Darfst du Kunde 42 sehen?
↓
Geschäftslogik ausführen: Welche Felder darf dieser Nutzer sehen?
↓
Datenbankabfrage(n) ausführen — intern, nicht sichtbar
↓
Ergebnis aufbereiten: Felder filtern, Werte formatieren, verknüpfte Daten einbetten
↓
JSON-Antwort zurückschicken
Was dazwischen liegt, ist entscheidend. Die API entscheidet:
- Wer auf welche Daten zugreifen darf
- Welche Felder zurückgegeben werden
- Ob Daten aus mehreren Tabellen zusammengeführt werden
- Ob Operationen protokolliert werden
- Ob bestimmte Aktionen Nebeneffekte auslösen (E-Mail senden, Cache invalidieren, Workflow starten)
Ein konkretes Beispiel: Bestellung anlegen
Per SQL direkt:
INSERT INTO orders (customer_id, product_id, quantity, status)
VALUES (42, 789, 3, 'pending');
Das schreibt einen Datensatz in die Tabelle. Fertig.
Per REST API:
POST /orders
{
"customer_id": 42,
"product_id": 789,
"quantity": 3
}
Was die API intern macht:
- Prüft ob Kunde 42 existiert und aktiv ist
- Prüft ob Produkt 789 auf Lager ist (Lagertabelle)
- Schreibt den Bestelldatensatz
- Reduziert den Lagerbestand
- Schickt eine Bestätigungs-E-Mail
- Löst vielleicht einen Workflow aus
Mit direktem SQL-Insert würden Schritte 1–6 nicht passieren. Das Ergebnis wäre ein inkonsistenter Datenbankzustand.
Was API-Endpunkte wirklich sind
API-Endpunkte sind keine Tabellen-Aliases. Sie sind:
Abstraktionen — Ein Endpunkt /customer-profile/42 kann intern Daten aus fünf verschiedenen Tabellen zusammenführen. Die Tabellenstruktur des Backends ist für den API-Nutzer irrelevant und unsichtbar.
Geschäftsoperationen — POST /orders ist nicht "füge eine Zeile in die Orders-Tabelle ein". Es ist "erstelle eine Bestellung" — mit allen Konsequenzen die das Unternehmen damit verbindet.
Kontrollpunkte — Berechtigungen, Logging, Rate Limiting, Validierung — alles läuft durch die API.
Stabilitätsversprechen — Die Tabellenstruktur im Backend kann sich ändern. Wenn der API-Anbieter seine Datenbank umstrukturiert, bleibt der Endpunkt /customers/42 trotzdem derselbe — weil das sein Versprechen an seine Nutzer ist.
Wann SQL, wann API?
| Situation | Empfehlung |
|---|---|
| Direkter Zugriff auf eigene Datenbank (ERP ohne API) | SQL / Database Agent |
| Zugriff auf Fremdsystem das eine API anbietet | REST API / Post Agent |
| Reporting über eigene Daten | SQL |
| Daten in ein externes System schreiben | REST API |
| Zugriff auf Cloud-Dienste (Salesforce, HubSpot, ...) | REST API (kein direkter DB-Zugriff möglich) |
| Interne 42°OS Datenpersistenz | SQL / Internal Storage Agent |
Die wichtigste Faustregel: Wenn ein Fremdsystem eine API anbietet, nutze sie. Direkter Datenbankzugriff auf fremde Systeme ist fast immer verboten, technisch unsicher und fragil.