REST-APIs für Nicht-Entwickler erklärt

Was ist eine REST-API?

Wenn Sie eine App verwenden, stammen viele der auf dem Bildschirm angezeigten Informationen von externen Diensten.

Das Wetter an Ihrem Reiseziel, der Status einer Sendung, der Preis eines Produkts, eine Buchung oder das Ergebnis einer Zahlung: Häufig verwaltet die App all diese Daten nicht selbst. Stattdessen fragt sie sie bei anderen Systemen ab.

Hier kommen APIs ins Spiel. Eine API ermöglicht es zwei Softwaresystemen, anhand festgelegter Regeln miteinander zu kommunizieren. Eine REST-API ist eine der gängigsten Möglichkeiten, dies über das Web zu tun. Sie können sich das als strukturiertes Gespräch zwischen Anwendungen vorstellen:

„Gib mir die Informationen zu diesem Produkt.“

Der Dienst antwortet:

„Hier sind Name, Preis und Verfügbarkeit.“

Oder:

„Erstelle eine neue Buchung für diesen Kunden.“

Darauf könnte der Dienst antworten:

„Buchung erstellt.“

REST steht für Representational State Transfer. Sie müssen sich dieses Akronym nicht merken, um die Funktionsweise zu verstehen. Der Grundgedanke ist einfacher: Eine REST-API organisiert Daten in Ressourcen – etwa Benutzer, Produkte, Bestellungen oder Buchungen – und legt ein standardisiertes Verfahren fest, um sie abzurufen, zu erstellen, zu aktualisieren oder zu löschen.

Ein Beispiel aus der Praxis

Stellen Sie sich eine Reise-App vor, die das Wetter an Ihrem bevorstehenden Reiseziel anzeigt. Die App muss nicht unbedingt alle Wetterdaten selbst erfassen und laufend aktualisieren. Sie kann eine Anfrage an die API eines Wetterdienstes senden.

Der Ablauf sieht so aus:

Ihre App → API-Anfrage → Wetterdienst → Antwort → Ihre App

Die Antwort kann die Temperatur, die Wetterlage und die Vorhersage für die nächsten Tage enthalten. Der Benutzer sieht lediglich das Wetter. Im Hintergrund kommunizieren jedoch zwei Systeme miteinander.

Die Restaurant-Analogie

Eine API lässt sich gut mit einem Restaurantbesuch vergleichen.

• Sie sind die Anwendung, die etwas benötigt.
• Die Speisekarte beschreibt, was Sie bestellen können.
• Die Bedienung nimmt die Bestellung auf und bringt die Antwort zurück.
• Die Küche ist der Dienst, der die eigentliche Arbeit erledigt.

Die API übernimmt sowohl die Rolle der Speisekarte als auch die der Bedienung. Sie legt fest, was Sie anfordern können, wie die Anfrage gestellt wird und welche Art von Antwort Sie erwarten können. Sie müssen nicht wissen, wie die Küche arbeitet, um ein Gericht zu bestellen. Genauso muss eine App nicht unbedingt wissen, wie ein Dienst intern umgesetzt ist, um dessen API zu verwenden.

Wie funktioniert eine REST-API-Anfrage?

Jede API-Anfrage enthält einige wesentliche Informationen.

Endpunkt: Wohin wird die Anfrage gesendet?

Der Endpunkt ist die Adresse, an die die Anfrage gesendet wird. Zum Beispiel:

https://api.example.com/products/42

Dies könnte für das Produkt mit der ID 42 stehen. Unterschiedliche Endpunkte können eine Sammlung von Ressourcen, ein einzelnes Element oder einen bestimmten Vorgang repräsentieren.

HTTP-Methode: Was möchten Sie tun?

Die HTTP-Methode teilt dem Dienst mit, welchen Vorgang Sie ausführen möchten. Die häufigsten Methoden sind:

• GET → Informationen abrufen;
• POST → eine neue Ressource erstellen;
• PUT oder PATCH → eine vorhandene Ressource aktualisieren;
• DELETE → eine Ressource löschen.

Auf einer Buchungsplattform könnte beispielsweise:

GET /bookings

Buchungen abrufen, während:

POST /bookings

eine neue Buchung erstellen könnte. Dies sind weitverbreitete Konventionen, aber keine absolute Garantie. Maßgeblich ist immer die Dokumentation der jeweiligen API.

