Introduction to Routing

The routing engine is responsible for getting the incoming request and routing that request to the appropriate controller based on the URL pattern. We can configure the routing engine so that it can choose the appropriate controller based on the relevant information. In other words, routing is a programmatic mapping that states which method of which controller is to be invoked based on some URL pattern.

By convention, ASP.NET MVC follows this pattern: Controller/Action/Id.

If the user types the URL http://yourwebsite.com/Hello/Greeting/1, the routing engine selects the Hello controller class and Greeting action method within the Hello controller, and passes the Id value as 1. XXXController is a naming convention and it is assumed your controllers are always ending with a controller suffix. You can give default values to some of the parameters and make some of the parameters optional.

The following is the sample configuration:

The template: "{controller=Hello}/{action=Greeting}/{id?}");

In the preceding configuration, we are giving three instructions to the routing engine:

• Use the routing pattern controller/action/id.
• Use the default values Hello and Greeting for controller and action respectively, if the values for controller or action are not supplied in the URL.
• Make the id parameter optional so that the URL does not need to have this information. If the URL contains this Id information, it will use it. Otherwise, the id information will not be passed to the action method.

Let us discuss how the routing engine selects the controller classes, action methods, and id values for different URLs. We'll start with URL1, here:

URL1: http://localhost/
Controller: Hello
Action method: Greeting
Id: no value is passed for the id parameter

The following action method will be picked up by the routing handler when the preceding URL is passed:

public class HelloController : Controller
{
  public ActionResult Greeting(int id)
  {
    return View();
  }
}

Let's look at URL2, here:

URL2: http://localhost/Hello/Greeting2
Controller: Hello
Action method: Greeting2
Id: no value is passed for the id parameter

The following action method Greeting2 will be picked up by the routing handler when the preceding URL is passed:

public class HelloController : Controller
{
  public ActionResult Greeting(int id)
  {
    return View();
  }
  public ActionResult Greeting2(int id)
  {
      return View();
  }
}

Let's look at URL3, here:

URL3: http://localhost/Hello2/Greeting2
Controller: Hello2
Action method: Greeting2
Id: no value is passed for the id parameter

The following action method will be picked up by the routing handler when the preceding URL is passed:

public class Hello2Controller : Controller
{
  public ActionResult Greeting2(int id)
  {
    return View();
  }
}

Let's look at URL4, here:

URL4: http://localhost/Hello3/Greeting2/1
Controller: Hello3
Action method: Greeting2
Id: 1

The following action method will be picked up by the routing handler when the preceding URL is passed:

public class Hello3Controller : Controller
{
  public ActionResult Greeting2(int id)
  {
    return View();
  }
}

Another common pattern is to use more RESTful programming practice. We instead treat URLs as Resource ID and send the action as an HTTP method such as GET or POST.

So, from a classical MVC point of view, if you need to edit a book, you send a post to http://yourwebsite.com/Books/Edit/1 with a POST request, and the body contains the new book details.

However, from a RESTful standpoint, you would use http://yourwebsite.com/Books/1 with a PUT or PATCH request, and the request body contains the book details.

The point of RESTful programming is to have some sort of standardization that everyone agrees on at least up to a certain degree. For the RESTful case you don't have to document your API. Everyone knows that a PUT request replaces the resource that is by HTTP standard. However, for the actions, someone can call it Edit whereas another can call it Update. Of course, with web applications that are not intended to be used as an API, this is less valuable. However, you might want a reusable API along with your web application. That's where the RESTful approach shines. For that case, your web pages just become a special case of the API and you have less duplication.