One of the most confusing aspect of MVC and Web API is the subject of routing. MVC routing looks and feels more logical to most developers as compared to the Web API routing. The reason behind this is that Web API depends on the HTTP verb to match the action being called. It follows a set of conventions which automatically fires a particular action based on the endpoint being hit. This throws of most of us because we are in the habit of calling methods by name.
Hopefully this post will give you a head start at what is the simplest or the default way in which Web API manages its routing based on conventions. I will show all the concepts using simple boiler plate code, don’t focus on the logic inside the Action(method).
The tools being used in this post is Visual Studio and Postman.
For the uninitiated, please open up a file called WebApiConfig.cs, the default route is defined there
This is the code that I have written
Now let us run the application and fire up Postman, which will help us in changing the verb and understanding the concept a bit better.
As you can see the call does not specify any function name yet it automatically maps to the first Get Action in the program. How did it happen?
Simple the Http Verb being used is Get , so the API engine looks for a function which has a name starting with Get and takes no parameter. In the code only Action that matches this criteria is the first one. I could have named the action anything that I want but it would have made no difference and the first action would have been called because routing is done on HTTP verb name rather than action name.
Next we try to find a specific employee based on the id so we change the endpoint to
This time the engine looks for the action which has a name starting with Get and accepts one integer parameter, in our case it is the second one.
If you had two functions with the same parameter list but different name, each starting with Get, something like GetEmp(int id) and GetOnId(int id) then the engine would have raised an exception because it only looks for the verb name and the parameter list and unlike the traditional polymorphism the action name has no effect on it.
Now let’s try to call the delete action, again we need to change the HTTP verb to make this work
Let’s recap how did it find the Delete action without the name?
It looked for an action which has the name starting with the HTTP verb being used in our case Delete and the action should accept one parameter of int type.
I hope this simple demo has made the convention based routing of Web API clear, once you try it out you will love the simplicity of the specification.
But if you are still not convinced then in my next post I will discuss ways to modify this behaviour and conform more with the traditional approach without breaking the Web API’s inherent beauty.
Want to know more about me or hidden gems in Web API , JS, C#, then visit me at my blog here.