Das Interesse an REST ist doch recht hoch und der Raum Atlanta, der so um die 200 Leute fassen sollte, ist zu einem Drittel gefüllt. Um das obige Thema kümmern sich in wechselnder Folge Stefan Tilkov und Phillip Ghadir.  Stefans Vorträge sind immer recht kurzweilig und so hoffe ich, aus einem rein theoretischen Thema, heute Abend gut informiert/motiviert und überzeugt, herauszugehen. 

Die Einführung macht Stefan und erzählt ein wenig über die Geschichte von REST. Eigentlich läuft es unter dem Strich darauf hinaus, dass man HTTP dafür einsetzt, wofür es gemacht wurde und nicht, wie im Falle von Web Services;  als Mittel zum Zweck (Port 80) einsetzt.  Eine weitere Grundaussage: Alle Dinge sind adressierbar  und können somit als eigenständige Entität  benutzt werden. Das könnte so etwas wie das statische Äquivalent zur Closure sein. REST selber wird von den Teilnehmern heute nur vereinzelt eingesetzt, mit Web Services sind aber fast alle schon irgendwie in Berührung gekommen. Letztere mag offensichtlich kaum jemand und der Einsatz ist wohl nicht immer technisch getrieben. Eine Frage, die ich Stefan oft habe stellen hören: Warum kann man in einem Unternehmen nicht genauso 'suchen', wie man es, auf ganz natürliche Art und Weise, von Google gewohnt ist?  Das Web hat bewiesen, dass es funktioniert, kann man das nicht übertragen?

Phillip Ghadir steigt nun in die Details ein, was konkret das RESTful Design oder das Mapping lokaler Interface-Funktionen auf die verfügbaren HTTP - Aufrufe (GET, POST, PUT,...) beschreibt.

Nach der Kaffeepause ( ich habe tatsächlich dem leckeren Gebäck widerstanden!) steigt Stefan in die Details ein, die REST ausmachen:

  • Identifiable Resource (alle wichtigen Dinge im Web haben eine eigene URI. Ein besonders schlechtes Gegenbeispiel ist JSF! :-)
  • Uniform Interface (GET, PUT, POST,...), Methoden sind Save (Client kann sie immer nutzen), Idempotent (Methode kann immer wieder sicher aufgerufen werden)
  • Formate für den Transport von Semantik (plain XML (validation possible), (X)HTML, JSON -> default choice 2012, RDF)
  • Stateless communication (man kann jedem Request ansehen, was er tut und er ist in sich abgeschlossen)

Interessant der Ansatz, eine Session auch als Ressource zu sehen und ihr eine URI zu verpassen. Das bedeutet etwas mehr Arbeit für den Server, hat aber den Charme, dass man beispielsweise einen Warenkorb wetierleiten und durch jemand anderen bearbeiten lassen könnte.

Jetzt geht es um Caching. Ein probates Mittel sind ETags. Je eingehender man sich mit der Materie beschäftigt, desto schneller stößt man auf die Probleme, die unter der Oberfläche lauern.  So groß das Potential auch sein mag, ohne ein gehöriges Maß an Erfahrung, kann man hier auch viele Dinge falsch machen. 

Ich mache jetzt etwas richtig und gehe in die Mittagspause!

Patterns & Antipatterns

Antipattern:

  • Tunneling 
    • alles was nicht mit GET gemacht auch mit GET machen <URI Tomcat>/admin/shutdown => Amazon macht dass...
    • das gleiche Problem auch mit POST
  • Ignoring Caching 
  • Standardisierte Fehlercodes nicht nutzen
  • Misusing Cookies

Pattern:

  • Collection Resource (related resources are accessed together)
  • Paging Collection ( Result sets are too large to be retrieved at once) - create and return subsets
  • Read-only View (spezialized views on one or more collections of resources)
  • Resource Creation (resources are created concurrently and  need unique URIs)
  • Notification Polling (clients needs to know about updates to resources) - RSS / Atom Feed
  • Conflict Handling (protection against concurrent modification)
  • Saved Search (complex querys)
  • Canonical representation (ensure lowest common denominator of processing)
  • Externalized Client Cache

JAX-RS 2.0 (public draft)

Atlernativ Spring MVC, Spark, Play! (in Java)

Ein praktisches Beispiel zur Client- und Serverseitigen Implementierung in Folien gegossen. Nichts, was man hier wiedergeben könnte.

RESTful SOA

Transaktionen sind problematisch in REST-Services. Als Beispiel können Transaktionen aus dem EE Bereich dienen (Beispiel für gutes Design). Verteilte Transaktionen über Services machen jedoch keinen Sinn. Neben den technischen gibt es auch fachliche Transaktionen, die beliebig lange dauern können. Auch hier treffen wir wieder auf die Resource in Form einer Transaktion. Hier sind sogar Verlinkungen zwischen System denkbar, was ein sehr mächtiges Feature wäre.

Umsetzung von REST in SOA Welt:

  • Ensure Web apps are RESTful
  • Expose machine-readable information via HTTP GET
  • Distribute notifications via Atom Feeds
  • Manage metadata with RESTful resources
  • Ship RESTful client libraries
  • Adopt existing infrastructure
  • Use WS* for political reasons (the better wins in long term)

Die beste Dokumentation für eine RESTful API ist eine Web-App, die genau dieses API benutzt und damit dokumentiert!