Rest For ASP.NET MVC SDK and Sample

Aug 17, 2009 aspnetmvc suggest edit

When building a web application, it’s a common desire to want to expose a simple Web API along with the HTML user interface to enable various mash-up scenarios or to simply make accessing structured data easy from the same application.

A common question that comes up is when to use ASP.NET MVC to build out REST-ful services and when to use WCF? I’ve answered the question before, but not as well as Ayende does (when discussing a different topic). This is what I tried to express.

In many cases, the application itself is the only reason for development [of the service]

“[of the service]” added by me. In other words, when the only reason for the service’s existence is to service the one application you’re currently building, it may make more sense would stick with the simple case of using ASP.NET MVC. This is commonly the case when the only client to your JSON service is your web application’s Ajax code.

When your service is intended to serve multiple clients (not just your one application) or hit large scale usage, then moving to a real services layer such as WCF may be more appropriate.

However, there is now a third hybrid choice that blends ASP.NET and WCF. The WCF team saw that many developers building ASP.NET MVC apps are more comfortable with the ASP.NET MVC programming model, but still want to supply more rich RESTful services from their web applications. So the WCF team put together an SDK and samples for building REST services using ASP.NET MVC.

You can download the samples and SDK from ASP.NET MVC 1.0 page on CodePlex.

Do read through the overview document as it describes the changes you’ll need to make to an application to make use of this framework. Also, the zip file includes several sample movie applications which demonstrate various scenarios and compares them to the baseline of not using the REST approach.

At this point in time, this is a sample and SDK hosted on our CodePlex site, but many of the features are in consideration for a future release of ASP.NET MVC (no specifics yet).

This is where you come in. We are keenly interested in hearing feedback on this SDK. Is it important to you, is it not? Does it do what you need? Does it need improvement. Let us know what you think. Thanks!

Found a typo or mistake in the post? suggest edit

Comments

48 responses

