WebApi looked as one of the strongest contenders at first, just by its lineage (MSFT is his champion). But when I saw its pre-beta status I had second thoughts. And third thoughts remembering all the horror stories I have had with its father: Windows Communication Foundation. Since I spent less time than I wanted evaluating OpenRasta I gave WebApi a spin. And here are my thoughts.

Get It!

Getting WebApi up and running is simple enough: install the WebApi package and you are good to go. There are a number of other packages that add some interesting features, but I only went for the simple, barebones, server side of things.

Documentation

The walkthrough is pretty comprehensive but the site does not have a whole lot of “official” documentation. But the package comes with a pair of .chm files that are really handy.

And one cannot complain about the number of people writing about the product in their blogs. The information might be outdated, but it should give an idea of the activity of the community around the product, which is pretty nice, in my opinion.

The Services

Creating services (or APIs, as they are called in WebApi jargon) is a two step thing out-of-the-box.

1. Create a class decorated with the ServiceContract attribute that contains one or more related methods (and related means URL-related) and implement your logic:
2. And register the route corresponding to the resource you are serving when the application starts:

Some content negotiation is included out of the box by adding an Accept request header, being the default XML and JSON is also included. A nice touch is that it supports qualified values (see the spec), meaning that will return the supported type with the higher relative quality factor or default to XML. Another nice touch is the fact that the response includes the codification charset of the data, which helps with those “weird” characters that we all love (ñ, æ, å,…)

One of the things that impressed me the most was how the whole URL placeholder and extra request information is handled. If one wants to have another API hanging from an already defined base route (in this case, /catalogs) another method in the api class is created and decorated with the WebGet attribute, setting the UriTemplate property to a string that will contain the placeholder information for that route, including any query string information that we may want to get and that information will be set in the parameters defined for the method. Pretty nifty.

And the icing of the cake for those who need it? Easy OData support. Apparently it does not get on well with REST according to some, but it is a pretty popular format of delivering information.

Opinion

I was pleasantly surprised by how smooth WebApi looks like. That only mean they did a good job to come up with a nice to work with API on top of the configuration hell that WCF is. And that is a compliment, by the way.
It does what it does in a nice manner but I do not have an opinion about extensibility points and customizations as I did not push it. But I know from my light reading about the subject that it supports the concept of resource factory, allowing to use your IOC container of choice to inject the dependencies your service might have in an easy manner.

Probably one the nicest things one can say is that it gets the job done without getting in one’s way, with a simple api, meaningful defaults and adherence to the spec. Do not know about relative performance, compared to some of the other contenders, though.

I have very few bad things (if any) to say. The only but is the two step creation of services (service plus the route), but I am confident there might be an extension to have it in one single step.

Would I use WebApi? I cannot see why not.
Was it the one I chose? No, it was not. Only because I tried it by chance and expected worse (due to its WCF heritage) it did not get higher in my list of preferences.
Would I recommend its use? Yeah, give it a go. It may suit your needs.