Die etwas andere Einführung in REST

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 …

2 Kommentare


  1. Was würdest du als Framework empfehlen? Jersey?


  2. Hi Peter,

    kommt drauf an. Setzen wir Java mal als gegeben voraus, ist jax-rs die standardisierte API an die sich diverse Implementierungen (Jersey, Resteasy, …) halten. Das definiert schonmal das allermeiste, was man so braucht, und rax-rs ist ein wirklich guter Standard. Ob du dann Jersey oder Resteasy nimmst, ist dann gar nicht mehr so entscheidend. Im Idealfall kannst du sogar die Implementierung einfach austauschen ohne deinen Code ändern zu müssen. Die Portabilität macht aber faktisch ein bisschen Arbeit, wenn du sie unbedingt brauchst. Die Unterschiede zwischen den Implementierungen liegen im Detail (Zusatzfeatures, Konfigurationsmöglichkeiten in der web.xml, etc.) bzw. die Entscheidung macht man in aller Regel an anderen Dingen fest. Zu erwähnen ist vielleicht höchstens, dass die nicht standardisierte Resteasy-Client-API nicht so das Gelbe vom Ei ist. Der neue Standard ist da deutlich hübscher (WebTarget) und Jersey bildet hier die Referenzimplementierung.

    Wenn du nen Service schreibst, hast du in aller Regel einen Container am Start (JBoss, Glassfish, etc.) und der Container bestimmt dann die jax-rs-Implementierung (Resteasy bei JBoss, Jersey bei Glassfish). So gesehen hast du die Entscheidung dann gar nicht mehr. Du kannst natürlich auch nen Tomcat nehmen und da ne selbstgewählte jax-rs-Implementierung draufwerfen. Wenn du nen Tomcat nimmst und nen Service schreiben willst, ist die Wahrscheinlichkeit aber recht hoch, dass du mehr haben willst, als dir der nackte Tomcat liefert. Also packst du da i.d.R. Spring drauf. Spring ist meines Erachtens nicht ganz so schön wie JEE [1], aber in neueren Versionen durchaus OK. Nun bringt Spring ein eigenes Framework für Rest-Services mit, das nicht jax-rs-kompatibel ist. Damit hab ich aber keine Erfahrung.

    Die alternative zu nem Container ist Dropwizard. Da ist Jersey mit dabei. Dafür hast du leider kein CDI (und CDI ist wirklich cool). Um zumindest nicht auf DependencyInjection verzichten zu müssen, kann man da aber vergleichsweise leicht Guice oder Spring draufpacken (Weld sperrt sich leider ein wenig). Dann hast du Jersey für Rest und Spring für DI.

    So, nun alle Klarheiten beseitigt? *g*

    Fangen wir also mal lieber mit dem an, was du brauchst. Angenommen, du hast keine sonderlichen Präferenzen und bisher noch keine anderen Services, die schon in nem Container laufen, etc. Außerdem suchst du etwas, das sich leicht administrieren lässt und wenig Overhead hat. In den Fall würde ich dir zu Dropwizard raten. Wenn du DI gewohnt bist, kannst du Spring dazu nehmen (auf github findest du Beispiele dazu). Ansonsten nimmst du es einfach so, wie es kommt. Mit Dropwizard kannst du schnell loslegen ohne erst noch lernen zu müssen, wie man nen JBoss richtig konfiguriert, etc. Ich nutz das Ding ganz gerne.

    Wenn du doch andere Anforderungen hast, als von mir jetzt mal gemutmaßt, sag Bescheid und ich kann dir vielleicht was anderes raten.

    Viele Grüße

    Christian

    P.S.: Grüß mir die Uni!

    [1] Bei einem unserer Services schimpfen wir echt auf Spring, aber die Gründe sind da vielschichtiger.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.