Hace algunas semanas vimos cómo crear inline route constraints, o restricciones de ruta en línea en ASP.NET Core, y creamos un ejemplo simple que permitía al sistema de routing detectar si el valor suministrado a través de un parámetro de ruta era una palabra palíndroma.
Para ello, creamos la restricción "palindrome" que, implementada en la clase PalindromeConstraint podíamos usar de la siguiente forma:
// Uso en minimal API:
app.MapGet("/test/{str:palindrome}", (string str) => $"{str} is palindrome");
// Uso en MVC:
public class TestController : Controller
{
[HttpGet("/test/{str}")]
public string Text(string str) => $"{str} is palindrome";
}
Sin embargo, si atendemos a la lista de restricciones disponibles de serie en ASP.NET Core, vemos que hay algunas de ellas que son parametrizadas, como maxlength o range:
| Plantilla de ruta | Significado |
|---|---|
/order/{orderId:minlength(5) |
orderId debe tener como mínimo 5 caracteres |
/setAge/{age:int:range(0,120) |
age debe ser un entero entre 0 y 120 |
En este post vamos a ver precisamente eso, cómo crear una restricción personalizada con parámetros.
Las inline route constraints, o restricciones de ruta en línea son un interesante mecanismo de ASP.NET Core para especificar condiciones sobre los parámetros definidos en el interior de los patrones de ruta.
Por ejemplo, una acción MVC o un endpoint mapeado usando el patrón /product/{id}, será ejecutado cuando entren peticiones hacia las rutas /product/1 y product/xps-15.
Sin embargo, si en el momento del mapeo utilizamos el patrón /product/{id:int} estaremos indicando que el manejador sólo debe ser ejecutado cuando el valor del parámetro id sea un entero.
Esto podemos verlo mejor en un ejemplo. Observad la definición de la siguiente acción MVC, que será ejecutada sólo si el valor para el parámetro id es un entero, es decir, responderá a peticiones como /product/1 o /product/234, pero será ignorada si la petición entrante se dirige a la ruta /product/xps-15:
public class ProductController : Controller
{
...
[HttpGet("product/{id:int}")]
public async Task<ActionResult<Product>> ShowDetails(int id)
{
var product = ... // Obtener producto
return product != null ? product: NotFound();
}
}
O lo que sería su equivalente usando las minimal APIs introducidas en .NET 6:
app.MapGet("/product/{id:int}", async (int id) =>
{
var product = await new ProductCatalog().GetByIdAsync(1); // Obtener producto
return product != null ? Results.Ok(product) : Results.NotFound();
});
Como ya habréis adivinado, en
{id:int}es donde estamos especificando que el parámetro de rutaiddebe ser entero.
Pues continuamos profundizando en el sistema de rutado por atributos, o attribute routing, recientemente incluido en ASP.NET MVC y Web API. Si aún no conoces este mecanismo, te recomiendo que eches un vistazo a los dos artículos anteriores de la serie:Como vimos en el último post, en las rutas es posible incluir restricciones a los parámetros de entrada, de forma que si las condiciones especificadas no se cumplen, el sistema de routing descartará la regla y continuará buscando en la tabla de rutas una entrada que encaje con la petición entrante.
Así, la acción
Confirm() mostrada a continuación no será invocada ante peticiones como “/user/confirm/1234” o “/user/confirm/abcdef”:[Route("user/confirm/{pin:alpha:length(4}"] // 4 alphabet chars (a-z)
public ActionResult Confirm(string pin)
{
...
}
Y como también veíamos en el post anterior, MVC y Web API traen de serie un buen número de restricciones (alpha, bool, decimal, int, length, etc.) que podemos emplear directamente sobre nuestras rutas, pero, lo que es mejor, se trata nuevamente de un mecanismo extensible: podemos crear nuestras propias restricciones para attribute routing sin demasiado esfuerzo.
En la entrega anterior de la serie hicimos una pequeña introducción al attribute routing introducido en ASP.NET MVC 5 y Web API 2, explicando cómo podíamos activar esta característica y las reglas básicas para la definición de rutas sobre acciones y controladores de ambos frameworks.En esta ocasión vamos a ver cómo podemos incluir restricciones o constraints en dichas rutas, algo que podíamos conseguir también utilizando el rutado por convenciones pero de forma más farragosa y que ahora con attribute routing y otras mejoras incluidas en las últimas versiones de MVC y Web API se convierte en trivial.
Y ya de paso, repasaremos lo que son las restricciones de ruta y cómo podíamos usarlas en versiones anteriores de MVC y Web API, para que aquellos que aún no hayáis tenido oportunidad de trabajar con ellas.
Como seguro sabéis, una de las novedades que acompañan a MVC 5 es la inclusión de un nuevo mecanismo para la definición de rutas llamado attribute routing, que básicamente consiste en acercar el registro de rutas a las acciones y controladores que las utilizan en lugar de definirlas en el tradicional y lejano RouteConfig.cs.