Header und Body: Zusätzliche Informationen

Header enthalten ergänzende Informationen zur Anfrage, beispielsweise das Datenformat oder die für die Authentifizierung verwendeten Zugangsdaten. Der Body enthält dagegen die Daten, die für den Vorgang benötigt werden. Wenn Sie beispielsweise eine Buchung erstellen möchten, könnte der Body Folgendes enthalten:

{
  "service": "Consultation",
  "date": "2026-09-15",
  "time": "14:00"
}

Diese Daten werden häufig als JSON dargestellt – ein weitverbreitetes Format, das strukturiert und sowohl für Menschen als auch für Software leicht lesbar ist.

Was geschieht, wenn die Antwort eintrifft?

Nachdem der Dienst die Anfrage empfangen hat, verarbeitet er sie und sendet eine Antwort zurück. Die Antwort enthält in der Regel die angeforderten Daten oder das Ergebnis des Vorgangs sowie einen HTTP-Statuscode, der angibt, was passiert ist. Die häufigsten Codes lassen sich in drei große Kategorien einteilen.

200–299: Alles ist in Ordnung

Die Anfrage wurde erfolgreich verarbeitet. Zum Beispiel:

• 200 OK → Anfrage abgeschlossen;
• 201 Created → neue Ressource erstellt.

400–499: Mit der Anfrage stimmt etwas nicht

Das Problem betrifft normalerweise die Anfrage selbst oder die Berechtigungen des Clients. Zum Beispiel:

• 400 Bad Request → ungültige Daten;
• 401 Unauthorized → Authentifizierung fehlt oder ist ungültig;
• 403 Forbidden → der Benutzer verfügt nicht über die erforderlichen Berechtigungen;
• 404 Not Found → die angeforderte Ressource existiert nicht.

500–599: Serverseitiges Problem

Beim Dienst, der die Anfrage verarbeitet, ist ein Problem aufgetreten. Für Benutzer sagt ein Code wie 409 oder 500 allerdings wenig aus. Eine gute Anwendung übersetzt den technischen Fehler daher in eine verständliche Meldung:

„Dieser Termin ist nicht mehr verfügbar. Wählen Sie bitte eine andere Uhrzeit.“

Das ist wesentlich hilfreicher als:

„HTTP 409 Conflict.“

REST-APIs, Datenbanken, Webhooks und GraphQL: Was ist der Unterschied?

Diese Technologien und Konzepte hängen zusammen, erfüllen jedoch unterschiedliche Aufgaben.

REST-APIs und Datenbanken

Eine Datenbank speichert Informationen. Eine API legt dagegen fest, wie andere Systeme mit diesen Informationen interagieren können. Eine Datenbank könnte beispielsweise Folgendes enthalten:

• Benutzer;
• Produkte;
• Bestellungen;
• Buchungen.

Die API kann bestimmen, welche Daten abgerufen, erstellt oder aktualisiert werden dürfen – und von wem. Dadurch entsteht eine Kontrollschicht zwischen der Anwendung und den Daten. Würde ein Browser ohne ausreichende Schutzmaßnahmen direkt mit einer Datenbank verbunden, könnten Informationen oder Vorgänge offengelegt werden, die vertraulich bleiben sollten. In Coderblock kann der Agent im Dialog ein Postgres-Datenbankschema entwerfen und anwenden. Standard-Web-Apps verwenden ein eigenes Supabase-Projekt mit Postgres, Auth, Storage und Row Level Security. Im Bereich Backend können Sie außerdem Tabellen, authentifizierte Benutzer, Speicher und Funktionen einsehen.

REST-APIs und Webhooks

APIs und Webhooks arbeiten in unterschiedliche Richtungen. Bei einer herkömmlichen API-Anfrage fragt Ihre Anwendung etwas ab:

„War die Zahlung erfolgreich?“

Bei einem Webhook informiert ein anderer Dienst Ihre Anwendung von sich aus darüber, dass etwas passiert ist:

„Die Zahlung wurde soeben erfolgreich abgeschlossen.“

