Skip to content
IRC-Coding IRC-Coding
REST HTTP Statuscodes Idempotenz Stateless OpenAPI

RESTful Design-Prinzipien: HTTP-Methoden, Statuscodes, Idempotenz & Statelessness

RESTful API Design: GET/POST/PUT/DELETE/PATCH, Statuscodes, Idempotenz, Statelessness, Sicherheit (HTTPS/Token/CORS) und Prüfungsfragen.

S

schutzgeist

1 min read

RESTful Design-Prinzipien

Dieser Beitrag ist eine Begriffserklärung zu RESTful Design-Prinzipien – inklusive Prüfungsfragen, Merkpunkte und Tags.

In a Nutshell

REST (Representational State Transfer) ist ein Architekturansatz für APIs auf HTTP-Basis: klare Methoden, Ressourcen-URIs, Statuscodes und Zustandslosigkeit.

Kompakte Fachbeschreibung

REST nutzt HTTP-Methoden für CRUD:

  • GET: lesen
  • POST: erstellen
  • PUT: vollständig ersetzen
  • PATCH: teilweise ändern
  • DELETE: löschen

REST folgt dem Prinzip der Statelessness: jeder Request enthält alle nötigen Infos; der Server speichert keinen Sitzungszustand.

Idempotenz ist wichtig für Retries:

  • idempotent: GET, PUT, DELETE
  • nicht zwingend idempotent: POST, PATCH

Ergebnisse werden über Statuscodes kommuniziert (z.B. 200, 201, 404, 500). Übliche Datenformate sind JSON/XML.

Prüfungsrelevante Stichpunkte

  • HTTP-Methoden für CRUD
  • REST ist zustandslos
  • Idempotenz: Wiederholungen dürfen keine Nebenwirkungen verdoppeln
  • Ressourcen-URIs, z.B. /api/users/123
  • Statuscodes (200, 201, 404, 500) (IHK-relevant)
  • PATCH verändert nur Teilfelder
  • Security: HTTPS, Token-Auth, CORS
  • Doku: OpenAPI/Swagger (Dokumentationspflicht)

Kernkomponenten

  1. HTTP-Methoden
  2. Ressourcen-URI-Konventionen
  3. Statuscodes (2xx/4xx/5xx)
  4. REST-Konformität (Richardson)
  5. Idempotenz-Regeln
  6. Statelessness
  7. Content Negotiation (Accept/Content-Type)
  8. JSON/XML
  9. Auth (Bearer/API-Key)
  10. OpenAPI/Swagger

Praxisbeispiel (User-API)

GET /users
POST /users
GET /users/1
PUT /users/1
PATCH /users/1
DELETE /users/1

Vorteile und Nachteile

Vorteile

  • Einfach, gut verständlich
  • Standardprotokoll (HTTP)
  • Plattform-/sprachunabhängig
  • Gut skalierbar

Nachteile

  • Kein eingebautes Session-Management
  • Kann „chatty“ werden (viele Requests)
  • Für komplexe Operationen braucht man saubere Modellierung

Typische Prüfungsfragen (mit Kurzantwort)

  1. Was bedeutet stateless? Server speichert keinen Sitzungszustand; Request muss vollständig sein.
  2. Welche Methoden sind idempotent? GET, PUT, DELETE.
  3. PUT vs PATCH? PUT ersetzt vollständig, PATCH nur Teilfelder.
  4. Was bedeutet 201? Ressource wurde erstellt.

Freie Antwort

REST ist das Rückgrat moderner Web-APIs. In Prüfungen/Projekten musst du Endpunkte sauber dokumentieren, Methoden korrekt wählen und Statuscodes sauber einsetzen.

Lernstrategie

  1. API mit Postman/curl testen.
  2. Mini-API mit CRUD-Routen bauen.
  3. Methoden/Statuscodes/Idempotenz auswendig üben.
  4. PUT/DELETE nur idempotent einsetzen.

Themenanalyse

  • Kern: HTTP, URI-Design, JSON
  • Herausforderungen: Versionierung, Fehlerbehandlung, Auth
  • Sicherheit: Zugriffskontrolle, Verschlüsselung, CORS
  • Doku: OpenAPI, Beispiele, Fehlerkatalog
  • Wirtschaftlichkeit: Standardisierung spart Zeit

Weiterführende Infos

  1. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
  2. https://developer.mozilla.org/de/docs/Web/HTTP/Methods
  3. https://restfulapi.net/
  4. https://swagger.io/specification/
Zurück zum Blog
Share:

Ähnliche Beiträge