Continuing from the previous post, let’s look into what frameworks that are available to implement Web services (REST or SOAP). We will be talking about frameworks available in the Microsoft technology stack only.
Lets take a look at all the options available:
The initial WCF SOAP stack also referred to as WCF classic now, was a unification of all the distributed application technologies including ASMX, Remoting, COM+, MSMQ in a single framework. It was done using SOAP as the messaging protocol.
WCF Data Services
Formerly known as ADO.NET Data Services, WCF data services enables the creation and consumption of OData services for the web.
WCF RIA Services:
A convenient way build the backend for Silverlight applications.
WCF Web HTTP
At some point the WCF team decided that you should be able to build RESTful/HTTP services using the WCF stack (or brand). This was the attempt to built HTTP/RESTful Services to deal with vanilla HTTP request and response.
Although ASP.NET MVC is a framework to create web applications, you can return all content types that HTTP supports from an action in your controller. You can build a custom action filter or Result formatter to do content negotiation for you.
As soon as developers identified that you can build RESTful using the ASP.NET MVC framework without messing with WCF Web Http, Microsoft came up with a framework similar to MVC but very specifically for building RESTful services –
ASP.NET Web API
ASP.NET WEB API is the new framework by Microsoft to build HTTP services. Internally it uses the goodies of the ASP.NET MVC framework and caters to all the requirements around building RESTful services. The framework also provides great WCF features like self hosting with programmable configuration.
ASP.NET WEB API OData Services
It is a set of components built on top of ASP.NET WEB API that lets you build OData services. It plays nicely with the WEB API model giving you the flexibility to select a subset of the OData query syntax and/or formats.
This framework allows you to build real time services for the web. It allows you to create a duplex connection between the client and the server. SignalR initially started as an open source effort before it was fully embraced into the ASP.NET stack. The framework uses Web Sockets when available and has fallback options. It supports a variety of clients.
What to use?
Lets start with what not to use. It is recommended not to use any of the following in your application:
- .NET Remoting – Encourages tight coupling, does not scale well and does not interoperate.
- ASMX – Limited features around security and session management, for a SOAP based XML web service use WCF.
If you are using one of the above in a new application that you are developing, you really need to catch up with the world. If you have it in an existing application, it might be worthwhile calculating your maintenance for the life of the application with and without the upgrade.
My take on what to use to build services
Consider the following question:
- Is the communication on the same windows machine (locally running service)?
- Is the service going to be consumed within the intranet, in Windows environment?
- Are you dealing with Message Queues?
- Do you need Message based security (and why)?
If you answer to any of the question above is ‘Yes’ you should use WCF classic framework.
For anything else, if your service is going to be consumed over the web, use ASP.NET Web API. Even if you feel your MVC application can handle your minimum requirements, consider looking at Web APIs. It has built in content negotiation, OData support and provides a lot of power for dealing with data result sets.
If you need duplex communication channel where the server should be able to communicate back to the client, use ASP.NET SignalR. It is the ideal candidate for real-time application like Stock ticker or chat applications.
So, to conclude, if you need SOAP services – use WCF classic, if you need to build HTTP service – use ASP.NET Web API.