Consuming REST Services with WCF

Posted by Hartmut Wilms on Apr 30, 2008

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

.NET ,

REST ,

SOA ,

.NET Framework

Tags

WCF

The .NET Framework 3.5 introduces REST-style WCF services. In addition to developing and hosting RESTful services there are several options for consuming these services.

WCF offers support for REST via "web" bindings and the Web Programming Model that allow for publishing RESTful services, which return plain XML, JSON encoding, or syndication feeds. There are many resources on the web that explain how to write such services, but very few on how to consume REST services with the .NET Framework.

In his article on "Consuming Services Using Silverlight 2.0" Simon Evan points out that there is no support for auto proxy generation as is the case for SOAP Web services:

Other services (such as REST) are a little harder to consume, and the one thing that did surprise me was that there is no support for the auto proxy generation used by ASP.net AJAX against the WebHttpBinding. You have to construct a Uri string manually and call the service either by using the WebClient class in the case of HTTP GET resuests (REST), or by using the HttpWebRequest class for other HTTP verbs. If the service uses JSON encoding, parsing the response can be achieved in one of two ways: either through WCF's DataContractJSONSerializer (similar in concept to the XmlSerializer), or by using LinqToJSON ...

Json.NET (LinqToJSON) is available on Codeplex. XML data can as easily be parsed and consumed with LINQ to XML, which is part of .NET Framework 3.5.

Pedram Rezaei explains how to develop a consumer for the "ListInteresting operation from Flickr". At first he takes a three step approach as outlined by Simon Evan:

• Do the HTTP request and include all the parameters as part of the URI
• Get the response that is in XML format
• Either parse it or deserialize it into an object

Although this is a viable approach, Pedram criticizes that

We are not using the unified programming model offered by WCF and the URL is hacked together using string concatenation. The response is also manually deserialized into an object. With WCF and the WebHttpBinding we can automate most of this.

He then takes a "WCF approach", which consists of the following steps:

• Define a ServiceContract that represents the service provider.
  The UriTemplate contains all necessary parameters that are mirrored in the corresponding interface method's parameters. The signature of the method also defines a CLR return type, which takes the deserialized XML content from the service response. The method has to be annotated with the WebGet or WebInvoke attribute and the ServiceContract must be configured to use the XmlSerializerFormat instead of the DataContractSerializer in order to match the service's returned XML as close as possible.
• Configure the client endpoint to use the "webHttpBinding".
• Define XML serializable types for the return value (and the parameters).
• Create a client proxy by either instantiating the ChannelFactory directly or by deriving from ClientBase<>.

Have a look at the details in Pedram's article. Mihailo Lalevic uses the same approach for developing a consumer for the eBay API and provides a WPF sample application (source code) as an attachment to his article.

• Older >