REST-API bauen: Design, Sicherheit und Deployment

Um eine REST-API zu bauen, listest du die Ressourcen auf, die deine App verwaltet (Benutzer, Bestellungen, Buchungen), gibst jeder eine URL wie /orders und /orders/{id} und nutzt HTTP-Methoden für Aktionen: GET zum Lesen, POST zum Anlegen, PATCH zum Ändern, DELETE zum Entfernen. Gib JSON mit aussagekräftigen Statuscodes zurück, validiere jede Eingabe, verlange Authentifizierung und Berechtigungsprüfungen pro Datensatz auf dem Server und teile Listen in Seiten auf. Dokumentiere danach die Endpunkte und stelle die API hinter HTTPS bereit.

Dieser Leitfaden behandelt die Designentscheidungen, eine Auswahl fertiger Routen, Prompts für einen KI-App-Builder und die Fehler, die zu Sicherheitslücken führen. Wenn APIs für dich neu sind, beginne mit was eine API ist.

Wann du eine REST-API brauchst

• Dein Web-Frontend muss Daten auf einem Server speichern und laden
• Eine Mobile-App, ein Partner oder ein Automatisierungstool braucht Zugriff auf deine Daten
• Andere Dienste senden dir Ereignisse (Webhooks)
• Du teilst die Arbeit zwischen einem Frontend- und einem Backend-Team auf

REST ist der häufigste Stil, aber nicht der einzige. REST vs. GraphQL erklärt, wann ein flexibler Abfrage-Endpunkt besser passt.

Zuerst designen: Ressourcen und Routen

Schreib die Substantive deiner App und das, was Nutzer mit ihnen tun, auf. Für eine einfache Buchungs-App sieht das so aus:

Diese Routen bilden Anlegen, Lesen, Ändern und Löschen ab; siehe was CRUD ist. Konventionen, die sich lohnen:

• Substantive im Plural, keine Verben in URLs: /bookings, nicht /getBookings.
• Nur eine Ebene verschachteln, wenn es die Zugehörigkeit klarer macht: /bookings/{id}/notes.
• Aktionen, die kein CRUD sind, können Unterressourcen sein: POST /bookings/{id}/cancel ist klarer als ein unklares PATCH.
• Einheitliche Feldnamen, zum Beispiel created_at überall.

Statuscodes und Fehler

Nutze die Standard-HTTP-Codes, damit Clients erkennen, was passiert ist, ohne Text zu parsen:

Gib Fehler in einer einheitlichen JSON-Struktur zurück, zum Beispiel {"error": {"code": "slot_taken", "message": "Dieser Termin ist nicht mehr verfügbar."}}, und gib in Antworten niemals Stack-Traces oder Datenbankfehler aus.

Optionen und Abwägungen

Schritt für Schritt

1. Ressourcen und Routen auflisten, wie oben, inklusive wer jede Route aufrufen darf.
2. Die Daten modellieren in deiner Datenbank mit den Feldern und Beziehungen, die du brauchst.
3. Zuerst die Lese-Routen bauen, dann Anlegen, Ändern und Löschen.
4. Jede Eingabe bei Schreibzugriffen validieren mit einer Schema-Bibliothek: Pflichtfelder, Typen, Längen, erlaubte Werte. Unbekannte Felder ablehnen.
5. Authentifizierung hinzufügen, dann Autorisierung pro Datensatz: Das Laden von /bookings/42 muss prüfen, dass Buchung 42 dem Aufrufer gehört, nicht nur, dass jemand angemeldet ist.
6. Jede Liste paginieren und die Seitengröße begrenzen.
7. Login und aufwendige Routen ratenbegrenzen. Siehe Rate Limiting.
8. CORS nur konfigurieren, wenn Browser auf anderen Domains die API aufrufen müssen, und diese Ursprünge explizit auflisten. CORS-Fehler beheben erklärt die Fehler, die du sehen wirst.
9. Doku und Tests schreiben für jede Route, inklusive der Fehlerfälle.
10. Deployen mit Geheimnissen in Umgebungsvariablen, HTTPS, Logs und einem Health-Check.

