As we just saw, the new routing implementation is basically handled by the two services.AddMvc() and app.UseMvc() methods called within the Startup.cs file, which perform the following tasks respectively:

• Registering MVC using the Dependency Injection framework built into ASP.NET Core
• Adding the required middleware to the HTTP request pipeline, while also (optionally) setting a pack of default routes

We can take a look at what happens under the hood by looking at the current implementation of the app.UseMvc() method in the framework code (relevant lines are highlighted):

 public static IApplicationBuilder UseMvc( 
    [NotNull] this IApplicationBuilder app, 
    [NotNull] Action<IRouteBuilder> configureRoutes) 
{ 
    // Verify if AddMvc was done before calling UseMvc 
    // We use the MvcMarkerService to make sure if all the services    
      were added. 
    MvcServicesHelper.ThrowIfMvcNotRegistered(app.ApplicationServices); 
 
    var routes = new RouteBuilder 
    { 
        DefaultHandler = new MvcRouteHandler(), 
        ServiceProvider = app.ApplicationServices 
    }; 
 
    configureRoutes(routes); 
 
    // Adding the attribute route comes after running the user-code   
      because 
    // we want to respect any changes to the DefaultHandler. 
    routes.Routes.Insert(0, AttributeRouting.CreateAttributeMegaRoute( 
        routes.DefaultHandler, 
        app.ApplicationServices)); 
 
    return app.UseRouter(routes.Build()); 
} 

The good thing about this is the fact that the framework now handles all the hard work, iterating through all the Controller's Actions and setting up their default routes, thus saving us some work. It's worth noting that the default ruleset follows the standard RESTFUL conventions, which means that it will be restricted to the Get, Post, Put, Delete action names. Here, we can say that ASP.NET Core is enforcing a strict WebAPI-oriented approach, which is much to be expected since it incorporates the whole ASP.NET Core framework.

Following the RESTful convention is generally a great thing to do, especially if we aim to create a set of pragmatic, RESTful-based public APIs to be used by other developers. Conversely, if we're developing our own app and we want to keep our API accessible to our eyes only, going for custom routing standards is just as viable. As a matter of fact, it can even be a better choice to shield our Controllers against some of the most trivial forms of request floods and/or DDoS-based attacks. Luckily enough, both the Convention-based Routing and the Attribute-based Routing are still alive and well, allowing us to set up our own standards. If we want to enforce the former approach, we can extend the code already present in the Startup.cs file; conversely, we can keep doing what we previously did within our Controllers source code, where Attribute-Based Routing is widely present either at Controller level:

 [Route("api/[controller]")] 
public class ItemsController : Controller 

Alternatively, it can be present at the action method level:

 [HttpGet("GetLatest")] 
public JsonResult GetLatest()