Was ist eine REST-API?

Eine REST-API ist eine API, die dem Architekturstil REST folgt: Ressourcen unter URLs, zustandslose Anfragen und standardisierte HTTP-Methoden. REST – Representational State Transfer, definiert in Roy Fieldings Dissertation aus dem Jahr 2000 – ist ein Stil, kein Protokoll und kein Standard: eine Reihe von Constraints, die zusammen eingehalten APIs hervorbringen, die das gesamte Web bereits zu konsumieren, zu cachen und zu skalieren weiß.

Das Wichtigste in Kürze

Ein vollständiger CRUD-Zyklus in reinem HTTP

Der ganze Stil in vier Anfragen – genau das sendet am Ende jedes Framework und jedes SDK:

POST /v1/posts                     →  201 Created            anlegen
{ "title": "Hello REST" }             Location: /v1/posts/8fk2

GET /v1/posts/8fk2                 →  200 OK                 lesen
                                      { "title": "Hello REST", … }

PUT /v1/posts/8fk2                 →  200 OK                 ersetzen
{ "title": "Hello again" }            (PATCH würde Felder ändern)

DELETE /v1/posts/8fk2              →  204 No Content         löschen
GET /v1/posts/8fk2                 →  404 Not Found          …und er ist weg

Derselbe Zyklus über SDKs, die die REST-Aufrufe verpacken:

// JavaScript / Node.js — Back4app JS SDK
// The REST semantics, wrapped: create, read, update, delete
const post = new Parse.Object('Post');
post.set('title', 'Hello REST');
await post.save();                            // POST   /classes/Post      → 201

const fetched = await new Parse.Query('Post')
  .get(post.id);                              // GET    /classes/Post/:id  → 200

fetched.set('title', 'Hello again');
await fetched.save();                         // PUT    /classes/Post/:id  → 200

await fetched.destroy();                      // DELETE /classes/Post/:id  → 200

// Flutter / Dart — Back4app Flutter SDK
// The REST semantics, wrapped: create, read, update, delete
final post = ParseObject('Post')..set('title', 'Hello REST');
await post.save();          // POST   /classes/Post      → 201

await post.fetch();         // GET    /classes/Post/:id  → 200

post.set('title', 'Hello again');
await post.save();          // PUT    /classes/Post/:id  → 200

await post.delete();        // DELETE /classes/Post/:id  → 200

// iOS / Swift — Back4app Swift SDK
// The REST semantics, wrapped: create, read, update, delete
var post = Post()
post.title = "Hello REST"
let saved = try await post.save()      // POST   /classes/Post      → 201

let fetched = try await saved.fetch()  // GET    /classes/Post/:id  → 200

var updated = fetched
updated.title = "Hello again"
_ = try await updated.save()           // PUT    /classes/Post/:id  → 200

try await updated.delete()             // DELETE /classes/Post/:id  → 200

// Android / Kotlin — Back4app Android SDK
// The REST semantics, wrapped: create, read, update, delete
val post = ParseObject("Post")
post.put("title", "Hello REST")
post.save()                                    // POST   /classes/Post      → 201

val fetched = ParseQuery.getQuery<ParseObject>("Post")
    .get(post.objectId)                        // GET    /classes/Post/:id  → 200

fetched.put("title", "Hello again")
fetched.save()                                 // PUT    /classes/Post/:id  → 200

fetched.delete()                               // DELETE /classes/Post/:id  → 200

Die sechs Constraints von REST

1. Client-Server – Schnittstelle und Implementierung entwickeln sich unabhängig voneinander; die Oberfläche weiß nie, wie die Speicherung funktioniert.
2. Zustandslos – jede Anfrage ist in sich abgeschlossen; der Server hält zwischen Aufrufen keine Session. Genau das erlaubt es jeder Replik, jede Anfrage zu beantworten.
3. Cachebar – Antworten deklarieren ihre Cachebarkeit selbst; GETs mit korrekten Cache-Headern lassen die gesamte Caching-Infrastruktur des Webs (Browser, CDNs, Proxys) für Ihre API arbeiten.
4. Einheitliche Schnittstelle – der Constraint, der REST ausmacht, in vier Teilen: über URIs identifizierte Ressourcen; Manipulation über Repräsentationen (Sie senden das JSON zurück, zu dem die Ressource werden soll); selbstbeschreibende Nachrichten (Methode + Header sagen alles, was zur Verarbeitung nötig ist); und Hypermedia als Motor des Anwendungszustands (Antworten verlinken die nächsten Aktionen).
5. Schichtensystem – Clients können nicht erkennen, ob sie mit dem Ursprungsserver, einem Cache oder einem Gateway sprechen; Zwischenschichten lassen sich frei einfügen.
6. Code on Demand (optional) – Server dürfen ausführbaren Code an Clients ausliefern; der einzige als optional markierte Constraint und derjenige, den die meisten APIs ignorieren.

HTTP-Methoden: Sicherheit, Idempotenz, CRUD

Die Tabelle, die auf fast jeder gut rankenden Seite fehlt – die Semantik aus RFC 9110, verdichtet:

Sicher heißt, die Anfrage ändert nichts; idempotent heißt, eine Wiederholung ändert nichts weiter. Das ist kein Detailwissen, sondern Ihre Retry-Strategie: Ein Netzwerk-Timeout bei PUT lässt sich gefahrlos wiederholen, derselbe Timeout bei POST braucht einen Idempotenzschlüssel oder eine Duplikatprüfung. Die vollständige CRUD-Zuordnung hat einen eigenen Eintrag.

Statuscodes: was wann zurückgeben

