CRUD-Operationen: Create, Read, Update, Delete erklärt

Was ist CRUD?

CRUD steht für Create, Read, Update, Delete, die vier Grundoperationen auf gespeicherten Daten. Eine Datenbank führt sie als SQL-Anweisungen aus, eine REST-API stellt sie als HTTP-Methoden bereit, und die meisten Verwaltungsoberflächen sind um sie herum gebaut. Lässt sich eine Funktion mit einem dieser vier Verben beschreiben, ist sie CRUD.

Wie CRUD auf SQL und HTTP abgebildet wird

CRUD-Beispiel: eine Tabelle users

Dieselben vier Operationen in SQL:

-- Create
INSERT INTO users (email, name) VALUES ('alice@example.com', 'Alice');
-- Read
SELECT * FROM users WHERE id = 42;
-- Update
UPDATE users SET name = 'Alice Smith' WHERE id = 42;
-- Delete
DELETE FROM users WHERE id = 42;

Und als Aufrufe einer REST-API, wobei jeder Aufruf einen API-Endpunkt anspricht:

POST   /users        {"email": "alice@example.com", "name": "Alice"}   -> 201 Created, Location: /users/42
GET    /users/42                                                      -> 200 OK
GET    /users?limit=20&offset=0                                       -> 200 OK (a page of users)
PUT    /users/42     {"email": "alice@example.com", "name": "Alice Smith"} -> 200 OK (full replace)
PATCH  /users/42     {"name": "Alice Smith"}                          -> 200 OK (partial change)
DELETE /users/42                                                      -> 204 No Content

PUT vs. PATCH

Ein PUT ersetzt die ganze Ressource, der Aufrufer sendet also den vollständigen neuen Zustand. Ein PATCH beschreibt nur die Änderung eines Teils, es werden also nur die geänderten Felder gesendet. PATCH passt zu üblichen Bearbeitungsformularen, PUT dann, wenn der Client den kompletten Datensatz tatsächlich besitzt.

Welche Methoden lassen sich gefahrlos wiederholen?

Laut MDN sind GET, PUT und DELETE idempotent: Wiederholt man die Anfrage, bleibt der Serverzustand gleich. Bei POST und PATCH ist das nicht garantiert, ein wiederholtes Create kann daher einen Duplikat-Datensatz erzeugen. Idempotency-Keys lösen das, siehe Idempotenz und die HTTP-Semantik in RFC 9110.

CRUD jenseits von REST

GraphQL kennt keine Endpunkte pro Verb: Lesen sind Queries, Schreiben sind Mutations. gRPC benennt Methoden nach der Operation (CreateUser, GetUser). Event-Sourcing-Systeme speichern Ereignisse wie UserCreated, statt Zeilen zu überschreiben. Mehr dazu im Eintrag GraphQL.

mutation { createUser(input: {...}) { id } }
query    { user(id: 42) { id name } }
mutation { updateUser(id: 42, input: {...}) { id } }
mutation { deleteUser(id: 42) { success } }

Häufige CRUD-Fehler

• Keine Paginierung bei Listen. Ein Listen-Endpunkt, der jede Zeile zurückgibt, wird mit wachsender Tabelle langsam und fällt irgendwann aus. Siehe API-Paginierung.
• N+1-Abfragen. Der Listen-Endpunkt führt pro Datensatz eine zusätzliche Abfrage aus. Joins oder Eager Loading verwenden.
• Verlorene Updates. Zwei Clients bearbeiten denselben Datensatz, der letzte Schreibzugriff gewinnt. ETag oder Versionsfeld nutzen.
• PUT mit unvollständigem Body. Der Server ersetzt den Datensatz und leert jedes Feld, das der Aufrufer weggelassen hat.
• 200 mit leerem Body für einen fehlenden Datensatz. Stattdessen 404 zurückgeben.
• Stille Kaskadenlöschung. Wer einen Nutzer löscht, löscht auch dessen Bestellungen.
• SQL aus Nutzereingaben zusammengebaut. Immer parametrisierte Abfragen verwenden.
• Autorisierung nur bei Schreibzugriffen. Auch Lesezugriffe geben Daten preis.

CRUD-APIs testen und überwachen

Eine CRUD-API bricht unter Last meist an denselben Stellen ein: langsame Listenabfragen, Sperrkonflikte bei Updates und doppelte Create-Aufrufe bei Wiederholungen. Skripten Sie einen kompletten Create-Read-Update-Delete-Ablauf und führen Sie ihn mit dem LoadFocus-Lasttest aus, der JMeter- und k6-Skripte aus 25 Cloud-Regionen startet. Nach dem Release kann das API-Monitoring Ihre Lese-Endpunkte prüfen (kostenlose Checks laufen alle 5 Minuten) und Statuscode sowie Antwort-Body kontrollieren. Weiterlesen: RESTful APIs per Lasttest prüfen und API-Testing.

Häufige Fragen: CRUD-Operationen

Ist jede API eine CRUD-API?

Viele Daten-APIs lassen sich sauber auf CRUD abbilden. APIs mit Geschäftslogik nutzen oft andere Verben, zum Beispiel POST /transfers oder POST /users/42/send-welcome-email.

Was ist der Unterschied zwischen CRUD und REST?

CRUD sind die vier Operationen. REST ist ein Architekturstil für APIs, der diese Operationen oft, aber nicht immer auf HTTP-Methoden abbildet.

Soll ich weich oder hart löschen?

Weiches Löschen (ein Zeitstempel deleted_at) bewahrt die Historie und ist umkehrbar. Hartes Löschen brauchen Sie, wenn Daten aus rechtlichen Gründen verschwinden müssen oder Speicher frei werden soll.

Wie verhindere ich verlorene Updates?

Mit optimistischer Nebenläufigkeit: Der Client sendet das gelesene ETag oder die Version, und der Server lehnt den Schreibzugriff ab, wenn sich der Datensatz inzwischen geändert hat.

Braucht jedes Modell alle vier Operationen?

Nein. Nur lesbare oder nur anfügbare Ressourcen sind in Ordnung. Stellen Sie nur die Operationen bereit, die Ihr Anwendungsfall braucht.