Windows Phone 7 Notification Services – Prerequisites–Part 2

Converting SOAP to REST

Don’t let the image fool you. It doesn’t mean that SOAP is Superman and that REST is asleep under a tree.

So, this post is about converting to a RESTful approach, for reasons previously discussed. We will convert the same project that is SOAP-based.

A Comparison from the previous blog post WCF Service Type Why it is used SOAP Developed my Microsoft in 1998. Platform neutral approach to middleware. Considered the standard for web services. No built in caching because built upon HTTP Post. SOAP can work with protocols other than HTTP. Leverages a number of additional protocols from the industry WS-* standards. Better at federated security, which is when one company can be trusted and considered authenticated by another company without the second company having to maintain the authentication information (username and password, typically). SOAP supports WS-Atomic Transactions, which support distributed, two-phase commits. Many comment that SOAP is limited by the fact that the API on the client must match the API on the server. REST Often considered to be simpler and faster. Good for simple create-read-update-delete types of interactions. REST provides caching built-in from HTTP Get requests. REST has no support for distributed transactions. Generally considered more interoperable, because SOAP and the WS-* specification has a large number of different standards. Also, most all platforms support http as a protocol, even mobile devices, household devices, POS devices, DVD players, and TVs. There is no direct support for generating a client from server-side-generated metadata, as there is in the world of SOAP. Many discount the value of this metadata because you still have to learn the underlying API of the service.

Steps to take and why

Step Why step is needed Step 1 - Add service reference to System.ServiceModel.Web REST requires specific bindings and contract attributes that are implemented in System.ServiceModel.Web assembly Step 2 - Add an attribute (WebGet) to our SayHello() method Indicates that a service operation is logically a retrieval operation and that it can be called by the REST programming model Step 3 - Add the Factory=System. ServiceModel.Activation. WebServiceHostFactory to the Service.svc file Allows us To simplify the WCF service by using the WebServiceHostFactory class to create our service. This class eliminates the need to use configuration for the service Step 4 - Open web.config and delete the entire System.ServiceModel section REST doesn't require this section. Step 5 - Test with our web based service https://localhost/WCFService/Service.svc/SayHello?name=bruno

Step 1 – Add service reference

Right click on https://localhost/WCFService Important Note   You may already have that reference set.

Step 2 – Add WebGet attribute

Description: The IService Interface decorated with [WebGet]   [ServiceContract]public interface IService{ [OperationContract] [WebGet] string SayHello(string name);} Figure: Code inside of IService.cs

Step 3 – Add WebHostFactory to Service.svc

View Markup Add the highlighted code in Service.svc Description: Adding REST support for our web service <%@ ServiceHost Language="C#" Debug="true" Service="Service" CodeBehind="~/App_Code/Service.cs" Factory="System.ServiceModel.Activation.WebServiceHostFactory" %> Figure: Markup for Services.svc

Step 4 – Eliminate <service.ServiceModel> from Web.config

Description: The updated Web.config file  <?xml version="1.0" encoding="utf-8"?><configuration> <system.web> <compilation debug="false" targetFramework="4.0" /> </system.web> <system.webServer> <modules runAllManagedModulesForAllRequests="true"/> </system.webServer></configuration> Figure: Web.config

Step 5 – Go into Internet Explorer and Test

Comments

• Anonymous
  December 15, 2010
  You don't convert SOAP to REST like this. They are two different architectural styles and result in two completely different APIs. You converted SOAP to POX, which is just doing the same thing as SOAP without the envelope.

• Anonymous
  December 15, 2010
  Hi Jesse, Thank you for reading my post. If you read my previous post, you will note that I make it abundantly clear that comparing SOAP vesus REST is like "apples versus oranges."  To your point, SOAP is not an architectural style, but a protocol. - also stated in the previous post. Finally, feel free to write a more robust response that I could post inside my post. I'd be happy to incorporate your feedback. I appreicate the feedback. Bruno - bterkaly@microsoft.com