In den letzten Jahren ist REST zu einer beliebten Schnittstellentechnologie geworden. Das hat mehrere Gründe und einer davon ist, dass REST als einfache Technologie verstanden wird. Und das ist auch richtig. Gewissermaßen. Irgendwie. Fakt ist aber auch, dass man REST erstmal lernen und verstehen muss. Bei REST gerät man leicht in Versuchung zu meinen, etwas verstanden zu haben, obwohl das nur bedingt der Fall ist. REST wirkt erstmal einfach, aber REST ist vor allem auch anders. Es liegt eine andere Denkweise zugrunde. Ich haben schon mehrere REST-Services geschrieben und ebenso auch mehrere benutzt. Nun mache ich das seit Monaten und trotzdem komme ich immer wieder in die Situation, dass ich merke, dass ich etwas falsch oder zumindest nicht ganz vollständig verstanden habe.

Einführungen in REST gibt es wie Sand am Meer. Wenn man sich davon mal ein paar angesehen hat, wird man feststellen, dass es davon eine Handvoll Arten gibt. Unterschiedliche Herangehensweisen, unterschiedliche Schwerpunkte und unterschiedliche Nützlichkeit. Folgende Arten hab ich finden können:

• Typ I: Kurzpräsentation/REST in 10 Minuten: Das ist so das, was man typischerweise in der Uni gelehrt bekommt. 1-2 Folien mit den wichtigsten Punkten, ggf. ein kleines Hello-World-Beispiel. Ich hatte sogar echt Glück: Das, was auf den Folien stand, war sogar ziemlich richtig, es waren wirklich die wichtigsten Punkte und ich durfte sogar JAX-RS in ner Übung mal selbst benutzen. Mehr kann man hier nicht erwarten. Insgesamt ist das natürlich sehr oberflächlich und am Ende hat man nicht viel mehr als eine vage Idee von REST. Ziel einer solchen Einführung ist also eher blankes Unwissen durch ein „REST? Ah, ja. Schonmal gehört.“ zu ersetzen.
  • Detailgrad: niedrig
  • Schwerpunkt: Konzepte
  • Ziel: grobes Verständnis schaffen
  • Praktische Nützlichkeit: beschränkt
• Typ II: Der Ist-doch-alles-ganz-einfach-Ansatz: Ich hab mal einen Vortrag zu REST gesehen, der Anhand von eins, zwei Trivialbeispielen (ein Uhrzeit-Service…) gezeigt hat, wie leicht man einen REST-Service schreiben und ansprechen kann. REST ist ja nur ein HTTP-Request und eine Antwort. *grins* Ebenso gibt es diverse Mini-Tutorials und Blogposts, die nichts anderes machen, als ein Trivialbeispiel zeigen. Das ist dann vielleicht gut gemeint, aber von REST hat man hinterher genauso wenig Ahnung wie vorher. Wenn man dem irgend etwas abgewinnen will, dann könnte man höchstes sagen, dass sie Interesse wecken oder für Trivialfälle Copy-and-Paste-Code auffindbar machen. Sonderlichen Erkenntnisgewinn versprechen sie nicht.
  • Detailgrad: niedrig
  • Schwerpunkt: Trivialbeispiele
  • Ziel: Einfachheit vorgauken, ggf. Marketing; Interesse wecken
  • Praktische Nützlichkeit: vernachlässigbar
