REST API

REST API (Representational State Transfer Application Programming Interface) ist ein Architekturstil für die Kommunikation zwischen Client und Server über das HTTP-Protokoll. REST wurde im Jahr 2000 von Roy Fielding in seiner Dissertation definiert und hat sich zum Standard für moderne Webschnittstellen entwickelt. RESTful APIs ermöglichen es Anwendungen, Daten auszutauschen und Operationen auf Ressourcen auszuführen - typischerweise im JSON-Format.

Grundprinzipien von REST

REST basiert auf sechs grundlegenden Prinzipien, die eine skalierbare und wartbare API-Architektur ermöglichen:

Client-Server-Architektur

Die strikte Trennung von Client und Server ermöglicht eine unabhängige Entwicklung beider Komponenten. Der Client kümmert sich um die Benutzeroberfläche, während der Server die Datenverarbeitung und -speicherung übernimmt. Diese Trennung verbessert die Portabilität und Skalierbarkeit.

Zustandslosigkeit (Stateless)

API Keys

Für Server-zu-Server-Kommunikation werden oft API Keys verwendet. Diese werden entweder im Header oder als Query-Parameter übermittelt:

# Als Header
X-API-Key: dein_geheimer_api_key

# Als Query-Parameter (weniger sicher)
GET /api/users?api_key=dein_geheimer_api_key

REST vs. andere API-Architekturen

REST ist nicht die einzige Möglichkeit, APIs zu gestalten. Hier ein Vergleich mit anderen Ansätzen:

REST eignet sich besonders gut für öffentliche APIs und Anwendungen mit klar definierten Ressourcen. GraphQL bietet mehr Flexibilität bei komplexen Datenabfragen, während SOAP in älteren Enterprise-Systemen noch verbreitet ist.

HTTP-Methoden in REST APIs

REST APIs nutzen die Standard-HTTP-Methoden, um CRUD-Operationen (Create, Read, Update, Delete) auf Ressourcen durchzuführen. Jede Methode hat eine spezifische Bedeutung:

Die Wahl der richtigen HTTP-Methode ist entscheidend für eine semantisch korrekte API. GET-Anfragen sollten keine Seiteneffekte haben (idempotent), während POST neue Ressourcen erstellt.

HTTP-Statuscodes

REST APIs kommunizieren den Erfolg oder Misserfolg einer Anfrage über HTTP-Statuscodes. Du solltest die wichtigsten Codes kennen:

Praxisbeispiel: Benutzer-API

Ein typisches Beispiel für eine REST API ist eine Benutzerverwaltung. Hier siehst du, wie die verschiedenen HTTP-Methoden in der Praxis eingesetzt werden:

GET-Request: Benutzer abrufen

Mit einem GET-Request fragst du Daten vom Server ab, ohne den Zustand zu verändern:

GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

Response (200 OK):

{
  "id": 42,
  "name": "Max Mustermann",
  "email": "max@example.com",
  "role": "developer",
  "createdAt": "2024-01-15T10:30:00Z"
}

POST-Request: Neuen Benutzer erstellen

Ein POST-Request sendet Daten an den Server, um eine neue Ressource zu erstellen:

POST /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "name": "Anna Schmidt",
  "email": "anna@example.com",
  "password": "sicheresPasswort123"
}

Response (201 Created):

{
  "id": 43,
  "name": "Anna Schmidt",
  "email": "anna@example.com",
  "role": "user",
  "createdAt": "2024-12-04T14:22:00Z"
}

URL-Design und Ressourcen

Ein gutes REST-API-Design folgt klaren Konventionen bei der URL-Struktur. Ressourcen werden als Substantive im Plural benannt:

# Gute REST-URLs
GET    /api/users              # Alle Benutzer abrufen
GET    /api/users/42           # Benutzer mit ID 42 abrufen
POST   /api/users              # Neuen Benutzer erstellen
PUT    /api/users/42           # Benutzer 42 aktualisieren
DELETE /api/users/42           # Benutzer 42 löschen

# Verschachtelte Ressourcen
GET    /api/users/42/orders    # Bestellungen von Benutzer 42
GET    /api/users/42/orders/5  # Bestellung 5 von Benutzer 42

# Schlechte URLs (vermeide Verben in URLs)
GET    /api/getUsers           # Falsch
POST   /api/createUser         # Falsch
POST   /api/deleteUser/42      # Falsch

Authentifizierung und Sicherheit

REST APIs müssen geschützt werden, da sie oft sensible Daten übertragen. Die gängigsten Authentifizierungsmethoden sind:

Bearer Token (JWT)

Die häufigste Methode ist die Verwendung von Bearer Tokens im Authorization-Header. Nach erfolgreicher Anmeldung erhält der Client einen JWT (JSON Web Token), den er bei jeder Anfrage mitsenden muss:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik1heCIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Tools für die REST-API-Entwicklung

Für die Entwicklung und das Testen von REST APIs gibt es verschiedene hilfreiche Werkzeuge:

• Postman: Grafische Oberfläche zum Testen von API-Endpunkten
• cURL: Kommandozeilentool für HTTP-Anfragen
• Swagger/OpenAPI: Spezifikation und Dokumentation von APIs
• Insomnia: Alternative zu Postman für API-Tests
• HTTPie: Benutzerfreundliches Kommandozeilentool

Mit cURL kannst du schnell API-Endpunkte von der Kommandozeile aus testen:

# GET-Request
curl -X GET https://api.example.com/users/1 \
  -H "Authorization: Bearer TOKEN" \
  -H "Accept: application/json"

# POST-Request mit JSON-Body
curl -X POST https://api.example.com/users \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Test", "email": "test@example.com"}'

REST API in der Praxis

REST APIs sind allgegenwärtig in der modernen Softwareentwicklung. Ob du eine Mobile App entwickelst, ein Frontend mit einem Backend verbindest oder Microservices integrierst - du wirst mit REST APIs arbeiten.

Als Fachinformatiker für Anwendungsentwicklung wirst du REST APIs sowohl konsumieren als auch selbst entwickeln. Typische Frameworks für die API-Entwicklung sind Spring Boot (Java), Express.js (Node.js), Django REST Framework (Python) oder Laravel (PHP). Auch für Fachinformatiker für Systemintegration sind REST APIs relevant - etwa bei der Integration von Cloud-Diensten oder der Automatisierung von Infrastruktur.

Quellen und weiterführende Links

• RESTful API Design - restfulapi.net
• Microsoft API Design Best Practices
• MDN Web Docs - HTTP
• OpenAPI Specification (Swagger)
• Roy Fielding über REST APIs