EMZETT.REST
Kurz: Representational State Transfer — ein Architekturstil für Web-APIs, bei dem Ressourcen über feste URLs und Standard-HTTP-Methoden (GET, POST, PUT, DELETE) angesprochen werden.
Genauer: Zentrale Prinzipien: zustandslos (jede Anfrage enthält alle nötigen Informationen, der Server merkt sich nichts zwischen Anfragen), ressourcenorientiert (URLs stehen für Dinge, nicht für Aktionen — /users/5 statt /getUser?id=5) und nutzt HTTP-Statuscodes zur Fehler-/Erfolgsrückmeldung. Ist kein Protokoll, sondern eine Konvention, wie man HTTP für APIs nutzt.
Im Detail
GET /users/5 - einen Nutzer abrufen
POST /users - einen neuen Nutzer anlegen
PUT /users/5 - einen Nutzer komplett ersetzen
PATCH /users/5 - einzelne Felder eines Nutzers ändern
DELETE /users/5 - einen Nutzer löschen
Der Begriff “Zustandslos” ist zentral und oft missverstanden: er bedeutet nicht, dass die Anwendung keinen Zustand hat (ein Nutzerkonto ist natürlich gespeichert), sondern dass der Server sich NICHT merkt, in welchem Kontext eine vorherige Anfrage stattfand — jede Anfrage muss alle nötigen Informationen (z. B. ein Auth-Token) selbst mitbringen. Das macht REST-APIs einfacher zu skalieren (jeder Server-Knoten kann jede Anfrage unabhängig beantworten, ohne geteilten Sitzungszustand) und einfacher zu debuggen (jede Anfrage ist für sich verständlich).
“REST” ist streng genommen ein Architekturstil mit mehreren definierten Constraints (u. a. auch Cacheability und eine einheitliche Schnittstelle), keine feste Technologie oder ein Protokoll — in der Praxis wird der Begriff heute oft lockerer für “eine JSON-über-HTTP-API mit sinnvollen URLs” verwendet, ohne dass streng alle ursprünglichen REST-Prinzipien eingehalten werden. Alternativen wie GraphQL oder gRPC lösen dieselbe Grundaufgabe (Client-Server-Kommunikation über eine API) mit anderen Kompromissen, etwa flexiblerer Datenabfrage bei GraphQL.
Entstehungsgeschichte
Der Begriff REST wurde 2000 von Roy Fielding in seiner Doktorarbeit geprägt, einem der Mitautoren der HTTP-Spezifikation selbst — REST beschreibt dabei im Kern die Architekturprinzipien, die dem Web bereits zugrunde lagen (Ressourcen über URLs, zustandslose Anfragen, Caching über HTTP-Header), formalisiert als übertragbares Muster für API-Design. Das erklärt, warum REST-APIs sich so natürlich mit Standard-HTTP-Mechanismen (Statuscodes, Caching-Header, Content-Negotiation) verbinden — sie sind im Grunde eine bewusste, konsequente Anwendung der Web-eigenen Architektur auf programmatische Schnittstellen statt auf menschlich gebrowste Websites.
HATEOAS — das oft ignorierte Prinzip
Eines der ursprünglichen REST-Constraints wird in der Praxis am häufigsten ignoriert: HATEOAS (Hypermedia as the Engine of Application State) verlangt, dass eine API-Antwort nicht nur Daten, sondern auch Links zu möglichen nächsten Aktionen enthält — ein Client soll sich durch eine API “navigieren” können, ähnlich wie ein Mensch durch verlinkte Webseiten klickt, statt die komplette URL-Struktur vorab dokumentiert kennen zu müssen. Die allermeisten heute als “REST-API” bezeichneten Schnittstellen implementieren HATEOAS nicht und liefern stattdessen einfach reine Datenobjekte zurück — pragmatisch weit verbreitet, aber streng genommen kein vollständiges REST im ursprünglichen Sinne Fieldings.
Statuscodes richtig nutzen
Eine gut designte REST-API nutzt den vollen HTTP-Statuscode-Bereich aussagekräftig statt nur 200 (Erfolg) und 500 (Serverfehler): 201 Created nach erfolgreichem Anlegen einer Ressource, 204 No Content bei erfolgreicher Löschung ohne Rückgabewert, 400 Bad Request bei fehlerhafter Client-Eingabe, 401 Unauthorized/403 Forbidden bei fehlender/unzureichender Berechtigung, 404 Not Found bei nicht existierender Ressource, 409 Conflict bei Konflikten (z. B. doppeltem Anlegen). Diese Differenzierung erlaubt es Client-Code, programmatisch sinnvoll auf unterschiedliche Fehlerfälle zu reagieren, statt jeden Fehler gleich zu behandeln.