Chris Hardy • August 17th, 2009
Looks rather interesting. Will be good to see how it fares next to OpenRasta...
PK • August 17th, 2009
"We are keenly interested in hearing feedback on this SDK"
Kewl .. but do we post our replies/feedback, here? or the ASP.NET MVC forums? or elsewhere?
rictokyo • August 17th, 2009
@PK just comment on it anywhere, doesn't really matter where, as long as its on the web, don't worry, they will find your comment wherever you may post it and be thankful for the input.
Me, I think this is a cool idea in deed, and would like to see this on a next release of ASP.NET MVC.
BTW:
when is a future release coming?
What other cool things are you planning to add to it?
Jack • August 17th, 2009
Not using MVC for nearly half years, glad to hear the SDK and Sample package!
None • August 17th, 2009
Is there a benefit to moving to WCF instead of using regular MVC? I found out that http://JivenWho.com operates as such and they don't seem to have any issues.
The Jay Mann • August 17th, 2009
After reading the included document, this seems like a great tool. However, after noticing that it chooses the display format based on a query string parameter, this reminded me of something I was thinking about just a few hours prior. Why not use the Accept header to determine the output type. This allows not just a single format type to be returned, but rather a list of possible types sorted by preference, and simply throwing a 406 if the list of types aren't supported. For example, a client may prefer to recieve JSON data, but can work with XML or RSS data if necessary, thus can set Accept to application/json,text/xml;q=0.9,application/rss+xml;q=0.2. This would suggest returning JSON by preference, XML otherwise (or if the service really prefered XML), RSS only if absolutely necessary, and an HTTP 406 assuming the service doesn't support JSON, XML, or RSS.
The only issue is when applying this to the general purpose case. FireFox web browser seems to have very sane values for Accept when retrieving from the addressbox supplied URL (text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 first give me HTML or XHTML, if not, maybe XML, or anything else otherwise). Chrome has a fairly decent list (application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 XML as top priority!? HTML lower priority than plain XML!? that'll cause a few issues). IE gives a very weird list (image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */* uhm... yeah.....). The big issue though is the Windows RSS Platform, which only sends a */*, which would make it impossible to detect RSS or Atom rather than regular HTML. I'd assume those issues would present show stoppers to such a method (why use a technology that, while it's done the way it's supposed to be done, doesn't work?) I'd still like to see support for this method, as it does make a bit more sense. Maybe even if such were to catch on, clients will better support it.... maybe...
ranamauro • August 17th, 2009
@The Jay Mann: Accept header is indeed supported in this sample. The docs for HttpHelper.GetResponseFormat state:
Returns the preferred content type to use for the response, based on the request, according to the following rules:
1. If the query string contains a key called "format", its value is returned as the content type
2. Otherwise, if the request has an Accepts header, the list of content types in order of preference is returned
3. Otherwise, if the request has a content type, its value is returned
The first option, the one you noted, is only enabled for browsers as a convenience for quick sanity checking (in fact it might make sense to have an option on WebApiEnabledAttribute to disable it), as most browsers won't let you specify an Accept header (fiddler does, but that's not really a browser). This option is checked first as it needs to override the Accept header that the browser normally sends.
Luke Sampson • August 17th, 2009
I've downloaded and run the samples... just wondering is there a way to define a view for a particular request type, e.g. if it's an Atom request, can you customise the XML output so it has something in the feed/entry/author elements?
So far, I'm not really convinced this would be a valuable feature - I've built REST services consumed by other applications using plain old MVC and it seems easier and gives you plenty of control. Not to say REST couldn't be better supported by the framework, but this approach seems unwieldy.
Asbjørn Ulsberg • August 17th, 2009
I agree with Luke Sampson. Perhaps a better approach would be to throttle and filter which control methods to call based on [AcceptFormat("application/atom+xml")] attributes or something similar? Being able to route the request to the correct control method based on the requested format would be nice to have handled on the same level as [AcceptVerbs].
The underlying logic would in most cases be very similar for both "text/html" and "application/atom+xml" return types, but as Luke mentions, you'd like to alter the output for Atom documents so the header is added and such (which obviously should be done once, perhaps through a response filter or something similar).
Javier Lozano • August 17th, 2009
Great post, thanks for the info, Phil!
One question, how do I use SOAP with this new toolkit? :P (j/k)
ranamauro • August 17th, 2009
@Luke Sampson: the way you define a view for a particular request type is by providing an IResponseFormatHandler. There is an Atom sample (Product\sdk\MovieApp\AtomResourceSample) that illustrates how you would do this for the Atom format (Infrastructure\AtomFormatHandler.cs) and it is built on top of SyndicationItem & SyndicationFeed.
The basic idea is that you can register handlers with the FormatManager, and each time an action on a controller has executed and provided a model, your handler will be called and asked if it can handle the response format that the request asked for (normally via Accept header), and if so it will be asked to reneder the response based on the model.
All of the above works for de-serializing requests (using the model binder infrastructure) and it is based on IRequestFormatHandler.
tvish • August 17th, 2009
@LukeSampson, @AsbjornUlsberg
The format support is as follows: Just like in MVC you can return specific ActionResults for specific formats from you controller method if you so desire. The SDK includes specific action results for Atom, RSS, XML, JSON etc for this case.
However often times one wants the controller method to not contain switch statements about the format. Instead, the SDK allows you to register format handlers (for request and response) and allow the controller method to work in terms of CLR types.
Declaratively specifying the formats a controller method handles seems like a good feature to consider for the next drop. Thanks for the feedback.
The Jay Mann • August 17th, 2009
@ranamauro
Well, that's great, I missed that sentence the first time going through (though, I read it about 1 hour before going to bed, so I wasn't in the most active state, I guess). Now I'm much more apt to try this out, although the lack of support for the Accept header from Windows RSS Platform is still a bit disheartening.
ranamauro • August 17th, 2009
@The Jay Mann: good to hear you'll give it another look, we definitely look forward to receiving more feedback.
if Windows RSS Platform insists in sending Accept: */* you should stil be able to use mechanism #1 to select the appropriate format (?format=application/atom+xml), at least with this release. for the future we will probably look into adding extensibility into the mechanism that determines the format to send back (EG: I imagine you could do this based on the User-Agent or other request metadata).
Tian Chen • August 18th, 2009
There is a discussion going on a Chinese blog:
www.cnblogs.com/.../...ign-in-asp-net-routing.html
related to the RouteBase class. The author was wondering why MVC team didn't follow the Framework Design Guildlines'
interface->default base class implementation
approach?
Or because your team has some extension idea in mind?
Thanks.
mikekidder • August 18th, 2009
Noticed the ActionLink's uri for the "Home" tab and "Log On" in the samples are changing based on the last http request. Bug? Obviously, a different behavior than the original MVC.
Chris • August 18th, 2009
Just to add to this MVC/REST party, take a look at kohari.org/.../siesta-painless-rest-via-asp-net... from the Ninject author as another option.
Jarrett Vance • August 18th, 2009
This topic is very interesting to me as I've worked on an AtomPub implementation in both WCF and MVC. So I completely understand why people creating simple web APIs rather use MVC than WCF.
At first, I was very confused about the "hybrid" terminology as the solution does not use both MVC and WCF. Just to be clear, there is no WCF in this solution.
I do think this is a neat way to quickly expose a web API in MVC as the web programming model does it in WCF. However, in practice:
1) There is almost always a need to handle web form post differently than a straight resource post (xml, atom).
2) There is typically a service/business layer that doesn't care about the wire format.
So I also agree with Luke and Phil and think the plain old MVC is better. I also like the idea of the [AcceptFormat("application/atom+xml")] attribute.
Piers Lawson • August 18th, 2009
I was never quite convinced by the WCF version of REST. It seemed very heavy weight and did not have the flexibility that I could get using ASP.Net MVC. I've written a whole series on getting what I believe is a truely RESTful service working with ASP.Net MVC. It also supports multiple representations, including HELP. However it provides a true MVC approach to serving XML where the views are XSLT files.
What I would like to see in the next version of MVC, rather than WCF being brought in, is support for overloading POST as I described in this article, built in support for XSLT views as I created here and more control over the errors returned to the client.
I'd love to know what you think of the series:
http://shouldersofgiants.co.uk/Blog/category/ASPNet-MVC.aspx
Having said that... I'll give this SDK a try. Thank you for pointing it out!
Piers
Sebastien Lambla • August 18th, 2009
@phil I dont think routing to different methods for different media types is a good idea. That's exactly the kind of horrible things WCF REST does.
There's also an issue with putting the media type in the querystring, as this prevents caching from being done on those URIs.
And I suppose someone should mention it, so I may, if you want something built from the ground-up for ReST, you can have a look at http://www.openrasta.com
Nice to see more interest in REST.
tvish • August 19th, 2009
@Sebastien
To be clear, WCF REST does not do dispatch to different methods based on different media types. You can specify the format in the URL using WCF REST 3.5 (?format=xml for example) but the framework does not do dispatch based on media type. In .Net Framework 4.0 WCF automatically does request and response format selection based on AcceptHeader+ContentType.
I would encourage you to look at the SDK samples and functional tests again. The primary model for format selection is based on content-type and accept header. Now we also support ?format=xml|json etc just because it eases the development experience - you can view the different formats in the browser without needing to use Fiddler or write a REST client.
cellphonelookup • August 19th, 2009
As long as you have the area code and the seven digit number, you should be able to locate any number's owner, if you know cell phone lookup reviews viste this web: cell phone lookup reviews, Reverse Phone Lookup Online Reviews Blog , Reverse Phone Lookup Reviews
Piers Lawson • August 20th, 2009
I've had a bit of a poke around and have some comments. I like that you support the format parameter in the query string as I actually prefer this over the accepts header approach (I'm afraid I swallowed the Richardson and Ruby book whole and they give more eloquent reasons for using the query string approach than I could muster). I also like your use of a custom controller factory, though I wonder how much complication this introduces when you are solving a fairly simple problem.
What I would like to see or don't like so much:
I'm not convinced about how well a web site and a web service served from the same URIs and controllers works. I feel they serve different audiences and purposes and tying them so closely together could constrain them both. For instance your example uses "edit" and "create" in the URI whereas I would expect a web service to support PUT direct to an id and POST direct to the index. So instead of POST to /Home/Create a client would POST to /Home and instead of using PUT to /Home/Edit/5 the client would PUT to /Home/5. You're approach doesn't preclude this... I'm just illustrating the "danger" of making the same site act as both a human consumable web site and a web service.
There is no way to manipulate the XML / JSON being served. That means one of the major REST principles "Hypermedia as the engine of application state" is not possible to achieve without polluting your model with properties that hold URIs. If you provided a transformation step, URIs could be injected into the outgoing representation. Also, the outgoing representation could be manipulated in other ways that the developer deems appropriate (e.g. supporting HEAD with a cut down representation, adding namespaces etc. etc.). This to me is crucial... it is meant to be Model VIEW Controller after all!
I'd love to see overloading of POST built in so that client's that don't support PUT and DELETE can use these verbs.
Is there a more formal place to discuss this functionality?
tvish • August 20th, 2009
@Piers
Thanks for trying out the SDK.
WRT PUT to /Home/5 instead of POST to /Home/Edit/5: Actually the SDK enables 2 different styles of MVC websites - POX APIs and REST APIs. The MovieApp_POXSample shows you the former, where the "action" is part of the URL (in line with traditional ASP.NET MVC). On the other hand it is also possible to create very RESTful APIs where there is no action in the URL - the MovieApp_ResourceSample shows how that can be done.
We do support method overloading. You can specify the actual method using the XHttpMethodOverride HTTP header or using a hidden form field with the same name. The MovieApp_ResourceSample should illustrate that.
The post-processing step where the links are inserted is interesting. We did play around with some ideas along those lines and were planning to get feedback in a subsequent drop.

Feedback on the blog is good. Codeplex issue tracker is also another way to give the feedback.
Piers Lawson • August 20th, 2009
Thanks for the extra information. The ability to overload POST is good, though (for non-browser clients) you appear to only look at the X-Http-Method-Override header... why not also look at the
querystring for an override? Regurgitating from Richardson and Ruby "A client that doesn't support PUT and DELETE is also likely not to support custom HTTP request headers."
Along the same lines, if I read the code correctly, you only support the format=xml querystring if the client is a browser. Why restrict this to browsers only? The same argument stands from above; some clients can't support changing the headers. Besides which, putting details of the representation in the URI makes it more addressable, which I prefer.
All in all then, I think it is a good start. I would still need a way of transforming data before it is transmitted and transform it on reception... this is not just to add links, it allows the internal and external representations to evolve independently. For XML I used XSLT and an XsltExtension. The XsltExtension used UrlHelper.Action to generate the link from the routing table. For JSON I used JavaScriptConverters.
If you address these issues you could have a convert! When do you think this could become part of the main ASP.Net MVC? Or would it always be standalone?
tvish • August 21st, 2009
@Piers
Thanks for giving the requirement. In the current SDK, the FormatManager is the component that handles serialization and deserialization of data in non-HTML formats (XML, JSON etc). You can register IRequestFormatHandler, IResponseFormatHandler implementations that handle serializing and deserializing a particular format. By default we populate the FormatManager with IRequestFormatHandler and IResponseFormatHandler implementations that process XML and JSON formats.
So I think one way you can achieve what you are trying to do is to register your own implementations of IRequestFormatHandler, IResponseFormatHandler for XML and JSON that wrap the default implementations and do the transformation after serialization/before deserialization before delegating to the default implementations to do the bulk of the work.
Would that work for you?
Kiran • August 23rd, 2009
It would be nice if default implementation enables us to swap the out of the box JSON Serializer with other components like NewtonSoft's json.net serializers.
Piers Lawson • August 23rd, 2009
Yes, that would work. However, it doesn't move me much forward from my current solution... I'd still have to write the custom format handlers. I would be happy to do that if you addressed the other issues I raised:
1) Should be possible to override the Method using a querystring parameter
2) Method override using a form variable (and querystring if 1 is implemented) should not be restricted to browser clients only
3) Format override should not be restricted to browser clients only
4) some commitment to the future of this functionality... will it be built into the full ASP.Net MVC release or formally supportted in some other way.
If I get time, I will write another blog entry that uses your framework.
ranamauro • August 24th, 2009
@Kiran
We've looked into that, but it turns our that switching out just the serializers isn't that simple because they usually have different APIs, so you'd need to implement your own IRequestFormatHandler/IResponseFormatHandler.
The sdk\MovieApp\EdmSample illustrates exactly this scenario, where we replace the OOB JSON handler (which is built on the DataContractJsonSerializer) with one built on the JavaScriptSerializer.
I hope this looks like a reasonable solution, but I'd appreciate hearing any suggetsions to improve the experience :)
Kiran • August 25th, 2009
@ranamauro
Yes. That worked fine. Thank you.
PK • August 25th, 2009
SDK team, is there an intent to bake some of this into ASP.NET MVC 2.0 _assuming_ the community approves of it? If so, is there time left?
As much as I love all this MVC stuff, I'm starting to get a bit 'Beta-Tired' at the moment *blush*. I really jumped onto the ASP.NET MVC bandwagon early (because i've been DYING for this to come to the ASP.NET world) ... but as we all know with BETA's, etc... expect things to change :) I'm all well and good with that .. but just a bit tired after doing that for a year .. so i'm having a break until 2.0 is released (instead of me changing, changing, changing, etc :) ).
Which is why i'm _hoping_ this will be baked in really early, if we're all pretty kewl with it...
Uzivatel • August 25th, 2009
Hi Phil,
I was using JSON.NET for DTO serialization (JSON format) and was happy with it. Haven't look on the sample (will have time on weekend) but is there a possibility to exchange default serialization engine with JSON.NET somewhere?
Is there a source code avaiable?
Thanks for the answer!
ranamauro • August 26th, 2009
@Uzivatel
It is definitely possible to do so. I did a proof of concept based on the EdmSample (the one in sdk\MovieApp\EdmSample I mentioned in my earlier post) and swapped the use of the JavaScriptSerializer with calls to the JsonConvert API and it worked fine. In fact I was able to get my JSON indented as follows by simply specifying Formatting.Indented:
[
{
"Id": 1,
"Title": "Star Wars",
"Director": "Lucas",
"DateReleased": "\/Date(251884800000-0800)\/",
"EntityKey": {
"EntitySetName": "MovieSet",
"EntityContainerName": "MoviesDBEntities",
...
If there's enough interest I could write up a small blog post illustrating the necessary steps and a zip of the code I wrote.
Hope this helps.
PK • August 26th, 2009
@Ranamauro : that would be a lovely idea :)
ranamauro • August 26th, 2009
@Uzivatel, @PK
The post is up, I hope it helps:
ranamauro.blogspot.com/.../...ntegrating-with.html
PK • August 27th, 2009
@Ranamauro: Sure does! that's great :) :) Also, with conditional compilation constants, we could maybe get the best of both worlds :)
eg.
#if DEBUG
string json = JsonConvert.SerializeObject(this.Data, Formatting.Indented);
#else
string json = JsonConvert.SerializeObject(this.Data); // Assuming this is a legit method signature.
#endif
:P
(or even use IoC for the Json type, for those who are really hardcore).
thanks heaps Ranamauro! good stuff :)
Liu Peng • August 30th, 2009
@Ranamauro: I try to return the JSON type of result by pass a accept type "application/json", what I use is jQuery's AJAX.
But the response is also the HTML format like the above:
$.getJSON('http://localhost:8082/')
When I add a query string parameter "?format=Json" the result will be JSON type:
$.getJSON('http://localhost:8082/?format=Json')
I debugged the source code and find that the $.getJSON will pass three accept types and the order is
[0]: {application/json}
[1]: {text/javascript}
[2]: {*/*}
In the HttpHelper.GetAcceptHeaderElements function has one code will store the content type:
contentTypeList.Sort(new AcceptHeaderElementComparer());
After store the order will be:
[0]: {*/*}
[1]: {text/javascript}
[2]: {application/json}
In the WebApiEnabledAttribute.OnActionExecuted only the first content type "/" will be pass, so the result is HTML and NOT JSON.
After I commented the sort code the result will be JSON.
Could you tell me the purpose for the "sort" code?
ranamauro • August 30th, 2009
@Liu
Sorry, you're hitting a code defect in this sample where we are incorrectly handling '*/*'. The purpose of the "sort" code is to order the content types the client is willing to accept so we can return the one that is most preferred.
We will be refreshing the sample with a fix and a couple additional functional tests to better cover this functionality, but in the meantime you can change the code in src\System.Web.Mvc.Resources\HttpHelper.cs and in AcceptHeaderElementComparer.Compare() replace the if statement (should be line 159) with the following:
if (string.Equals(xTypeSubType[0], yTypeSubType[0], StringComparison.OrdinalIgnoreCase)) { if (string.Equals(xTypeSubType[1], yTypeSubType[1], StringComparison.OrdinalIgnoreCase)) { // need to check the number of parameters to determine which is more specific bool xHasParam = AcceptHeaderElementComparer.HasParameters(x); bool yHasParam = AcceptHeaderElementComparer.HasParameters(y); if (xHasParam && !yHasParam) { return 1; } else if (!xHasParam && yHasParam) { return -1; } } else { if (xTypeSubType[1][0] == '*' && xTypeSubType[1].Length == 1) { return 1; } if (yTypeSubType[1][0] == '*' && yTypeSubType[1].Length == 1) { return -1; } } } else if (xTypeSubType[0][0] == '*' && xTypeSubType[0].Length == 1) { return 1; } else if (yTypeSubType[0][0] == '*' && yTypeSubType[0].Length == 1) { return -1; }
Hope this helps.
ranamauro • September 1st, 2009
Just a quick note, Phil has refreshed the drop in place, so you can download it from the exact same location. It contains the fix above and a couple additional tests to cover the scenario that was fixed (there's a also a minor fix to one of the test's csproj so its references resolve correclty on a 64 bit machine).
If folks would like to see another blog post covering some specific aspects of this SDK, please let me know, I'll be happy to do more :)
Piers Lawson • September 4th, 2009
Hi again... I've had a better look at the SDK now and tried migrating my sample web service to it. See my blog entry.
A quick summary of my thoughts:
1) I like the idea of using an attribute to mark a controller as supporting REST;
2) I like the FormatHandlers approach and being able to add my own;
3) Rather than providing ResourceControllerFactory to implement overloading of POST, I think it would be better to provide your own version of HttpRequestWrapper. Which would also allow you to override "Content Type" and "Accepts" all in one central place... transparently;
4) I think your overrides should not be restricted to just browser clients;
5) I'm not sure how well ResourceModelBinder deals with registering objects with ModelState... but I could be way off the mark there;
6) It would be great to see "Views" being added to the XML and JSON FormatHandlers.
Item 3 would not only remove the need for ResourceControllerFactory, but also simplify WebApiEnabledAttribute
All in all I learnt a lot more about ASP.Net MVC and picked up some good ideas. I hope you keep working on this... if ASP.Net MVC supportted multiple formats natively that would be great.
Thanks for publishing your work so far!
T • September 9th, 2009
I used the ASP.NET MVC REST SDK for building atom feedS for our exception logging dashboard and it worked perfect.
When creating the syndication content, I used CreateHTMLContent and added a tag around my HTML content string. Now it shows in a nice formatted way on internet explorer. But when reading the feed through outlook 2007, I am losing the formatting. Do you have any idea how to format the feeds for outlook 2007.
Thanks,
Greg Beech • September 21st, 2009
The sample seems fairly solid from a basic architectural point of view, however as it stands it can't be used with our API because we have a requirement to support multiple concurrent versions of resource representations.
We have a very similar format handler implementation, but we also allow transformation of the request/response from a version-specific resource representation to/from a version-agnostic model based on the media type.
To do this we use a custom media type with a "version" parameter, and then have pluggable request/response model transform interfaces following the CanTransform/Transform pattern.
This type of multiple concurrent version scenario is very important to many API builders, as few of us are big enough to demand that consumers upgrade when we do, so I think it's critical that it is built into any serious API framework.
If you want to contact me regarding this, I'm happy to provide more information.
PK • September 22nd, 2009
@ranamauro : is it possible to have some json/xml response when there's an error?
eg. Imaging u're after some json data for the a list of all the movies. For some weird reason, an exception occured. As such, we want to reply with a custom json error message and an http status 500. Is this possible, with this SDK?
ranamauro • September 24th, 2009
@PK: yes it is possible. If you look at the controllers in any of the examples you will notice that the model is based on HttpException: in any action you can do throw one of those, EG:
throw new HttpException((int)HttpStatusCode.InternalServerError, "There was an error processing your request");
the exception will be handled by the SDK code and rendered in the appropriate format on the wire. What's in the SDK currently by default will just serialize a string on the wire, resulting from HttpException.ToString(), but you can override this, by setting HttpException.Data["details"] to any object of your choice, and we will serialize that instead (this code is in ResourceErrorActionResult.cs BTW).
ranamauro • October 5th, 2009
For folks still listening on this thread, I just wanted to point out that this SDK is included in Futures as part of MVC 2.0 Preview 2.
This is the link to the download:
[a]aspnet.codeplex.com/.../ProjectReleases.aspx[/a]
And of course the post on this blog announcing the release:
[a]haacked.com/.../...net-mvc-preview-2-released.aspx[/a]
Kiran • October 9th, 2009
The SDK is returning 'Not Found' error in google chrome browser. This is because of the AcceptTypes in google are different. The first item in the ordered list is 'application/xml' instead of text/html.
ranamauro • October 11th, 2009
@Kiran:
this is a known behavior of Chrome and one that others also find incorrect. there's currently a bug filed for the issue, you can see it here:
code.google.com/p/chromium/issues/detail?id=13137
if this is blocking you I can probably get passed it by special casing the content-nego code for User-Agent "Chrome/*".
Piers Lawson • January 20th, 2010
I have updated my RESTful extension for ASP.Net MVC to take some ideas from this SDK and hopefully go further. For instance my extensi0on supports a Help representation, encoding, overloaded POST, requesting a particular represention via the URI etc etc.
I would love some feed back on it see:
http://shouldersofgiants.co.uk/blog/