I’m looking at using ASP.Net MVC as a platform for a REST based Service. I know WCF has built in support for REST services; however, I’m looking at returning multiple types of data depending on the request.
I would like the client to request the content type. So if they send text/html for example I would render my model into Html, if they request text/xml it would return xml. We could also do JSON.
Does anyone see any issues with this?
Not using WCF could increase the complexity of the client when calling the service since they won’t be able to auto-generate a proxy; however, in my case, the clients will be either browser requesting html, or java client libraries processing the xml.
Since were not using WCF we need to secure the service; however, I’m thinking we can do this using forms authentication.
The benefit of this is that no matter what type of data the client is requesting it is all going through the same controllers / models etc…
After reading Haack’s post, about using extensions to indicate the content type, I think your better off keying off the Accept Header. Seems more Rest’ish to me, although granted its a little more difficult to fire up a browser and test your url.
I through together a little blog article about doing this and using a ModelBinder to abstract out the HttpContext from your controller: http://jberke.blogspot.com/2009/03/aspnet-mvc-model-binder.html.
Additionally in response to Troy’s opt-in comment, I was using the view to render Xml of my model. This allowed me to have different xml formats for the same model. Which makes sense. What if you need to support versioning or different formats for different clients. I don’t like the idea of the framework automatically rendering anything.