• Typ III: Der Framework-Ansatz: Deutlich praxisorientierter und hilfreicher sind Tutorials und Dokus zu den Frameworks. Hier bekommt man in der Regel deutlich mehr vermittelt als den Trivialkram. Frameworks sind ja i.d.R. so aufgestellt, dass sie auch für Sonderfälle Lösungen bereit stellen. Technisch sind diese Tutorials meistens ganz gut, aber eines fehlt doch: Wenn man die Werkzeuge kennt, weiß man noch nicht unbedingt, wie man sie richtig einsetzt. Wenn man eine Schreiner-Lehre macht, reicht es ja vermutlich nicht, wenn man lernt, wie man einen Hobel benutzt. Mit einem Hobel umgehen können, ist wichtig, klar. Die Frage ist aber doch eher: Wann setzte ich den Hobel ein? Das Werkzeug zu kennen, reicht nicht. So ist es auch hier: Diese Tutorials sind gut und wichtig, aber sie sind eben nur ein Teil dessen, was man wissen muss.
  • Detailgrad: hoch
  • Schwerpunkt: Technische Realisierung
  • Ziel: technische Möglichkeiten aufzeigen und erklären
  • Praktische Nützlichkeit: hoch
• Typ IV: Der architektonische Ansatz: Die fundamentale theoretische Basis von REST ist natürlich die Dissertation von Roy Fielding. Dort (und in den Tutorials, die sich daran orientieren) erfährt man, dass REST eigentlich keine Schnittstelklentechnologie und kein Kommunikationsprotokoll ist. Vielmehr ist REST ein Architekturstil bzw. -pattern. REST ist die Architektur des Web im Allgemeinen und von HTTP im Speziellen. Da REST nun eben ein Pattern ist, ist es unabhängig von konkreten Technologien wie HTTP (das ist quasi nur ein Beispiel, eine Manifestation). Demnach definiert sich REST auch nicht über URLs auf Ressourcen und HTTP-Verben, sondern über Architectural Contraints. Das ist auch alles ganz interessant und von einem gewissen Standpunkt aus auch durchaus lesenswert. Mit dem, was in der Praxis heute unter REST verstanden wird, hat das aber nur bedingt etwas zu tun. REST, wie Roy Fielding es beschreibt, ist genau genommen etwas anderes; etwas, was mit dem, was die anderen REST-Tutorials so erklären, nur bedingt etwas zu tun hat. Man mag, wie Fielding das tut, die Semantic Diffusiuon beklagen, die hier geschehen ist. Oder man akzeptiert, dass das ein normaler Vorgang ist und wir jetzt einen Architekturstil und eine Schnittstellentechnologie haben, die halt nunmal beide REST heißen. Wer sich für Architekturtheorie interessiert oder hören will, wie einer der Väter von HTTP aus dem Nähkästchen plaudert, soll die Diss gerne lesen. Wer direkt praktischen Nutzen braucht, liest besser (zuerst mal) etwas anderes.
  • Detailgrad: unterschiedlich
  • Schwerpunkt: Architektur
  • Ziel: die Theorie hinter (dem Architekturstil) REST erklären
  • Praktische Nützlichkeit: beschränkt
• Typ V: Der theopraktische Ansatz: Selbstverständlich kann man auch die Konzepte hinter der Schnittstellentechnologie erklären. Also weder die Features eines Frameworks aufzählen, noch architekturphilosophisch losgelöst von praktischen Belangen, sondern vielmehr die relevante Theorie hinter der Praxis erklären.
  • Detailgrad: mittel bis hoch
  • Schwerpunkt: Konzepte
  • Ziel: Verständnis für die richtige Anwendung schaffen
  • Praktische Nützlichkeit: hoch

Wie unschwer zu erkennen ist, bevorzuge ich die Ansätze III und V. Ich bin jedoch der Meinung dass Typ V ziemlich vernachlässigt wird. Es gibt so Zeug, aber insgesamt doch nicht so, wie ich es mir vorstelle. Ich will also versuchen, diese postulierte Lücke zu füllen. Das wird nicht in einen Blog-Post passen und außerdem recht lange dauern. Aber ich will es versuchen und die einzelnen Blog-Artikel dann hier verlinken. Ich werde sicher nicht alles erklären und man sollte vermutlich schon eine grobe Vorstellung von REST haben. Dafür verspreche ich, möglichst viel praxisrelevanter Theorie zu liefern.

1. REST ist wie Japanisch — nur anders
2. … to be continued …