REST-Prinzipien

REST-Prinzipien (Representational State Transfer) sind Grundprinzipien für das Design von Web-APIs, die eine einfache und standardisierte Kommunikation zwischen Client und Server ermöglichen. Hier sind die wichtigsten REST-Prinzipien und ihre Anwendung:

1. Ressourcenorientierung

• REST-APIs orientieren sich an Ressourcen. Eine Ressource ist eine Einheit, die über eine eindeutige URL adressiert wird.
• Ressourcen sind in der Regel Substantive und sollten klar benannt werden, z.B. /users, /products, /orders.
• Beispiel:
  • GET /users: Gibt eine Liste aller Benutzer zurück.
  • GET /users/1: Gibt die Details des Benutzers mit der ID 1 zurück.

2. Verwendung standardisierter HTTP-Methoden

• REST nutzt die standardisierten HTTP-Methoden (Verben), um Operationen auf Ressourcen auszuführen:

  • GET: Zum Abrufen von Daten.
  • POST: Zum Erstellen neuer Daten.
  • PUT: Zum vollständigen Aktualisieren einer Ressource.
  • PATCH: Zum teilweisen Aktualisieren einer Ressource.
  • DELETE: Zum Löschen einer Ressource.

• Beispiel:

  • POST /users: Erstellt einen neuen Benutzer.
  • PUT /users/1: Aktualisiert die gesamte Ressource Benutzer mit ID 1.
  • PATCH /users/1: Aktualisiert nur bestimmte Felder der Ressource.
  • DELETE /users/1: Löscht den Benutzer mit ID 1.

3. Statelessness (Zustandslosigkeit)

• Jeder API-Request sollte alle Informationen enthalten, die für die Bearbeitung nötig sind, ohne dass der Server vorherigen Kontext behält.

• Das bedeutet, dass der Server keine Informationen über frühere Anfragen speichert. Jeder Request ist eigenständig und unabhängig.

• Authentifizierung und alle erforderlichen Daten müssen bei jeder Anfrage übergeben werden (z.B. in den Headern).

• Beispiel:

  • Ein Request mit Authentifizierung muss immer das Token übermitteln, damit der Server ihn verifizieren kann, da der Server den Status des Benutzers nicht speichert.

4. Repräsentation einer Ressource

• Eine Ressource wird in einem bestimmten Format repräsentiert, meist JSON oder XML.

• Der Client gibt oft im Accept-Header an, welches Format er erwartet, und der Server antwortet entsprechend.

• Beispiel:

  • Accept: application/json im Header signalisiert dem Server, dass JSON erwartet wird.
  • Der Server könnte alternativ auch application/xml unterstützen, wenn der Client XML bevorzugt.

5. Selbstbeschreibende Nachrichten

• Die Struktur und Bedeutung einer Anfrage/Antwort sollten durch die Nachricht selbst ersichtlich sein, sodass zusätzliche Dokumentation minimiert wird.

• Jeder Request und jede Response sollte Informationen enthalten, die eine eindeutige Interpretation ermöglichen, z.B. durch Header, Content-Typen und Statuscodes.

• Beispiel:

  • Ein GET /users/1-Request könnte als Antwort einen Statuscode 200 OK und einen JSON-Body zurückgeben, der den Benutzer beschreibt.
  • Ein DELETE /users/1-Request, der auf eine nicht vorhandene Ressource zugreift, gibt 404 Not Found zurück.

6. HATEOAS (Hypermedia as the Engine of Application State)

• HATEOAS bedeutet, dass die API zusätzliche Links und Navigationshinweise bereitstellen sollte, um den Client durch die API zu führen.

• Jede Antwort enthält Verweise auf andere mögliche Aktionen, sodass der Client „weiß“, wie er mit der API navigieren kann.

• Beispiel:

  • Ein GET /users/1-Request gibt den Benutzer zurück und könnte im JSON-Response zusätzliche Links enthalten:

    {
      "id": 1,
      "name": "John Doe",
      "email": "johndoe@example.com",
      "links": [
        { "rel": "self", "href": "/users/1" },
        { "rel": "friends", "href": "/users/1/friends" },
        { "rel": "posts", "href": "/users/1/posts" }
      ]
    }

7. Client-Server-Architektur

• REST basiert auf einer klaren Trennung von Client und Server, was bedeutet, dass sich beide unabhängig voneinander weiterentwickeln können.
• Der Client kümmert sich um die Darstellung und Interaktion, während der Server die Datenverwaltung und Logik übernimmt.
• Diese Trennung erlaubt es, verschiedene Clients (z.B. Web-App, mobile App) mit dem gleichen Server zu verbinden.

8. Cachebarkeit

• REST-APIs sollten Cache-Header verwenden, um anzugeben, welche Antworten gecacht werden können und wie lange.

• Caching kann die Effizienz der API steigern, indem es unnötige Anfragen vermeidet.

• Beispiel:

  • Der Server sendet den Header Cache-Control: max-age=3600, um anzugeben, dass die Antwort für eine Stunde gecacht werden kann.