Question

I’ve recently discovered a way to implement RESTful services using Global.asax (by handling the Application_BeginRequest event). Basically, I am saying it is possible (and easy) to implement a RESTful web service in classic ASP.NET, without any need for WCF.

It takes approximately 30 lines of code to figure out which method you want to call (from the URL) and pass it parameters (from the query string, via reflection) as well as serialize the result using XmlSerializer. It all leads to a web service that can be accessed through HTTP GET requests, and returns standard XML data.

So with that in mind, is there any reason to use WCF when creating a RESTful web service that will be invoked only through HTTP GET requests? WCF introduces a lot of overhead and restrictions, whereas the Global.asax approach I described above is much easier to implement, customize, and deploy.

Note – JSON endpoints can also be implemented without WCF by using the JavaScriptSerializer.

Also – HTTP POST requests can be handled by Global.asax in a similar way.

So in the end, what would be the reason to use WCF in such a case? Is there better scalability or performance?

Answer 1

You can also use Asp.Net MVC to implement REST quite easy.

What you don’t get for free with this approach is:

• non-HTTP bindings.
• support for multiple message formats.
• non-IIS hosting.
• control over the process activation.
• control over the instance creation.
• object pooling.
• message queueing.
• transactions.
• scalability and reliability.
• additional technologies built on top of WCF like the OData support.

If none of these applies to your scenario – you don’t need WCF.