REST-APIs: Grundprinzipien

In L7 haben wir gesehen, dass Microservices übers Netzwerk miteinander reden. Aber auch ein monolithisches Backend muss mit dem Frontend kommunizieren, mit Mobile Apps und mit fremden Systemen. Das Standard-Protokoll für all das ist REST – kurz für Representational State Transfer. Eine REST-API ist heute der Default für Web-Schnittstellen: jeder kennt sie, jeder kann sie konsumieren, jeder Framework unterstützt sie.

Diese Lektion liefert dir die Grundprinzipien: was ist REST überhaupt, wie sind die HTTP-Methoden zu benutzen, was bedeuten die berühmten Statuscodes (200, 404, 500 …), wie sieht ein guter Ressourcen-Entwurf aus. Damit bist du sowohl für IHK-Klausuren als auch für deinen ersten Job gut gerüstet. Eine vertiefende Behandlung liefert K51 API-Entwicklung & REST vertieft.

1) Was ist REST?

REST ist kein Standard, sondern ein Architektur-Stil. Roy Fielding hat ihn im Jahr 2000 in seiner Doktorarbeit beschrieben. Die Grundidee: das Web ist großartig – machen wir auch unsere APIs so wie das Web. Konkret: jede Sache (eine Bestellung, ein Produkt, ein Nutzer) wird als Ressource mit einer eigenen URL behandelt, und auf jede Ressource wendet man die Standard-HTTP-Methoden an (GET, POST, PUT, DELETE).

Eine schöne Analogie: stell dir REST wie einen sehr ordentlichen Bibliothekar vor. Jedes Buch hat eine eindeutige Signatur (URL). Du kannst es dir holen lassen (GET), ein neues Buch reinstellen (POST), den Titel ändern (PUT), oder es entfernen lassen (DELETE). Du redest mit dem Bibliothekar nicht in eigenen geheimen Codes, sondern in einer kleinen, festen Liste klarer Befehle, die jeder Bibliothekar versteht. Genau das macht REST aus.

2) Ressourcen: das Herz von REST

In einer REST-API ist alles eine Ressource. Eine Ressource ist eine adressierbare Sache – meist ein Geschäftsobjekt wie ein Kunde, eine Bestellung, ein Produkt. Jede Ressource hat eine eigene URL, und URLs sind Substantive im Plural:

3) Die HTTP-Methoden: das Verb für jede Aktion

REST verwendet die Standard-HTTP-Methoden, die jeder Browser, jeder Server und jede Bibliothek bereits kennt. Jede Methode hat eine klar definierte Bedeutung – das macht REST-APIs intuitiv:

4) Das CRUD-Mapping: REST in einer Tabelle

In den meisten Anwendungen geht es um vier Operationen: Create, Read, Update, Delete – kurz CRUD. REST bildet sie nahezu 1:1 ab. So sieht die volle Tabelle für Produkte aus:

5) HTTP-Statuscodes: die Antwort des Servers

Auf jede Anfrage antwortet der Server mit einem Statuscode – einer dreistelligen Zahl, die die Art der Antwort kategorisiert. Du kennst sicher 404 (Not Found) und 500 (Server Error). Es gibt fünf Gruppen, jeweils nach der ersten Ziffer:

Die wichtigsten konkreten Codes für deine Klausur und den Alltag:

• 200 OK – Anfrage erfolgreich. Standard-Antwort auf GET.
• 201 Created – neue Ressource wurde erstellt. Antwort auf erfolgreiches POST.
• 204 No Content – erfolgreich, aber keine Antwortdaten. Z.B. nach DELETE oder PUT.
• 400 Bad Request – die Anfrage ist syntaktisch oder semantisch fehlerhaft.
• 401 Unauthorized – nicht angemeldet (kein gültiges Token oder Session).
• 403 Forbidden – angemeldet, aber keine Berechtigung für diese Aktion.
• 404 Not Found – die Ressource gibt es nicht.
• 409 Conflict – Konflikt mit dem aktuellen Zustand (z.B. Duplikate).
• 500 Internal Server Error – etwas im Backend ist kaputt.
• 503 Service Unavailable – Server überlastet oder in Wartung.

Häufig verwechselt: 401 vs. 403. 401 heißt „ich weiß nicht, wer du bist" – Login fehlt oder Token abgelaufen. 403 heißt „ich weiß, wer du bist, aber du darfst das nicht" – Berechtigungs-Problem. Diese feine Unterscheidung kommt in IHK-Aufgaben gerne dran.

6) Interaktiv: eine REST-Anfrage selbst zusammenbauen

Probier es aus. Klick eine Aktion, und sieh, wie sich Methode, URL und Antwort ändern. Das ist nicht echt mit einem Server verbunden – aber genau so sehen REST-Anfragen in jedem Tool (Postman, curl, Browser DevTools) aus:

7) Die REST-Prinzipien (Constraints)

REST ist mehr als „HTTP plus Substantive". Roy Fielding hat sechs Constraints (Einschränkungen) definiert, die einen API-Stil zu „RESTful" machen. In der Praxis und in IHK-Klausuren sind diese sechs wichtig zu kennen:

