alexanderzeitler.com - Microsoft Web API – den REST macht WCF (Teil 1)

Microsoft Web API – den REST macht WCF (Teil 1) | Alexander Zeitler

Alexanderzeitler.com Spined HTML

Microsoft Web API – den REST macht WCF (Teil 1) | Alexander Zeitler Toggle navigation Home Feed Microsoft Web API – den REST macht WCF (Teil 1) Written on April 15, 2011 SOA -- So Oder Anders? (c) geek&poke Wenn heute über SOA gesprochen wird, denken viele Entwickler nach wie vor an Web Services (im Falle von .NET sind dies entweder ASP.NET Web Services oder die Windows Communication Foundation, kurz WCF), welche SOAP mittels XML und anderen Standards realisiert und so Remote Procedure Calls (sprich Aufrufe von Funktionen auf fremden Rechnern) ermöglichen. Da sich die fremden Systeme, auf denen die Dienste bereitgestellten werden, nicht selten in fremden Netzen oder gar im Internet befinden, bestand natürlich schnell der Bedarf für Authentifizierung und Authorisierung, welche z.B. mit der SOAP-Erweiterung WS-Security ermöglicht wurde. Natürlich wollte man sich auch auf die zuverlässige Zustellung der SOAP-Nachrichten verlassen können und schuf eine weitere Erweiterung namens WS-Reliability. Damit man die SOAP-Messages beschreiben konnte wurde WSDL ins Leben gerufen. Wie man sieht, ein ziemlicher Aufwand, um Daten zwischen zwei Endpunkten im Netz austauschen zu können. Die Aufzählung der Erweiterungen und Formate ist dabei bei weitem nicht vollständig, ganz zu schweigen von den Problemen, die in der Praxis zu lösen sind. Und jetzt: der REST Trotz der o.g. Erweiterungen hat man mit SOAP nicht wirklich das Gefühl, elegant und effezient zu arbeiten und SOA, so behaupte ich, hat sich nicht in dem Maße durchgesetzt, wie es die Buzzword-Bingo-Szene aller Orten Glauben machen möchte. Auf der anderen Seite gibt es seit Jahren das Internet, das sich rasent schnell verbreitet hat und praktisch in allen Bereiche unseres Lebens eindringt. Nun wäre das Internet sicher nicht so erfolgreich gewesen, wenn es langsam, unzuverlässig und schwer zu bedienen gewesen wäre. Das Internet, wie es die meißten Anwender im Browser Ihrer Wahl verwenden, basiert auf dem HTTP-Protokoll, das die Funktionen des Webs über die in der Spezifikation festgelegten HTTP-Operationen realisiert. Wer sich mit Web-Entwicklung befasst, ist sicher bereits mit HTTP-Verben (oft auch Methoden genannt) wie GET oder POST konfrontiert gewesen. Neben diesen beiden Verben gibt es noch andere, allerdings eher unbekannte Verben in der HTTP-Spezifikation wie z.B. PUT oder DELETE. Außerdem arbeitet HTTP mit sogenannten Status-Codes, die den Browser (z.B. mit dem Wert 200 für OK) und manchmal auch den Anwender (z.B. 404 Seite nicht gefunden) direkt über den Status des aktuellen Requests informieren. Basierend auf diesen und einigen weiteren Elementen der HTTP-Spezifikation verfasste Roy Fielding bereits im Jahr 2000 seine Dissertation, in welcher er eine neue Architektur für verteilte Anwendungen unter Verwendung von Webtechnologien beschrieb: Representational State Transfer, kurz REST. Dabei sei hier bereits klargestellt, dass REST-basierte Architekturen nicht zwingend im Web verwendet werden müssen, sondern nur die hierfür entwickelten Technologien und Prinzipien anwenden. There's a URI for That Im Mittelpunkt einer REST-basierten Architektur stehen Ressourcen, welche jeweils über eine eindeutige URI angesprochen werden können, wie z.B.: http://mybookstore.com/book/RESTInPractice Damit ist das Buch "Rest in Practice" für jeglichen Client (ggf. nach Authentifizierung) verfügbar, sofern er diese URI kennt. Eine Auflistung aller Bücher würde sich bei einer REST-Architektur z.B. hier finden: http://mybookstore.com/books/ Dabei ist derzeit weder klar, welches Format sich hinter den beiden URIs verbirgt, noch welche HTTP-Methode verwendet wird, um die URI aufzurufen. Auch hierzu gibt es klare Vorstellungen bei einer REST-Architektur: Eine URI, unter der Daten gelesen werden können, sollte immer per GET aufgerufen werden. Dies bedingt allerdings auch, dass der Aufruf die zugrunde liegenden Daten niemals verändert, sodass das die Operation beliebig oft aufgerufen werden kann und immer die gleichen Daten liefert (sofern diese nicht durch andere, hierfür vorgesehene Methoden, geändert wurden). Das zurückgegebene Format der aufgerufenen Methode kann der Client selbst bestimmen (sofern die Ressource mehrere Formate bereitstellt). Dies geschieht allerdings nicht, wie vielleicht zunächst vermutet über http://mybookstore.com/book/RESTInPractice/PDF. Vielmehr werden die HTTP-Header des Requests entsprechend konfiguriert. Um nun das o.g. Buch im PDF-Format unter der bereits genannten URI anzufordern, wird der Accept-Type im HTTP Header auf "application/pdf" gesetzt. Die URI für das Buch bleibt somit gleich: http://mybookstore.com/book/RESTInPractice Den Header wertet der Server entsprechend aus und die Ressource liefert, sofern das Buch als PDF zur Verfügung steht, dieses im Response als PDF aus. Steht das Buch nicht als PDF zur Verfügung, kann dies ebenfalls mit HTTP-Boardmitteln im Reponse angezeigt werden: Über den Status-Code im HTTP-Header (z.B. 404, wenn das Buch nicht gefunden wurden) des Response lassen sich praktisch alle Zustände einer Resource, des Requests oder gar des gesamten Servers, auf dem die Ressource gehostet wird, darstellen. Weitere Details und konkrete Implementierunen für .NET und JAVA-basierte REST-Services und Clients finden sich in dem Buch "REST in Practice", das ich jedem, der sich mit dem Thema befassen will oder muss (darf?), empfehlen kann. Microsoft und REST Natürlich gibt es auch von Microsoft einen Lösungsansatz für REST Architekturen. Bereits seit einigen Jahren existiert das WCF Starter Kit, welches allerdings nicht wirklich in die Ruhmeshallen von Microsoft gehört. Da REST-Architekturen heutzutage immer wichtiger werden und natürlich auch .NET-Entwickler solche entwickeln wollen oder müssen, hat sich Microsoft nun mit der WCF Web API des Themas nochmals angenommen und wie ich finde, nun eine wirklich gelungene Implementierung auf Basis der WCF auf den Weg gebracht. Der derzeitige Stand ist unter http://wcf.codeplex.com abrufbar. Glenn Block, der Verantwortliche hinter dem Projekt, wird auf der Mix 2011 in der Session "WCF Web APIs: "There's a URI for That" den aktuellen Entwicklungsstand mit Beispielen sowie weiteren Details zur Roadmap etc. präsentieren. Da ich mich bereits seit einiger Zeit mit der Web API beschäftige, werde ich hier in den nächsten Tagen mehrere Postings zum Umgang mit der Web API bereitstellen. Dabei kommen in den Beispielen neben der Web API auch das BDD-Framework machine.specifications/machine.fakes sowie der IoC-Container LightCore zum Einsatz. Es wird z.B. die Anpassung und testgetriebene Entwicklung der MIX-Beispiele gezeigt. Außerdem werden auch HTTP-Methoden wie PUT und DELETE behandelt und weitere Vorteile REST-basierter Architekturen vorgestellt. .aspx&bgcolor=3169AD&fgcolor=FFFFFF&border=000000&cbgcolor=D4E1ED&cfgcolor=000000) Please enable JavaScript to view the comments powered by Disqus. Copyright © Alexander Zeitler 2003 - 2016 | Impressum