Question

In my initial stab at creating a MVC4 Web API. I’ve noticed a few things about the way routes are handled that seems a little off:

• Controllers no longer ever have more than 4 actions?
• A resource that only supports one HTTP verb still gets it’s very own controller?
• The route hierarchy tends to be very flat, OR
• An extremely large number of routes must be specified/maintained compared to MVC apps for humans.

I’ve created fairly large sites that use only two or three routes, but I’m just starting on my API and I’m up to almost a dozen. I guess APIs by their nature lend themselves to deeper URLs than websites, but this seems a little excessive.

I feel like I’m missing a namespace somewhere or a routing convention. I attribute nearly all of this to the fact that action names are no longer part of the route, just the HTTP method. Is there a way to support routes by anything other than parameter matching, controller name, and HTTP method?

Answer 1

You can modify the routing in Global.asax. The default is set to:

           routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }

But you could change it for example to use the action name:

routes.MapHttpRoute(
name: "ActionApi",
routeTemplate: "api/{controller}/{action}/{id}",
defaults: new { id = RouteParameter.Optional }

For more information on custom routing in MVC WEb API look at this article.

Update based on comments

Above was the answer to the question, “can I change the routing?” The short answer is yes, but as was pointed out in another answer you may not want to and maintain a good REST API. MVC Web API with it default routing maintains the basic REST concept that you are working on resources, with the controller representing the resource. In your other question you give the example:

DELETE /account/1234/note/321 <- delete note 321 on account 1234

Where you want to delete a note on account 1234. In this case the resource you are working on is a note. A better representation for this would be to use query string so your API for this example would look like this:

DELETE /note/321?account=1234 <- delete note 321 on account 1234

This way you do not need to mess with the routing and it is clear that the resource being acted upon is a note with filters being used. But I would also question whether adding this explicit filter (i.e. where clause) is necessary if the id for note is unique for the whole application and not just for a specific account.