Creating a RESTful Web Service Using ASP.Net MVC Part 22 – Reviewing the Rest features in MvcFutures 2

May 1, 2010 22:54 by admin

When ASP.Net MVC 2 came out, it included support for overloading POST requests, something I had previously incorporated into our RESTful framework. The release also came with the latest incarnation of Microsoft’s experimentation with providing a RESTful framework for ASP.Net MVC (this is part of the ASP.NET MVC 2 Futures download). I looked at their first offering in an earlier post when it was known as the “Rest for ASP.Net MVC SDK”. It had some interesting ideas, but wasn’t comprehensive enough for me. So with this new release, I was keen to see if I could retire our framework (or at least parts of it) and use some of the new features. So here I’ll look at each feature I’d like to see in a RESTful web service and see how well it is supported, as well as look at some new ideas altogether.

Multiple Formats

In the previous Rest for ASP.Net MVC SDK, the rendering to XML and JSON was ultimately handled by the DataContractSerializer and DataContractJsonSerializer serialisers. I thought this was quite inflexible as shaping the final output was not possible without altering the object passed in. Our frameworks’s approach has been to apply an XSLT (with extensions) or use the JavaScriptSerializer (with JavaScriptConverters). Whilst flexible, this is not so quick and simple to implement, you need to provide XSLT or write JavaScriptConverters.

I was thinking about adding Format Handlers based on a simple templating model such as the Spark View Engine… however, I was beaten to it. A new feature in MVC Futures is that the serialisation is performed using a standard View Engine, such as the Webforms View Engine (or you could just as easily inject the Spark View Engine). How does it do this? Given a View Name of Fred, the code appends the Format Handler’s friendly name, giving a View Name of say Fred.Xml or Fred.Json. This new name is passed to the View Engine, to be processed as per usual. So now you can use the power of templating available in an ASPX or SPARK page to create exactly the XML you want, without resorting to clever tricks to inject functionality into the standard serialisers.

I think this is a great idea. I thought they might have baked it in deeper, such that any controls injected through Html.RenderPartial also had the FriendlyName automatically appended, but it is not much effort to add “.Xml” yourself to the view name passed to RenderPartial.

Overloaded POST

Overloading POST is now baked into ASP.Net MVC 2. This is a great stride forward… so long as it works OK. I have two issues with the way it has been implemented:

Firstly, if your client won’t or can’t use the "X-HTTP-Method-Override" header, you can use a FORM variable or Query String parameter to dictate which method you want to be used. However, you must name your parameter "X-HTTP-Method-Override". There are conventions out there that use different variables (e.g. “_method” used by Ruby on Rails). Without being able to configure or programatically change the variable name, ASP.Net MVC could not be used to replace such existing web services.

Secondly, for some reason, which I would love to know, the code that performs the override finishes with these statements:

if (verbOverride != null) {
    if (!String.Equals(verbOverride, "GET", StringComparison.OrdinalIgnoreCase) &&
        !String.Equals(verbOverride, "POST", StringComparison.OrdinalIgnoreCase)) {
        incomingVerb = verbOverride;
    }
}
return incomingVerb;

This means that if the value of the override is GET or POST, then it is ignored. Why do this? It seems superfluous in the case of POST and restrictive in the case of GET. Unfortunately, I know of at least one client that in certain circumstance only allows the POST verb to be used, so if you want to perform a GET, you need to use an Overloaded POST… that client is pretty popular! It is Flash. If you are using basic authentication (common for RESTful web services) Flash will always use the POST verb! So these, few lines of code, would prevent a secure web service from working with Flash, and possibly other, not so smart, clients. Perhaps, the team were taking a leaf out of Steve Job’s book? ;-)

Therefore, for now we will have to stick with our deeper implementation of POST overloading.

Accept Header

As with Overloading POST, I believe it is important that clients can use multiple techniques to indicate the format of the data they want to receive. One approach is to use the “Accept” header, supplying a list of acceptable formats with an indication of the client’s order of preference. Alternatively, clients should be able to use a Query String variable. The MVC Futures code supports both methods which is good. However, there is still the slight limitation that the name of the Query String variable (hardcoded to “format”) cannot be configured or changed programatically. The MVC Futures code does allow route data to be interrogated for a format, so this may provide a workaround.

Accept-Charset Header

The next thing I wanted to check was that the web service would obey they “Accept-Charset” request header. This allows a client to dictate the encoding to be used in the response (e.g. UTF-8, UTF-16 etc.). Currently the code in MVC Futures does not use this header at all. It doesn’t appear to fall back to using the encoding of the original request either. A comment in the code indicates they are thinking of implementing this... I hope they do. Our framework does support it.

Content-Type Header

The MVC Futures code does not populate the “Content-Type” Response header correctly out of the box. As a comment in the code indicates, the Webforms View Engine will override whatever is put in there. There is a suggested work around of deriving Views from a new ViewPage class that would set the header correctly. Hopefully the next version would sort this properly. Our framework does support it.

Allow Header

The MVC Futures code provides no support for the “Allow” header. It would be nice to have this built in somehow. Our framework does support it.

Connectedness

By using the standard View Engine functionality to generate the JSON or XML output means we have full access to the Html.ActionLink functions. Therefore, adding connectedness is very simple.

Conclusion

I think the support for RESTful web services being prototyped in MVC Futures is a promising start. Allowing the XML or JSON representation to be generated using existing View Engines (like the webform View Engine that processes ASPX pages) is a great idea. It’s mainly the fine detail that is still missing, being a good HTTP citizen for those clients that are still simple or written using a particular framework. I look forward to seeing this become more integrated in MVC 3!

kick it on DotNetKicks.com


Comments (3) -

May 6. 2010 16:51

Matt

Great stuff. What kind of licence is this released under?

Matt

May 6. 2010 17:55

Matt

Nevermind I can read inside the code - thanks!

Matt

June 13. 2011 07:42

Name badge

very useful informations but it will be too good. I Think that they are useful for people with sharing opinions. I bookmarked.

Name badge

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading