welcome to XRM blog

Keep in touch with latest CRM/ERP articles

To remain competitive your organisation must be efficient across the business process spectrum. To do so you need to take sound decisions based on a balance between the cost and risk. To do so you will be heavily dependent on your content management in itself needs...

image
Blog

Web API Convention Based Routing

By Sudeep on 1/18/2016

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.

 

.Net
Web API
Author
Blog Calendar
Blog Calendar List
2018 Nov  26  3
2018 Oct  7  3
2018 Sep  13  11
2018 Aug  2  2
2018 Jun  11  1
2018 Jan  41  2
2017 Sep  348  5
2017 Aug  14  1
2017 Jul  15  2
2017 Jun  36  2
2017 May  17  1
2017 Apr  31  2
2017 Mar  104  4
2017 Feb  269  4
2016 Dec  171  3
2016 Nov  267  8
2016 Oct  197  10
2016 Sep  341  6
2016 Aug  38  1
2016 Jun  1580  6
2016 May  102  3
2016 Jan  68  2
2015 Dec  373  6
2015 Nov  3  1
2015 Oct  11  1
2015 Sep  1105  6
2015 Aug  10  1
2015 Jul  101  2
2015 Jun  7  1
2015 May  20  1
2015 Apr  21  2
2015 Mar  67  3
2015 Jan  4998  4
2014 Dec  14  1
2014 Nov  2159  4
2014 Oct  74  2
2014 Sep  95  2
2014 Aug  2848  1
2014 Jul  40  2
2014 Apr  2401  12
2014 Mar  268  19
2014 Feb  216  8
2014 Jan  1490  16
2013 Dec  21  2
2013 Nov  607  2
2013 Oct  239  3
2013 Sep  10  1
2013 Aug  29  3
2013 Jul  202  1
2013 Apr  43  6
2013 Mar  1634  10
2013 Feb  272  4
2013 Jan  244  2
2012 Nov  24  2
2012 Oct  394  10
Tag Cloud
Interested in our services? Still not sure about project details? get a quote