Hoch
REST-APIs
Prinzipien einer REST-Schnittstelle und typische Endpunkt-Gestaltung.
Warum Priorität „Hoch"? Häufig Teil der Prüfung (60–79%) oder bringt viele Punkte.
Lernziele
- Die REST-Prinzipien (stateless, ressourcenorientiert, einheitliche Schnittstelle) erklären
- CRUD auf HTTP-Methoden mappen
- Ein sinnvolles Endpunkt-Schema entwerfen
REST-Prinzipien (nach Fielding)
- Client-Server: klare Trennung.
- Stateless: jeder Request trägt alle nötigen Infos; Server hält keinen Client-Zustand.
- Cacheable: Antworten können gekennzeichnet werden als (nicht-)cachebar.
- Uniform Interface: einheitliche Schnittstelle (Ressourcen-URIs + HTTP-Verben).
- Layered System: Client sieht nicht, ob hinter dem Server Proxies/LBs stehen.
- Code on Demand (optional).
CRUD-Mapping
| Operation | HTTP-Methode | URL-Muster | Status |
|---|---|---|---|
| Liste lesen | GET | /kunden | 200 |
| Eins lesen | GET | /kunden/42 | 200 / 404 |
| Anlegen | POST | /kunden | 201 Created |
| Ersetzen | PUT | /kunden/42 | 200 / 204 |
| Teil-Update | PATCH | /kunden/42 | 200 |
| Löschen | DELETE | /kunden/42 | 204 |
Beispiel-Request/Response
POST /kunden HTTP/1.1
Content-Type: application/json
{ "name": "Meier", "stadt": "Berlin" }HTTP/1.1 201 Created
Location: /kunden/42
Content-Type: application/json
{ "id": 42, "name": "Meier", "stadt": "Berlin" }Best Practices
- Ressourcen im Plural: /kunden, /artikel.
- Keine Verben in der URL (
/getKundenist anti-REST). - Filtern/Paginieren über Query-Parameter:
?seite=2&limit=20. - Beziehung:
/kunden/42/bestellungen. - Statuscodes korrekt einsetzen (201 beim Anlegen, 204 ohne Body).
Übungen
Eine AntwortWelches Endpunkt-Design ist RESTful?
Eine AntwortWelchen Status-Code gibt ein erfolgreiches POST /kunden idealerweise?