An den Unterscheidungen zwischen 401 und 403 sowie zwischen 200, 201 und 204 zeigt sich API-Handwerk: Präzise Codes machen Clients allein anhand der Statuszeile debugbar.

Ist Ihre API wirklich REST? Die Reifegradleiter

Der ehrliche Abschnitt, den kommerzielle Erklärungen weglassen. Das Richardson Maturity Model bewertet HTTP-APIs: Stufe 0 (eine URL, ein Verb, verkapptes RPC), Stufe 1 (Ressourcen unter URLs), Stufe 2 (korrekte Methoden und Statuscodes), Stufe 3 (Hypermedia – HATEOAS).

Nach Fieldings eigenem Beharren ist eine API ohne Hypermedia kein REST – er hat einen pointierten Essay geschrieben, der genau das sagt. In der Praxis ist fast jede gefeierte “REST-API” eine HTTP-API der Stufe 2: Ressourcen, Verben, Statuscodes, JSON, keine Hypermedia. Das ist weniger eine Frage der Reinheit als des Vokabulars: Wer die Leiter kennt, weiß, was der Begriff in einer Stellenanzeige bedeutet (Stufe 2) und was in der Dissertation (Stufe 3) – und bleibt sowohl von Cargo-Cult-HATEOAS als auch von pedantischen Korrekturen verschont.

REST vs. SOAP vs. GraphQL vs. gRPC

Der Vergleich mit GraphQL hat einen eigenen, ausführlichen Eintrag.

Konventionen, die eine REST-API angenehm machen

Über die Constraints hinaus gibt es Konventionen, nach denen Konsumenten Sie stillschweigend bewerten: Ressourcen als Substantive im Plural (/posts, nicht /getPost); höchstens eine Verschachtelungsebene (/posts/8fk2/comments, dann Schluss); Paginierung für jede Collection – cursorbasiert für Tiefe und Stabilität, mit durchgesetzten Limits; Filtern und Sortieren als Query-Parameter, nicht als Endpoint-Varianten; Versionierung mit expliziter Richtlinie (Pfad /v1/ oder Header – entscheiden Sie sich für eins, veröffentlichen Sie Deprecation-Fristen); Content Negotiation, die respektiert wird (Accept, Content-Type); und Fehler als strukturiertes JSON mit einem maschinenlesbaren Code statt bloßer Prosa. Nichts davon steht in der Dissertation – und doch macht all das den Unterschied zwischen einer API, die Entwickler empfehlen, und einer, die sie ertragen.

Typische Anwendungsfälle

• Öffentliche und Partner-APIs – die Allgegenwart von REST ist das Feature: Jede Sprache, jedes Werkzeug und jeder Entwickler spricht sie.
• Backends für mobile und Web-Apps – Ressourcen-CRUD über HTTP entspricht der Art, wie die meisten App-Screens tatsächlich Daten konsumieren.
• Nahtstellen zwischen Microservices – interne Verträge, bei denen sich das HTTP-Tooling (Gateways, Tracing, Caching) bezahlt macht.
• Integrationen im Webhook-Stil – Systeme benachrichtigen Systeme mit einfachen HTTP-Aufrufen, die beide Seiten ohnehin verstehen.
• Automatisch generierte Daten-APIs – Plattformen, die eine Datenbank als REST-Ressourcen bereitstellen – der schnellste Weg vom Schema zur funktionierenden API.

Sollten Sie REST verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Feste Repräsentationen passen nicht zu vielfältigen Clients. Over- und Underfetching sind die strukturelle Schwäche von REST; Sparse Fieldsets und Expansion-Parameter mildern sie, GraphQL setzt auf ein anderes Design.
• Kein verpflichtender Vertrag. Nichts erzwingt eine OpenAPI-Spezifikation, daher sind viele REST-APIs nur durch Überlieferung dokumentiert; Disziplin ist freiwillig, während gRPC und GraphQL sie strukturell verankern.
• Zustandslosigkeit wiederholt Kontext. Authentifizierungs- und Tenant-Kontext reisen mit jeder Anfrage – in Bytes günstig, aber die Session-Semantik wandert in Tokens, und manche Abläufe (mehrstufige Transaktionen) werden umständlich.
• N+1 als eingebaute Versuchung. Das Denken in einer Ressource pro URL verleitet zu Clients mit einem Aufruf pro Element; gute APIs liefern Expansion und Batch-Möglichkeiten, bevor Konsumenten Schleifen improvisieren.
• Das Wort “REST” ist mehrdeutig. Im Alltag meist eine HTTP-API der Stufe 2, in der Dissertation eine Hypermedia-Architektur – klären Sie, was eine Spezifikation, eine Stellenanzeige oder ein Reviewer meint, bevor Sie diskutieren.

REST-APIs mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die REST-API wird hier generiert, nicht gebaut: Jede Klasse in Ihrem Datenmodell ist sofort eine Ressource – POST /classes/Post legt an, GET /classes/Post/:id liest, mit den Methoden, Statuscodes und der Location-Semantik aus dem Durchlauf oben –, abgesichert durch Schlüssel, Benutzer-Tokens und Berechtigungen auf Klassenebene an der Grenze. Die Code-Tabs zeigen denselben Zyklus über die SDKs, die nichts anderes sind als dünne, idiomatische Hüllen um genau dieses HTTP; wächst eine Operation über CRUD hinaus, fügt eine Cloud-Code-Funktion einen eigenen Endpoint in einer einzigen Datei hinzu. REST der Stufe 2, standardmäßig korrekt, vom Schema zur URL in der Zeit, die das Definieren der Klasse dauert.