SOA lebt! Services mit REST

29. Juli 2015

Über SOA wird nicht mehr viel geredet, und Web Services sind old-school. Heute macht man REST! REST-Services! JSON über HTTP(S). Nix SOAP.

Ich spare mir jetzt den Rant darüber, dass Web Services nach wie vor ihre Daseinsberechtigung haben und auch absehbar haben werden. Ich freue mich auf der anderen Seite darüber, dass sich in der REST-Welt Erkenntnisse durchsetzen, die in der SOA-Welt kalter Kaffee sind.

 

Die wichtigste: REST-basierte Schnittstelle != Service

Anders ausgedrückt: Nur weil ich mit ASP.NET Web API eine JSON-basierte REST-Schnittstelle veröffentliche, hat das noch nichts mit einem Service (als Konzept im Sinne von SOA) zu tun.

Damit das nicht falsch verstanden wird: Es spricht überhaupt nichts dagegen, die übliche Abbildung von CRUD-Operationen auf REST-Aufrufe zu machen und damit seine AngularJS-Anwendung mit Daten zu versorgen. Nur hat das nichts mit Service-Orientierung zu tun.

Man sollte es sich definitiv zwei mal überlegen, ob man diese Aufrufe (und damit die internen Datenstrukturen und Methoden) auch für externe Clients zugreifbar macht.

Zum einen, weil man sich selbst damit keinen Gefallen tut. Die Gründe sind die gleichen, die schon zu “SOA mit Web Service”-Zeiten galten: Enge Kopplung, Qualitätsanforderungen wie Versionierung, QoS-Tracking, Security, … . Alles aus SOA-Zeiten bekannte Themen.

Zum anderen aber auch, weil simple CRUD-Operationen auf als bekannt vorausgesetzten Datenstrukturen dem Client nicht das bieten, was er erwartet und benötigt.

Service-Orientierung mit REST…

Was unterscheidet einen öffentlichen REST-Service von einer privaten REST-Schnittstelle?

Die weitreichendsten Konsequenzen hat sicher HATEOAS als Designansatz.

Kurz gesagt geht es bei HATEOAS darum, dass eine Datenstruktur die ich über einen REST-Service bekomme, nicht nur die Nutzdaten selbst beinhaltet. Geliefert werden immer auch die notwendigen URLs für Navigation (zu abhängigen Daten), aber auch für die möglichen Operationen (z.B. zum Löschen, wenn die Berechtigungen das zulassen). So kann man sich von einer Root-URL des Service anhand der Daten durch sämtliche Datenstrukturen und Operationen hangeln, ohne dass es weiterer Informationen bedarf.

HATEOAS liefert damit dynamisch die Informationen, die bei einem klassischen Web Service statisch über die WSDL bereitgestellt wird.

Andere Themen (Versionierung, coarse-grained Operationen, …) sind unmittelbar aus der Web Services-Welt übertragbar. Wieder andere haben nur in der einen oder nur der anderen Welt eine Entsprechung. Beispiele: Viele WS-*-Standards auf der einen Seite, HTTP Verbs und Mime-Types auf der anderen Seite.

Natürlich haben die unterschiedlichen Technologie-Stacks und nicht zuletzt auch unterschiedliche Herangehensweise bzgl. Metainformationen (dynamisch bei REST, statische in der WSDL bei Web Services) ihre Konsequenzen bzgl. des Service-Designs. Das ändert aber nichts daran, dass auch bei REST-Services ein bewusstes Schnittstellendesign – unabhängig von den Code-Generierungs-Ansätzen eines Werkzeugs – notwendig ist.

 

Wer sich damit tiefer auseinandersetzen will: Jeremy Likness hat eine Serie von Vorträgen auf Channel 9 veröffentlicht: “Web API Design Jumpstart

  1. Introduction
  2. Basic Design
  3. Configuration
  4. Validation and Error Handling
  5. Security
  6. Advanced Design

Teil 2 ist der interessanteste bzgl. grundlegender Designfragen, Teil 6 ergänzt das Thema Versionierung. Die anderen Teile sind sicher auch nicht uninteressant, werden aber für ASP.NET MVC-Entwickler nichts grundsätzlich neues bringen.