Put your controllers on a diet

Have a read of this fantastic post by Yngve Bakken Nilsen on cleaning up your controllers.

Nilsen accurately points out that in the real world, controllers, even with the best of engineering intentions, can get bloated. Nilsen focuses on the scenario of your controllers containing Actions for Views and Ajax requests that will return Json data, which is a common cause of controller bloat.

The post demonstrates that you can use SignalR to isolate any Ajax calls away from your controllers. I like his approach, but its also worth noting that you can use the Asp.Net Web API to achieve similar functionality. Using the Asp.Net Web API will allow you to easily separate your controllers that return data from your controllers that return views, but it does leave the client side requesting and manipulation of the data up to you.

Great post all the same, have a read.


JSON, Technical, WCF

ASP.Net Web API vs RESTful WCF services

With the upcoming release of asp.net 4.5, which includes the fantastic looking ASP.Net Web API, many of us will be thinking that this almost stands on the toes of WCF slightly.

Well not quite.

The two really can serve very different purposes.

  • WCF is designed so that all of your connectivity and endpoints are abstracted away from the core operations of the service (Although you may need to apply certain attributes to your operation contract)
  • All of the connectivity and endpoint data is largely configured through the Web.Config file (and you really should be read up on what your settings do before trying to tweak them)
  • WCF therefore allows you to switch out endpoints and connections through the Web.Config file without the need for recompiling (for example, if you wanted to disable SOAP on a SOAP and JSON web service)

That’s a lot of power.

So the question is, what if my intention is to only ever create a RESTful webservice and I never need to support other message types (such as SOAP)? Should I be using WCF?

Well, the short answer is that you can, but you’d be using a sledgehammer to crack a nutshell. Another major factor will be the issue that WCF doesn’t really let you go all the way with REST very easily:

  • All WCF requests for webHttpBindings are steered towards only using GET [WebGet] and POST [WebInvoke]
  • Enabling other HTTP verbs can involve configuration of IIS to accept request of that particular verb on .svc files
  • Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified

I’m a big fan of the KISS principle.  So if you are going to setup a Web Service and don’t need SOAP, you should take a good look at the ASP.Net Web API.

But what do the experts say?

Well, Christian Weyer, who basically had a hand in WCF’s inception, states in this blog post that the web is going in a new direction, focused around lightweight web based architectures. He is leaning toward using the ASP.Net Web API for these sorts of architectures.

Further Reading

apigee have made a fantastic ebook on Web APIs available to download for free. It’s a great read, and got me thinking about web services in more detail.



WCF and JSON Date format

If you have a WCF web service that allows the client to pass requests that contain JSON objects, you will at some point probably need to pass a date.  If your client is also written in C#, then you don’t need to worry about this date format – the JavaScriptSerializer class will sort the date format out for you.

However, if your client is written in some other non .net language, then you may need to know what exactly the date is.

WCF dates are specified as the number of milliseconds since the 1st of January 1970. This is also sometimes referred to as an Epoch Time Value. The guys over at Esqsoft have a handy web based Epoch date time converter. Great for finding JSON date values to put into a request into Fiddler for testing.

So lets take today’s date – 11th October 2011, and convert it to an Epoch Time Value:


is our output value.


Lets see this in the context of a JSON request:


As you can see, we need to wrap the Date in an escape sequence, and then a Date object. We also append the date with our time zone. In my case, I am appending a +0100 as I am one hour ahead of Greenwich Mean Time, currently on British Summer Time (although you wouldn’t know it looking at the weather!)


Bertrand Le Roy’s blog post on WCF JSON dates


ESQ Soft Epoch / Date Converter

JavaScriptSerializer Class