Migrating the Sounds Familiar application services to the cloud prompted me to make a switch from SOAP to REST. Though it was not necessary to make the switch, REST has become the de-facto standard for public services. The modification to my existing services was not a major change.
To assist me in my service migration effort, I found this article by Rob Bagby which details how to add a RESTful service to an Azure hosted ASP.NET Web Role. I will recount the steps here but do check out Rob’s article for his insight into RESTful development.
This is the configuration-less model. This factory will dynamically set up an instance of the WebServiceHost in response to requests. It will set up a default endpoint, if appropriate, with the binding set to webHttpBinding, our REST-Friendly binding.
Now we are ready to implement our service. Some clients may want to work with XML, others may prefer JSON formatted results. It is really easy to support both formats. Using the WebGet attribute you can specify the Uri template for your RESTful service and what the return format is, XML or JSON. By creating 2 identical methods that only differ by their Uri templates and return format you can support a dual purpose interface.
Note how I extract the implementation to a private method that is invoked by both interface methods. The GetCDList() method contains the same code I used in my previous service implementation. It performs the data access to the SQL Azure store using ADO.NET and it constructs the return type CDList. So all the Data Access code and associated object model were reused. I simply created a new Service Interface layer that implements the RESTful api.
By compiling the project and browsing to the svc file we can test out service end points. You can see expected results using these Uri’s from the Sounds Familiar application: