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 http://localhost/WCFService/Service.svc/SayHello?name=bruno
  Step 1 – Add service reference
  Right click on http://localhost/WCFService

Important Note

You may already have that reference set.
  Step 2 – Add WebGet attribute
  Description: The IService Interface decorated with [WebGet] 
public interface IService
    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"?>
    <compilation debug="false" targetFramework="4.0" />
    <modules runAllManagedModulesForAllRequests="true"/>

Figure: Web.config

  Step 5 – Go into Internet Explorer and Test


Comments (2)
  1. Jesse Ezell says:

    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.

  2. BrunoTerkaly says:

    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 –

Comments are closed.

Skip to main content