8) REST vs. SOAP vs. GraphQL

REST ist nicht die einzige Möglichkeit, APIs zu bauen. In Klausuren wird gerne nach der Abgrenzung zu anderen Stilen gefragt:

9) Aufbau einer kompletten REST-Anfrage

Eine echte REST-Anfrage besteht aus mehr als nur Methode und URL. Hier die volle Anatomie:

• Request-Line: Methode + URL + HTTP-Version. Beispiel: POST /products HTTP/1.1
• Header: Metadaten als Schlüssel-Wert-Paare. Wichtigste:
  • Content-Type: application/json – Format des Bodys
  • Authorization: Bearer eyJhbGc... – Authentifizierungs-Token
  • Accept: application/json – gewünschtes Antwort-Format
• Body: die eigentlichen Daten (nur bei POST, PUT, PATCH). Format meist JSON.

Die Antwort hat denselben Aufbau, nur mit Statuscode statt Methode/URL:

• Status-Line: HTTP-Version + Statuscode + Phrase. Beispiel: HTTP/1.1 201 Created
• Header: Metadaten der Antwort. Z.B. Content-Type, Location (URL der neu erstellten Ressource).
• Body: die Antwortdaten – meist JSON.

10) Best Practices für gute REST-APIs

Gute REST-APIs unterscheiden sich von „okay" REST-APIs durch einige Konventionen, die in der Praxis wichtig sind und in Klausuren oft mitgefragt werden:

• Versionierung: API-URLs mit Version präfixieren, z.B. /v1/products. So können breaking changes neue Endpunkte (/v2/products) bekommen, ohne alte Clients zu brechen.
• Filter / Pagination per Query-Parameter: /products?category=books&page=2&size=20 – nicht über die URL-Struktur abbilden.
• Konsistente Fehler-Antworten: bei Fehler nicht nur den Status-Code, sondern eine strukturierte Fehler-Beschreibung im Body: { "error": "InvalidEmail", "message": "..." }.
• HATEOAS (optional): die Antwort enthält Links zu verwandten Ressourcen. Z.B. eine Bestellung enthält den Link zum zugehörigen Kunden. Stark in der Theorie, in der Praxis selten konsequent umgesetzt.
• HTTPS überall: REST übers Internet immer über HTTPS, nie über HTTP. Token im Klartext zu übertragen wäre ein Sicherheitsdesaster. Vgl. K11 Hashing & Verschlüsselung.
• Authentifizierung: API-Key, Basic Auth, OAuth 2.0 oder JWT. Letztere sind heute Standard für moderne Web-APIs.

11) Typische Klausurfehler

Was in IHK-Klausuren regelmäßig schief läuft:

Zusammenfassung

REST (Representational State Transfer) ist ein Architektur-Stil für Web-APIs, basierend auf HTTP. Grundidee: Ressourcen haben URLs (Substantive im Plural: /products, /users/7/orders), HTTP-Methoden sind die Aktionen auf diesen Ressourcen. Die fünf HTTP-Methoden: GET (lesen, sicher und idempotent), POST (erstellen, nicht idempotent), PUT (ersetzen, idempotent), PATCH (teilweise ändern), DELETE (löschen, idempotent). CRUD-Mapping: Create → POST, Read → GET, Update → PUT/PATCH, Delete → DELETE. Statuscode-Gruppen: 2xx Erfolg (200 OK, 201 Created, 204 No Content), 3xx Umleitung, 4xx Client-Fehler (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict), 5xx Server-Fehler (500 Internal, 503 Unavailable). Wichtige Unterscheidung: 401 = nicht angemeldet, 403 = keine Berechtigung. Die sechs REST-Constraints: Client-Server, Stateless (zustandslos – Sitzungsdaten beim Client), Cacheable, Uniform Interface (einheitliche Schnittstelle), Layered System, Code on Demand (optional). Wichtigstes Prinzip in der Praxis: Stateless – ermöglicht horizontale Skalierung. Abgrenzung zu anderen Stilen: REST (heute Standard, JSON, einfach), SOAP (XML, komplex, Enterprise), GraphQL (Query-Sprache, Client wählt Felder). Anatomie einer Anfrage: Request-Line + Header + (optional) Body. Wichtigste Header: Content-Type, Authorization, Accept. Best Practices: Versionierung (/v1/...), Filter via Query-Parameter, konsistente Fehler-Strukturen, HTTPS überall, moderne Authentifizierung (JWT, OAuth). Häufige Klausur-Fehler: Verb in URL, POST/PUT verwechselt, PUT/PATCH-Verwechslung (Datenverlust!), 200 trotz Fehler, 401/403-Mix, REST als „Protokoll" bezeichnet. REST ist die lingua franca für Web-APIs – sowohl zwischen Frontend und Backend (3-Tier) als auch zwischen Microservices. Für die Daten, die über REST fließen, ist meist JSON das Format – darum geht es in der nächsten Lektion. Vertiefung in K51 API-Entwicklung & REST vertieft mit Authentifizierung, Versionierung, OpenAPI/Swagger.