Mapeamento distribuído
Nas partes anteriores (se você ainda não viu, veja aqui a <a style="color: #ff9900;" href="http://dtidigital.com.br/blog/rotas-em-asp-net-mvc/" target="_blank" rel="noopener noreferrer">parte 1</a> e a <a style="color: #ff9900;" href="http://dtidigital.com.br/blog/rotas-em-asp-net-mvc-parte-2-roteamento-personalizado/" target="_blank" rel="noopener noreferrer">parte 2</a> desse texto) vimos o que é o mecanismo de rotas do ASP.NET MVC e também como o mecanismo funciona para redirecionar as URLs amigáveis inseridas no navegador para os métodos dos seus controladores. Além disso, descobrimos como fazer com que nossas aplicações web em ASP.NET utilizem rotas personalizadas, ou seja, como fazer com que padrões personalizados de URLs vindos do cliente sejam mapeados para as ações que você desejar.
E então terminamos a segunda parte supondo um cenário: tem outra equipe desenvolvendo o Front-End de uma aplicação paralelamente ao seu desenvolvimento do Back-End. Este Front-End será um cliente do serviço que você está desenvolvendo e eles esperam fazer requisições a URLs específicas para cada método chamado.
Você pode, portanto, utilizar o Web API 2 para desenvolver um serviço REST, por exemplo. Neste caso, poderia criar um novo projeto Web API ou, se for de sua preferência e achar suficiente, pode utilizar seu projeto MVC mesmo, visto que o mecanismo dos controladores dos dois frameworks é semelhante. Para tal, basta apenas garantir que o global.asax possua pelo menos a seguinte linha de código no evento Application_Start e pelo menos a seguinte classe exista na pasta App_Start.
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan10.png"><img fetchpriority="high" decoding="async" class="size-full wp-image-349 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan10.png" alt="dan10" width="602" height="190" /></a>
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan11.png"><img decoding="async" class="size-full wp-image-350 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan11.png" alt="dan11" width="602" height="252" /></a>
Como podemos ver, o Web API também possui um mecanismo de roteamento bastante semelhante ao do ASP.NET MVC, mas lembre-se, ele é definido em um arquivo de configuração diferente.
Voltando ao nosso cenário, temos que fazer com que cada método do seu serviço inteiro, de qualquer controlador, possua cada um sua URL específica. Então, o que você faz? Registra uma rota para cada método? A resposta é: sim!
<h4 style="text-align: justify;">&#8212; Então eu terei uma classe de configuração gigante, com 50 rotas mapeadas no mesmo método?</h4>
A resposta é: não necessariamente. Pode, mas não precisa ser. Observe que o método de registro do WebApiConfig já possui como padrão a linha “config.MapHttpAttributeRoutes”. Isto permite a criação de rotas de forma distribuída, através de atributos utilizados para decorar os controladores e/ou seus métodos.
Ao se decorar um método com o atributo “Route”, define-se para ele uma rota a partir da raiz do servidor. Esta rota possui, de maneira simplificada, todos os elementos da rota registrada através do método MapRoute.
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan12.png"><img decoding="async" class="size-full wp-image-351 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan12.png" alt="dan12" width="602" height="85" /></a>
Por enquanto, vamos ignorar o atributo RoutePrefix e vamos supor que somente o método GetVehiclesInFence possua seu atributo Route. Observe também que a rota possui uma variável com o nome do parâmetro do método, tal qual as variáveis em rotas registradas pelo MapRoute. A primeira diferença é que não é necessário definir um valor para controller e action, visto que o atributo já está na ação a se executar. Assim, chamando “<a style="color: #ff9900;" href="http://suaaplicação.com/10/vehicles">http://suaaplicacao.com/10/vehicles</a>” o método acima seria executado com fenceId = 10 e seu resultado seria retornado ao cliente.
Continuando, se quisermos passar um valor default para as variáveis, basta adicionar o valor com uma sintaxe semelhante a argumentos default em C#. Assim, no exemplo acima, se quisermos que fenceId possua um valor default, poderíamos definir a rota como “{fenceId:int = 10}/vehicles”. No entanto, assim como argumentos default em C#, não seria possível fazer uma chamada a este método utilizando este valor, visto que a variável não é o último elemento da rota. Assim, seria impossível fazer uma requisição a, por exemplo, “<a style="color: #ff9900;" href="http://suaaplicacao.com/vehicles">http://suaaplicacao.com//vehicles</a>”. Isto não mapeia para uma URL válida. Se ajustarmos a rota para “vehicles/{fenceId:int=10}”*, poderíamos chamar “<a style="color: #ff9900;" href="http://suaaplicacao.com/vehicles">http://suaaplicacao.com/vehicles</a>”, e então a requisição seria mapeada para o método GetVehiclesInFence, com o parâmetro fenceId avaliado em 10.
Se quiser que seu valor default seja “UrlParameter.Optional”, basta adicionar o wildcard  ? à variável. Assim, poderíamos aplicar à rota “vehicles/{fenceId:int?}” e mudar o método para receber int? fenceId. Dessa forma, a chamada “<a style="color: #ff9900;" href="http://suaaplicacao.com/vehicles">http://suaaplicacao.com/vehicles</a>” mapearia para a ação GetVehiclesInFence com o parâmetro fenceId = null. Sem o símbolo ?, o parâmetro se tornaria obrigatório e a mesma chamada não seria mapeada para lugar nenhum.
A aplicação de constraints ocorre inline através do símbolo “:”. Nosso exemplo possui um constrint na variável fenceId, indicando que somente valores numéricos inteiros serão aceitos como válidos para o mapeamento da requisição. Na imagem abaixo estão representados os constraints aplicáveis.
<figure id="attachment_352" aria-describedby="caption-attachment-352" style="width: 602px" class="wp-caption aligncenter"><a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan13.png"><img loading="lazy" decoding="async" class="wp-image-352 size-full" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan13.png" alt="dan13" width="602" height="419" /></a><figcaption id="caption-attachment-352" class="wp-caption-text">Fonte: http://blogs.msdn.com/b/webdev/archive/2013/10/17/attribute-routing-in-asp-net-mvc-5.aspx</figcaption></figure>
&nbsp;
Há ainda o atributo RoutePrefix aplicável a um controlador. Este atributo define um prefixo para qualquer chamada a uma ação daquele controlador. Assim, no nosso exemplo, para efetivamente chamar o método GetVehiclesInFence, devemos utilizar a URL “<a style="color: #ff9900;" href="http://suaaplicacao.com/fences/10/vehicles">http://suaaplicacao.com/fences/10/vehicles</a>”. Qualquer outro método definido dentro do controlador Fences será mapeado a partir do endereço “<a style="color: #ff9900;" href="http://suaaplicacao.com/fences/">http://suaaplicacao.com/fences/</a>”.
Pode-se também aplicar o atributo Route à classe controlador. Para tal, é necessário que a rota possua uma variável “{action}”, podendo este ter um valor default para o caso de nenhum ser inserido. Com isso é possível aplicar um método padrão ao controlador, que assim, se somente o prefixo do controlador estiver presente na requisição, sem qualquer outra especificação de ação, o valor default de action é avaliado e o método de nome correspondente é chamado.
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan14.png"><img loading="lazy" decoding="async" class="size-full wp-image-353 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan14.png" alt="dan14" width="602" height="110" /></a>
Por fim, o mesmo tipo de roteamento distribuído por atributos é aplicável aos controladores ASP.NET MVC. Os atributos decoram as classes e métodos da exata mesma forma e para que o mapeamento ocorra adequadamente, deve-ser adicionar a linha “routes.MapMvcAttributeRoutes()” ao método RegisterRoutes da classe RouteConfig.
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/09/dan15.png"><img loading="lazy" decoding="async" class="size-full wp-image-354 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/09/dan15.png" alt="dan15" width="602" height="188" /></a>
E com isto aprendemos como mapear nossas URLs específicas, amigáveis e totalmente independentes dos nomes das nossas classes e métodos para os locais que desejarmos. Agora o poder está em suas mãos, você tem o controle sobre os endereços pelos quais seus usuários navegarão, crie suas aplicações e serviços com responsabilidade.
* Importante manter o valor default na rota sem espaços.
<h5></h5>
<h5>Por: Daniel Prata e José Vicente</h5>
<h5>Revisão: Jéssica Saliba</h5>

Rotas em ASP.NET MVC – PARTE 3 – Mapeamento distribuído

Desbloqueie o futuro do seu negócio

Mais conteúdos como esse

Travessa Dona Zilda, 125, sala 203, São Gonçalo – Pelotas, RS. CEP: 96075-166

14841 Dallas Parkway, 8th Floor Addison, TX 75254

R. Levindo Lopes, 357, 5º e 12º Andar – Savassi, Belo Horizonte MG, 30112-010