Você que utiliza ASP.NET MVC já se perguntou algum dia como seu browser consegue chamar métodos dos seus controladores? Já ficou curioso a respeito de por que as URLs da sua aplicação funcionam da forma que funcionam? Por que, afinal, um nome que nada tem a ver com minha página faz com que ela seja carregada nos navegadores dos meus usuários? E se eu quiser definir ainda outros endereços para minhas páginas ou ações? Chegaremos à luz de tudo isto através do mecanismo de roteamento do ASP.NET.
Uma das características básicas dos serviços REST, por exemplo, é que todo recurso é mapeado por uma URL (Uniform Resource Locator). É através dessa URL que sabemos como chegar até este recurso e executar uma determinada ação.
Cada URL identifica um recurso específico e tem a seguinte sintaxe: [scheme]://[host]:[port]/[path][?query], em que cada fragmento tem uma representação e funcionalidade, detalhadas abaixo:
<ul>
<li style="text-align: justify;">         Scheme: Identifica o protocolo que será utilizado para fazer a requisição, podendo ser: HTTP, HTTPS, FTP, etc.</li>
<li style="text-align: justify;">         Host: O Host define o nome (fornecido pelo DNS) ou o endereço IP do servidor.</li>
<li style="text-align: justify;">         Port: Opção para definir o número da porta (no destino) que será utilizada para receber a requisição. Se omitido, utilizará a porta padrão do protocolo, que no HTTP é a porta 80, no HTTPS a porta 443, etc.</li>
<li style="text-align: justify;">         Path: Este é o fragmento da URL que identifica o recurso em si. É através dele que apontamos qual dos recursos  desejamos acessar naquele servidor.</li>
<li style="text-align: justify;">         Query: Informação opcional que pode ser encaminhada para o serviço, fornecendo parâmetro(s) adicional(is) para o processamento da requisição. Um exemplo clássico é a inclusão do identificador do recurso que está sendo solicitado.</li>
</ul>
Até pouco tempo, as URLs eram indecifráveis para o usuário final, pois geralmente mapeavam um recurso para um arquivo físico da árvore de diretórios do servidor, e por isso, acabavam por vezes sendo muito extensas e/ou não faziam muito sentido para quem as lesse.  Aos poucos, elas foram ficando cada vez mais legíveis, mais amigáveis, facilitando o entendimento do usuário e favorecendo uma leitura melhor dos recursos que elas representam. Outro grande benefício desta evolução das URLs diz respeito ao SEO (Search Engine Optimization), onde os buscadores consideram as palavras encontradas na URL para otimizar a pesquisa.
Durante o desenvolvimento do ASP.NET MVC, a Microsoft criou um mecanismo de roteamento capaz de mapear URLs quaisquer para endereços dentro do servidor, sejam eles físicos, através do MapPageRoute (que discutiremos na parte 2 deste texto) ou virtuais, pelo método MapRoute. Esta ferramenta, a princípio, seria uma funcionalidade própria do framework MVC. O mecanismo é capaz de interpretar a requisição (URL) que está chegando pelo navegador e, baseado em uma tabela de regras, responder com o arquivo requisitado caso a regra registrada aponte para um endereço físico, ou o serviço, a classe e o método a ser executado caso a regra mapeie para um endereço virtual. Mas este recurso se mostrou tão útil que, antes mesmo do lançamento oficial do ASP.NET MVC, a Microsoft fez com que ele fosse desacoplado e levado para o core do ASP.NET. Com isso, o roteamento passou a ser utilizado tanto pelo ASP.NET MVC, quanto pelos Web Forms e também pelo ASP.NET Web API. (bem cm)
<div id="toc_container" class="toc_white no_bullets">Sum&aacute;rio<ul class="toc_list"><li><a href="#Mas-como-funciona-essa-tabela-de-rotas">1 Mas como funciona essa tabela de rotas?</a></li><li><a href="#Exemplificando">2 Exemplificando:</a><ul><li><ul><li><ul><li><a href="#Por-Daniel-Prata-e-Jose-Vicente">2.0.0.1 Por: Daniel Prata e José Vicente</a></li><li><a href="#Revisao-Jessica-Saliba">2.0.0.2 Revisão: Jéssica Saliba</a></li></ul></li></ul></li></ul></li></ul></div>
<h2>Mas como funciona essa tabela de rotas?</h2>
Quando você roda uma aplicação pela primeira vez, ela lança um evento denominado Application_start(), definido no arquivo Global.asax. É no código deste evento que o método de criação da tabela de rotas, dentre outros, é invocado.
&nbsp;
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan1.png"><img fetchpriority="high" decoding="async" class="size-full wp-image-336 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan1.png" alt="dan1" width="310" height="369" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan1.png 310w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan1-252x300.png 252w" sizes="(max-width: 310px) 100vw, 310px" /></a>
&nbsp;
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan2.png"><img decoding="async" class="size-full wp-image-337 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan2.png" alt="dan2" width="602" height="259" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan2.png 602w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan2-300x129.png 300w" sizes="(max-width: 602px) 100vw, 602px" /></a>
&nbsp;
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan3.png"><img decoding="async" class="size-full wp-image-338 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan3.png" alt="dan3" width="602" height="259" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan3.png 602w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/09/dan3-300x129.png 300w" sizes="(max-width: 602px) 100vw, 602px" /></a>
No método acima definimos o esquema de roteamento padrão que será utilizado pela nossa aplicação. De acordo com ele, estamos dizendo a ela que toda requisição que chegar através da URL deverá ser traduzida da seguinte forma: 
O primeiro segmento indica qual o Controller, o segundo segmento informa qual Action deste Controller deve ser chamada e o terceiro segmento, se informado, aponta o identificador do recurso acessado nesta Action. Além disso, definimos quais os valores padrão que os segmentos deverão assumir caso não sejam informados pelos usuários.
<h2>Exemplificando:</h2>
Lembram da sintaxe que foi mostrada logo no começo do texto? Para evitar que você volte lá no início, vamos dar uma forcinha e mostra-la aqui novamente: [scheme]://[host]:[port]/[path][?query]. É no fragmento [path] que estamos interessados aqui.
Agora imaginem que é feita a seguinte entrada no browser:  <a style="color: #808080;" href="http://suaaplicacao.com/admin/listarUsuarios">http://suaaplicacao.com/admin/listarUsuarios</a>.
Note que o primeiro segmento do ‘path’ contém a palavra ‘admin’ e o segundo segmento contém a palavra ‘listarUsuarios’. Sendo assim, de acordo com a regra que definimos na nossa rota padrão, nossa aplicação vai tentar encontrar a Action ‘listarUsuarios’ no Controller ‘adminController’.
Ainda considerando a regra padrão, o usuário poderia também fazer a seguinte chamada: <a style="color: #808080;" href="http://suaaplicacao.com/admin/listarUsuarios/345">http://suaaplicacao.com/admin/listarUsuarios/345</a>. Neste caso, a aplicação deverá mapear o terceiro segmento para o ‘ID’ do usuário a ser listado na Action ‘listarUsuarios’ do Controller ‘adminController’.
Explorando os valores padrão desta rota, se um determinado usuário fizesse a seguinte chamada: <a style="color: #808080;" href="http://suaaplicacao.com/">http://suaaplicacao.com</a>, a aplicação deveria mapear a entrada para a Action ‘Index’ do Controller ‘HomeController’, obedecendo aos valores ‘default’ definidos.
Por fim, se o usuário fizesse a chamada <a style="color: #808080;" href="http://suaaplicação.com/admin">http://suaaplicação.com/admin</a>, o serviço de rotas deveria mapear para a ação “Index” do controlador “adminController”, preenchendo a parte que foi passada pela requisição com seu valor e assumindo o valor padrão para as demais partes.
Certo, você deve ter entendido por que sua aplicação funciona da forma que funciona. A rota padrão do ASP.NET MVC define um mapeamento virtual, ou seja, ela não leva as URLs para arquivos físicos do sistema e sim para ações, métodos de controladores. Todas as URLs mágicas que redirecionam para o lugar certo, dependendo apenas dos nomes de seus controladores e ações, são possíveis com somente a rota padrão.
Entender como funciona é legal, é claro, mas agora você deve estar interessado em mais uma coisa: como eu utilizo esta ferramenta do meu jeito? Como eu faço para decidir para onde as URLs serão mapeadas? Para aprendermos isto, basta dar uma olhada aqui na <a style="color: #ff6600;" href="https://dtidigital.com.br/blog/rotas-em-asp-net-mvc-parte-2-roteamento-personalizado/">segunda parte</a>.
<h5 style="text-align: justify;">Por: Daniel Prata e José Vicente</h5>
<h5 style="text-align: justify;">Revisão: Jéssica Saliba</h5>

Rotas em ASP.NET MVC

Desbloqueie o futuro do seu negócio

Confira outros artigos