Webhooks eignen sich besonders für Ereignisse, die erst später eintreten, etwa Zahlungen, Versandaktualisierungen oder Änderungen am Status einer Bestellung. Sie müssen jedoch überprüft und sicher verarbeitet werden. Im verwalteten Stripe-Ablauf von Coderblock kann die Plattform die Webhook-Konfiguration übernehmen. Im BYOK-Modus fordert der Agent den geheimen Stripe-Schlüssel sicher an und konfiguriert den Webhook automatisch.

REST und GraphQL

REST und GraphQL sind zwei unterschiedliche Ansätze für die Kommunikation zwischen Anwendungen. Bei REST arbeiten Sie normalerweise mit mehreren Endpunkten, die verschiedene Ressourcen repräsentieren. GraphQL verwendet stattdessen eine Abfrageschnittstelle, über die der Client genau angeben kann, welche Daten er erhalten möchte. GraphQL kann besonders nützlich sein, wenn die Datenanforderungen komplex sind und der Client mehr Kontrolle über die Antwort benötigt. REST ist dagegen weitverbreitet und häufig leichter zu verstehen. Keiner der beiden Ansätze ist jedoch grundsätzlich besser. Die richtige Wahl hängt von der Architektur des Dienstes, den Produktanforderungen, dem Team und der Art des verwendeten Clients ab.

Authentifizierung und Autorisierung sind nicht dasselbe

Zwei Begriffe werden häufig verwechselt: Authentifizierung und Autorisierung. Der Unterschied ist einfach. Authentifizierung:

„Wer sind Sie?“

Autorisierung:

„Was dürfen Sie tun?“

Stellen Sie sich eine Plattform mit Kunden und Administratoren vor. Die Anmeldung bestätigt, dass Sie tatsächlich ein bestimmter Benutzer sind. Das bedeutet jedoch nicht automatisch, dass Sie sämtliche Daten der App einsehen dürfen. Ein Kunde könnte seine eigenen Buchungen sehen dürfen. Ein Administrator könnte die Buchungen aller Kunden einsehen dürfen. Die zugrunde liegende Identitätsinformation ist vom selben Typ, die Berechtigungen unterscheiden sich jedoch.

Was ist mit API-Schlüsseln?

Ein API-Schlüssel identifiziert häufig die Anwendung oder den Dienst, die beziehungsweise der eine Anfrage stellt. Eine authentifizierte Sitzung kann dagegen den angemeldeten Benutzer identifizieren. Beides sollte nicht als universeller Zugangspass betrachtet werden.

Berechtigungen müssen separat definiert und zusätzlich auf Server- oder Datenbankebene durchgesetzt werden. In Coderblock können Sie direkt im Chat Folgendes anfordern:

„Füge eine Anmeldung und Benutzerkonten hinzu.“

Der Agent kann Supabase Auth, Registrierungs- und Anmeldeseiten, Sitzungsverwaltung, geschützte Routen und mit dem authentifizierten Benutzer verknüpfte Row Level Security konfigurieren. Apps enthalten außerdem eine grundlegende Struktur für Profile und Rollen. Sie müssen also weder manuell eine Passworttabelle erstellen noch die Authentifizierungslogik von Grund auf selbst implementieren.

Wo sollten API-Schlüssel gespeichert werden?

Private Zugangsdaten sind ein weiterer entscheidender Sicherheitsaspekt. Ein geheimer API-Schlüssel darf weder im Frontend abgelegt noch auf GitHub veröffentlicht oder in einem für Benutzer zugänglichen Feld gespeichert werden. Wenn ein Coderblock-Projekt ein Geheimnis benötigt, kann der Agent es über eine sichere Abfrage von Umgebungsvariablen erfassen. Der Wert wird im serverseitigen Secrets-Speicher des Projekts abgelegt und weder dem Frontend-Code noch der Unterhaltung hinzugefügt.

So planen Sie eine Funktion, die eine API verwendet

Wenn Sie eine App mit einem KI-Builder erstellen, müssen Sie nicht bei der Technologie anfangen. Beginnen Sie mit dem gewünschten Ergebnis für den Benutzer. „Zeige Kunden den Lieferstatus ihrer Bestellung“ ist hilfreicher als:

„Füge eine API hinzu.“

Davon ausgehend können Sie festlegen, was benötigt wird.

1. Datenquelle bestimmen

Welches System enthält die richtigen Informationen? Ihre Datenbank? Ein externer Dienst? Stripe? Ein Versandmanagementsystem? Es muss eine eindeutige verlässliche Datenquelle geben.

