Verfasst von: bletra | 9. Juni 2010

WCF: Schnellstart (Teil 2 von 3)

Im ersten Teil dieser dreiteiligen Serie habe ich dargestellt, wie man mit VS2010 und Windows Communication Foundation (WCF) einen einfachen Webservice auf Basis von SOAP erstellen kann. SOAP ist mächtig, weit verbreitet und basiert auf XML. Selbst kleinste Informationen, die beispielsweise in einer Web-Ajax-Applikation von einem Webdienst erfragt werden, müssen diesem Standard folgend in einen umfassenden XML-Umschlag eingebettet werden. Einen anderen Ansatz verfolgt REST (Representational State Transfer). Hier wird jede Ressource mit einer eigenen URI und den möglichen Methoden GET, PUT, POST, DELETE auf Basis von HTTP angesprochen. Üblicherweise wird eine Methodenaufruf eines Webdienstes als Teil der URI kodiert. Möchte eine Applikation beispielsweise auf die Methode GetData() eines Services mit der Adresse http://services.company.de/Offers zugreifen, so erfolgt dies durch ein HTTP-Get von http://services.company.de/Offers/GetData. Parameter können bei GET nur in der URI übergeben werden. Bei den anderen HTTP-Methoden ist dies üblich, aber nicht zwingend notwendig. Der Dienst kann die Antwort in einem beliebigen Format zurückgeben, JSON, XML oder einfach als Text. Wie können wir den Service des letzten Artikels auf REST umstellen?

Einfacher Dienst mit REST

Zunächst ist ein passender Endpunkt zu definieren. Ein Endpunkt definiert die Schnittstelle nach außen. Basis für die SOAP-Unterstützung war das Binding wsHttpBinding. Einen REST-Endpunkt definiert man durch das Binding webHttpBinding. Damit ist auf den ersten Blick alles getan. Auf dem zweiten Blick wird klar, dass noch das passende Endpointbehaviour mit webHttp einzufügen ist (siehe Code der App.config). Desweiteren ergeben sich Änderungen aufgrund von REST und der eindeutigen Adressierung von Ressourcen.

Adressierung

Welche Methode soll aufgerufen werden, wenn ein GET auf die im Endpunkt definierte Adresse erfolgt? Bei REST sind Methoden und Paramter nicht in einem XML-Umschlag eingebettet, sondern in der URI kodiert. Im Interface müssen wir also irgendwie festlegen, welche Methode für welche Adresse zuständig ist. Dies erfolgt mit den .Net Attributen WebGet und WebInvoke und dem Parameter UriTemplate. Diese Parameter stehen erst nach Einbinden der Assembly System.ServiceModel.Web.dll zur Verfügung. Ich arbeite momentan noch mit dem Releasekandidat von VS2010 und hier war die Standardeinstellung für mein neues WCF-Projekt das Framework .Net Framework 4 Client Profile. Damit konnte ich die genannte Assembly nicht referenzieren. Sie können unter Projekt-Eigenschaften, Application, Target Framework das Framework .Net Framework 4 auswählen und nun die Referenz hinzufügen.

Parameter einer URI werden immer als String übergeben, daher müssen wir leider auch unser Interface modifizieren. Ich habe verschiedene andere Blog-Artikel gefunden, die auch mit Int-Parametern arbeiten. Bei mir erzeugte dies jedoch einen Compilerfehler. Ob dies an der installierten VS-Version liegt, kann ich nicht endgültig sagen. Der Frage werde ich jedoch nachgehen, für sachdienliche Hinweise bin ich dankbar 😉

Zusammenfassend ergeben sich folgende Ergänzungen zum Code:

App.config

Enpunkt und zugehöriges Behaviour in App.config einfügen:

<services>
...
  <endpoint address="rest" binding="webHttpBinding" contract="WCFLecture.ITestServiceSimple" behaviorConfiguration="restBehavior"/>
...
</services>
<behaviors>
...
  <endpointBehaviors>
    <behavior name="restBehavior"><webHttp/></behavior>
  </endpointBehaviors>
...
</behaviors>

Interface

[ServiceContract]
 public interface ITestServiceSimple
 {
   [OperationContract]
   [WebGet(UriTemplate = "/get/{value}")]
   string GetData(string value);//nur string parameter, in project properties, standard ist .net client, dann nicht system.servicemodel.web hinzufügbar

   [OperationContract]
   [WebInvoke(ResponseFormat = WebMessageFormat.Json, Method = "POST", UriTemplate = "/post/{name}")]
   Person PostPerson(string name);
 }

Der POST-Aufruf auf die URI <baseaddress>/rest/post/john liefert eine JSON Darstellung einer Person zurück.

Klasse

Zugehörige Implementation des Interfaces — kann in der ursprünglichen Klasse des Beispiels im letzten Artikel erfolgen:

public string GetData(string value)
{
  return string.Format("input was {0}", value);
}

public Person PostPerson(string name)
{
  return new Person(1, name);
}

Auf dieser Ebene unterstützt VS2010 nach meiner Einschätzung SOAP besser als REST. Im nächsten Artikel werde ich die Datenbankanbindung eines REST-basierten Webdiestes mit VS2010 betrachten. Das Fazit sei hier vorweggenommen, solche Dienste lassen sich gut und einfach erstellen.

Teil 1 von 3: Einfacher Dienst mit SOAP

Teil 3 von 3: Datenbankanbindung mit REST

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Kategorien

%d Bloggern gefällt das: