Vortrag 6: Restful API design
Warum REST mehr als HTTP mit XML ist
REST= Representational State Transfer
Als Beispiel wird „ein Büchershop (guess which one)“ genutzt.
Das ganze soll jetzt auf Mobile Endgeräte, „wir brauchen eine App“
Also braucht man eine Api.
die zu implementierenden Schnittstellen sind aus dem „Legacy“ System vorgegeben.
REST möchte:
Für eine Web API
http bewusst nutzen
Bedenken, das Web ist ein verteiltes Medium
Vorkenntnisse über APIs sollten minimiert werden (einfache Einarbeitung).
1 Methode ergibt eine REssource
also Buch Nr Buch-ID —-> http://site/api/book/book-id
2 Methoden, eine Ressource
addToCart
getCartInfo
http://site/api/cart/cart-id
Man muss sich immer die Frage stellen, was kommt in die URI, was in die Parameter
Alles was ein „Ding“ ist in die Uri, der Rest in die Parameter
Aktionen entsprechen Methoden
Aktionen auf Ressourcen sind nicht Teil der URI sondern http-Methoden
Dies ist später in
der API Doku zu beschreiben
Übliche Verhaltensmuster sind
GET->Anzeigen
Post Anlegen oder Ergänzen
PUT Anlegen oder Schreiben
Es sind pro Entity mehrere URI möglich
Http Möglichkeiten nutzen, Error Meldungen, Last Sharing etc.
Caching kann im Header eingestellt werden, also nutzen, gerade auch für mobile Geräte.
ETags definieren den Zustand einer Ressource. Auch diese sind sinnvoll!
Links: Echtes REST
Link-Semantik definieren
Ressourcen mit Referenzen verknüpfen
Wissen über die API also verlagern in die Link Annotation
Die Art des Links kann in einem Annotation type wie rel definiert werden.