2. Dokumentation prüfen

Prüfen Sie vor der Integration eines Dienstes:

• die verfügbaren Endpunkte;
• die Authentifizierungsmethoden;
• die Testumgebungen;
• die Nutzungslimits;
• die Formate von Anfragen und Antworten;
• ob Webhooks unterstützt werden.

3. Fehler einplanen

Was geschieht, wenn der externe Dienst langsam ist? Was passiert, wenn er vorübergehend nicht erreichbar ist? Was geschieht, wenn er unvollständige Daten zurückgibt? Eine gut konzipierte App benötigt auch dann ein klar definiertes Verhalten, wenn eine API nicht wie erwartet antwortet.

4. Ein- und ausgehende Daten validieren

Gehen Sie nicht davon aus, dass alle von einem externen Dienst empfangenen Daten immer korrekt sind. Daten müssen überprüft werden, bevor sie verwendet oder gespeichert werden.

5. Berechtigungen begrenzen

Eine Integration sollte nur auf das zugreifen können, was sie tatsächlich benötigt. Wenn ein Dienst Zahlungen lesen muss, bedeutet das nicht zwangsläufig, dass er sie auch ändern dürfen sollte.

6. Geheimnisse schützen

Private Zugangsdaten müssen auf der Serverseite bleiben. Der Browser darf niemals einen API-Schlüssel erhalten, mit dem eingeschränkte Vorgänge ausgeführt werden können.

7. Vor dem Produktivstart testen

Verwenden Sie nach Möglichkeit die Testumgebung des Dienstes. Testen Sie nicht nur erfolgreiche Vorgänge, sondern auch abgelehnte Anfragen, Fehler, Zeitüberschreitungen, Duplikate und Stornierungen.

8. Unnötige Anfragen vermeiden

Nicht alle Informationen müssen bei jedem Laden einer Seite erneut abgefragt werden. Wenn es die Daten erlauben, kann Caching die Antwortzeiten, die Anzahl der Anfragen und die Integrationskosten reduzieren.

Mit APIs in Coderblock arbeiten

Mit Coderblock werden APIs Teil desselben dialogbasierten Workflows, mit dem Sie auch den Rest der App erstellen. Sie können mit einer Idee oder einer Produktvorlage beginnen und die KI bitten, Frontend, Backend und Datenbank zu erstellen.

Wenn Sie eine Integration hinzufügen möchten, sollten Sie das gewünschte Verhalten möglichst genau beschreiben. Zum Beispiel:

„Füge einen Kontozugang hinzu. Jeder Kunde darf nur seine eigenen Buchungen sehen. Wenn der externe Terminplanungsdienst nicht verfügbar ist, zeige eine verständliche Meldung an und ermögliche dem Benutzer, es erneut zu versuchen.“

Eine solche Anweisung vermittelt nicht nur, welche Technologie verwendet werden soll, sondern vor allem, was in der App geschehen soll. Der Agent kann die technische Umsetzung übernehmen, während Sie das Ergebnis in der Live-Vorschau unter coderblock.dev prüfen und im Chat weiter verfeinern.

Warum API-Grundwissen auch ohne Programmierkenntnisse nützlich ist

Sie müssen kein Entwickler sein, um das Konzept einer REST-API zu verstehen. Doch Grundkenntnisse verändern die Art und Weise, wie Sie eine App planen. Sie helfen Ihnen zu verstehen, warum eine Stripe-Integration etwas anderes ist als eine Datenbankanbindung, warum sich ein Webhook von einer herkömmlichen API-Anfrage unterscheidet und warum ein API-Schlüssel niemals im Frontend offengelegt werden darf. Vor allem helfen sie Ihnen dabei, bessere Prompts für die KI zu formulieren.

Anstatt lediglich Folgendes zu verlangen:

„Füge eine API hinzu.“

können Sie beschreiben, was geschehen soll, welche Daten verwendet werden sollen, wer darauf zugreifen darf und was passieren soll, wenn etwas schiefgeht. Die KI kann einen Großteil der technischen Komplexität übernehmen.

Je klarer Sie jedoch das gewünschte Verhalten beschreiben, desto mehr Kontrolle haben Sie über das Produkt, das Sie erstellen.