welcome to XRM blog

In today’s world if we are using any service on the internet, we are consuming some sort of APIs in many ways. Even the article you are reading is coming as a response to an API request to our servers. Have you ever thought how you are able to see Google Maps on websites other than Google? That is where the APIs comes into picture.

One of the most common issues we face is creating a REST API for our client which is hosted on a brand new domain while the client application is being hosted on the clients old domain. Specifically when client demands that we carry both the system parallel for couple of months until he/she has confidence on the upgraded API's. In our own company we found this issue when launching a brand new domain for a new application. Unfortunately the new application hosted on the new domain talks to our old REST API hosted on our company domain. Problem!

In my previous post here I had discussed about convention based routing which is the default way in Web API. Check it out here.Starting with Web API 2 Microsoft introduced attribute based routing. Which is way more simpler. The reason for introducing this new feature was two folds, one it is easier to understand and maintain, second is the kind of REST calls required.

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).