Web API - Rendering Razor view by default?

Question

How do I get Web API to render a Razor view using the model that it returns? And only XML/JSON when the accept headers (or .extension) is set? Is this even possible?

It

Answer 1

I am looking for something similar to this, but not entirely. Through scouring the web, I found a couple posts by Fredrik Normen. He writes about this exact problem space and actually identifies a third-party solution in the second post listed. Basically, the solution involves creating a custom MediaTypeFormatter that knows how to handle views using the Razor engine provided by Microsoft (through the use of a third-party library).

• Using Razor engine together with Asp.Net Web API to create a Hypermedia API
• Using Razor together with ASP.NET Web API
• ASP.Net Web API and using Razor the next step

Hopefully Microsoft will implement something soon in Web API as Hypermedia seems to be gaining traction.

Hope this helps!

Answer 2

It seems crazy to require one set of controllers for rendering HTML and another for JSON/XML if they're working on the same models.

Web API is exactly what it is called - a technology for creating API's.

If you are creating an ASP.NET MVC application and want to return some JSON for your own purpose then you don't need content negotiation etc. therefore you don't need Web API (just use plain old good JsonResult).

If you want to create a reusable API than Web API is what you need but your client application should consume it in the same way as everybody else.

Web API isn't meant to be a "hammer" for "nailing" all non-HTML requests - use it when you need it.

Answer 3

I asked a similar question about this in the past on StackOverflow, because I wanted to do the same thing. However, I eventually ended up with an "Api" area and set of controllers, and a standard set of MVC controllers for the website.

In hindsight this actually wasn't a bad thing. I've found I tend to do different things in each set of controllers anyway. My views aren't just CRUD but tend to contain extra contextual data, so returning view models specific to that page is nice.

I think if I had stuck to my goal of combining the two I might have ended up with either over-complicated controllers or a user experience that wasn't as optimal as it could have been. So while this isn't a direct answer to your question, in my experience not being able to do this might not be such a bad thing.

Instead I've ended up with a rich set of builders and commands that most of my controllers delegate to. That way I can reuse most of the controller logic while being able to do specific things for API versus the web:

http://www.paulstovell.com/clean-aspnet-mvc-controllers

Answer 4

Yes, it is how it is designed for: Web API for data and MVC for rendered views. I know that some people will try adding view engine support to web API but it is not designed for it.

My personal view on this is that this parallel world between MVC and Web API (which is the source of most criticisms while community has generally praised the product) is mainly a consequence of the fact that Web API has been added to MVC without having a reference (or knowledge of it).

As Jon Galloway said on a recent podcast, had the team have HTTP knowledge they have now (as well as hindesight of the popularity of REST API now which they did not have then), they would have designed just a single pipeline serving data and rendered view alike.

I can only speculate that the future version of MVC/Web API will be presented as a single pipeline. In fact, this parallel world might have been a careful plan to unify them in the near future.

Answer 5

It seems crazy to require one set of controllers for rendering HTML and another for JSON/XML if they're working on the same models.

AFAIK, that's how it is. Standard controllers should be used for rendering HTML and ApiControllers for JSON/XML.