RESTful Web Service mit .NET und ExtJs: Einleitung

Dieser Artikel ist Teil 1 einer mehrteiligen Serie, die sich mit dem Erstellen und Nutzen eines RESTful Web Service mit Hilfe von .NET und ExtJs beschäftigt.

Bevor wir richtig loslegen – und hoffentlich auch, bevor die ersten „show the code“ brüllen – ein kleines Vorwort.

REST steht für Representational State Transfer, ein Paradigma für den Zugriff auf Services. REST benutzt dabei grundsätzliche, teilweise vernachlässigte Technologien, die unter anderem das HTT-Protokoll zur Verfügung stellt. Der Begriff wurde von Roy Fielding geprägt, der zuvor auch an der Spezifikation von HTTP beteiligt war.
Webservices, die Schnittstellen per REST zur Verfügung stellen (auch RESTful Service genannt), veröffentlichen Daten unter Verwendung sogenannter Ressourcen. Jede Ressource erhält eine eindeutige Adresse (URI). Die durchzuführende Aktion ergibt sich aus der Kombination der URI einer Ressource und der Art und Weise, wie diese URI angesprochen wird.

<p<Im Gegensatz zu RPC (remote procedure call, ein anderes verbreitetes Paradigma) veröffentlichen RESTful Webservices keine Informationen über die Methode, die aufgerufen wird. Die Schnittstellen werden einzig und allein durch die veröffentlichten Ressourcen definiert.

Eine Webservice-Schnittstelle, die mit RPC-Adressierung so angesprochen wird:

http://example.com:8080/MessageService?op=GetMessage&id=7862

würde, wenn der Webservice RESTful ist, so angesprochen werden:

http://example.com/MessageService/Message/7862

HTTP, also das Protokoll, mit dem Webservices kommunizieren, unterstützt verschiedene so genannte „Verben“, die die Art und Weise des Zugriffs spezifizieren. GET und POST sind den meisten Webentwicklern gut bekannt, daneben existieren jedoch noch andere Verben, die sich REST zunutze macht:

• GET: Abruf von Inhalten
• POST: Übertragung von Daten
• HEAD: Anforderung eines reinen HTTP-Headers
• PUT: Aktualisierung von Daten
• DELETE: Löschen von Daten
• TRACE: liefert die Anfrage zurück, die der Server empfangen hat
• OPTIONS: Liste der unterstützten Methoden
• CONNECT: von Proxyservern unterstützt

Üblicherweise benutzen RESTful Webservices die Verben GET (Abruf), PUT (Ändern), POST (erstellen) und DELETE (löschen). Dem Benutzer des Webservice muss also nur mitgeteilt werden, welche Ressourcen zur Verfügung stehen. Abrufen und manipulieren kann er sie dann, indem er sie mit den entsprechenden HTTP-Methoden aufruft.

Folgendes Beispiel mit der Ressource „ChatMessage“ soll das verdeutlichen.

http://example.com:8080/MessageService/ChatMessage
//     POST: erzeugt eine neue Nachricht und liefert ihre URI zurück
//     PUT: kein Effekt
//     DELETE: kein Effekt
//     GET: liefert eine Liste mit Nachrichten

http://example.com:8080/MessageService/ChatMessage/7862
//     POST: kein Effekt
//     PUT: verändert die Nachricht mit der ID 7862
//     DELETE: löscht die Nachricht mit der ID 7862
//     GET: liefert die Nachricht mit der ID 7862

RESTful Webservices erzwingen eine ressourcenorientierte Servicearchitektur. Der Service ist vollkommen entkoppelt von jeglicher Anwendung, er ist leicht adressierbar, vollkommen zustandslos und bietet eine einheitliche, vorhersehbare Schnittstelle für Ressourcen. Im Gegensatz zu „dicken“ RPC-Webservices enthalten die versendeten und empfangenen Nachrichten das absolut notwendige Minimum – Metainformationen wie angesprochene Schnittstelle entfallen komplett. Das macht RESTful Services sowohl flexibler, als auch universeller einsetzbar. Der Client muss lediglich HTTP beherrschen, SOAP-Kommunikationsverträge und dergleichen können entfallen.

Gleichzeitig sind sie spezialisiert auf die Web-Infrastruktur, da sie wesentlich mehr Eigenschaften von HTTP nutzen als RPC. Antworten an den Client können bei „reinen“ RESTful Webservices lediglich aus HTTP-Statuscodes bestehen: 404 dürfte jedem bekannt sein, es existieren allerdings noch etliche andere, die dem Client bei einem Minimum an übertragenen Daten Auskunft über den Erfolg (oder den Grund eines Misserfolgs) einer Aktion geben können.

Wir fassen zusammen:

• schlank
• (dadurch) schnell
• erzwingen Entkopplung
• fördern leicht verständliche Interfaces
• universell abrufbar

Weiter geht’s im nächsten Teil, in dem wir uns heraussuchen, was unser Service machen soll, und die Datenverträge schreiben.