Prompts für deinen KI-Builder

Gerüst:

Erstelle eine REST-API für Buchungen mit diesen Routen: GET /api/health, GET /api/bookings (paginiert, maximal 50 pro Seite), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. Speichere die Daten in unserer Datenbank. Validiere Request-Bodies mit einer Schema-Bibliothek und lehne unbekannte Felder ab. Gib JSON-Fehler als {"error": {"code", "message"}} mit passenden Statuscodes (400, 401, 403, 404, 409) zurück. Halte Geheimnisse in Umgebungsvariablen.

Sicherheit:

Verlange eine Anmeldung für jede Buchungsroute. Prüfe bei jedem Lesen, Ändern und Löschen auf dem Server, dass die Buchung dem aktuellen Nutzer gehört; gib 404 zurück, wenn nicht. Akzeptiere niemals Nutzer-IDs oder Rollen aus dem Request-Body. Begrenze POST /api/bookings auf 20 Anfragen pro Minute und Nutzer. Logge Fehler auf dem Server, ohne Stack-Traces zurückzugeben.

Doku:

Schreibe eine OpenAPI-Beschreibung dieser Routen und eine kurze README mit Beispiel-Requests und -Antworten für jede Route.

Deine API testen

Teste von außerhalb des Frontends, denn Angreifer werden das tun:

• Jede Route funktioniert mit gültiger Eingabe und liefert die dokumentierte Struktur und den dokumentierten Code
• Fehlende oder ungültige Felder liefern 400 mit einer klaren Meldung
• Ohne Token liefert jede geschützte Route 401
• Nutzer A, der per ID den Datensatz von Nutzer B abruft, erhält 404 oder 403
• Listen sind paginiert; ein riesiges limit wird begrenzt
• Doppelte oder kollidierende Anlagen liefern 409, nicht 500
• Rate Limits liefern 429
• Fehlerantworten enthalten keine Stack-Traces, kein SQL und keine Geheimnisse
• CORS erlaubt nur die Ursprünge, die du vorgesehen hast

Häufige Fehler

• Anmeldung prüfen, aber nicht die Zugehörigkeit. Die häufigste API-Lücke: Jeder angemeldete Nutzer kann jeden Datensatz lesen, indem er die ID ändert.
• Dem Client vertrauen. Preise, Rollen und Nutzer-IDs aus dem Request-Body können verändert werden.
• Ganze Datenbankzeilen zurückgeben. Passwort-Hashes und interne Felder leaken. Lege fest, was jede Antwort enthält.
• Unbegrenzte Listen. Eine Anfrage für alle Datensätze kann die ganze App verlangsamen.
• 200 OK mit einer Fehlermeldung im Inneren. Clients und Monitoring können nicht erkennen, dass etwas fehlgeschlagen ist.
• CORS, das alles erlaubt, bei einer API, die Cookies nutzt.
• Kein Health-Check und keine Logs, sodass du von Ausfällen durch Nutzer erfährst.

Für einen umfassenderen Check vor dem Start siehe die Sicherheitscheckliste für KI-gebaute Apps.

Eine REST-API in Mythex bauen

Du kannst Mythex um eine API bitten, als Teil deiner App oder als eigenen Dienst. Das Docs-Rezept REST-API-Backend enthält einen Start-Prompt: Nenne dein Framework und deine Routen, bitte um klare JSON-Fehler, halte Geheimnisse in Umgebungsvariablen und lass ein Dockerfile erstellen. Container-Backends in Node, Python, C#, Java und anderen werden über ein Dockerfile veröffentlicht, und Mythex übernimmt das Deployment über Publish (API-Backends). Ein Projekt kann eine Website und einen API-Server nebeneinander betreiben, und du kannst in der Vorschau zwischen beiden wechseln. Speichere Schlüssel als Projekt-Secrets, und wenn die API eine Datenbank braucht, bitte im Chat darum. Für geplante Hintergrundaufgaben rund um deine API siehe wie du Hintergrundjobs ausführst.

Fragen