Torniamo a parlare di Attribute Routing, la nuova opportunità per definire regole di routing con applicazioni ASP.NET MVC 5 e WebAPI 2. In un nostro precedente script (https://www.aspitalia.com/script/1145/Scrivere-Route-REST-Attribute-Routing-ASP.NET-MVC-ASP.NET-Web.aspx) abbiamo introdotto l'uso puntuale degli attributi RoutePrefix e Route sulle nostre action, come strumento per progettare URL che seguano un preciso ordine gerarchico.
Ma è importante valutare l'Attribute Routing anche dal punto di vista prestazionale e della sensibilità al contesto. Vediamo subito l'esempio di una ipotetica action che consenta la ricerca di clienti per partita IVA.
[RoutePrefix("api/clienti/")] public class ClientiController : ApiController { [HttpGet, Route("{partitaIva}")] public Cliente TrovaClientePerPartitaIva(string partitaIva) { ... } }
Con la regola di routing che abbiamo appena definito, ogni richiesta rivolta a /api/clienti/{partitaIva} verrà affidata all'action TrovaClientePerPartitaIva. Questo non è sempre desiderabile per una questione di efficienza: infatti la nostra action andrebbe in esecuzione anche se l'utente fornisse valori non numerici, o comunque sintatticamente non validi per una partita IVA.
Come rimedio, l'Attribute Routing ci consente di definire dei route constraints per ciascun parametro, ovvero dei vincoli di conformità del dato che vengono valutati prima ancora che l'action venga scelta ed eseguita.
Un route constraint va posto immediatamente dopo il nome del parametro a cui si riferisce, con un carattere ":" di separazione. Nel nostro caso, possiamo aggiungere una combinazione di due route constraint al parametro {partitaIva}.
[RoutePrefix("api/clienti/")] public class ClientiController : ApiController { [HttpGet, Route("{partitaIva:length(11):long}")] public Cliente TrovaClientePerPartitaIva(string partitaIva) { ... } }
In questo modo imponiamo che la partita iva sia una stringa di 11 caratteri di lunghezza e che sia anche interpretabile come numero intero poiché composta da sole cifre.
ASP.NET Web API 2 asseconda le esigenze più comuni offrendo un nutrito insieme di vincoli:
- Sul tipo, che impongono la convertibilità del valore verso determinati tipi CLR come: int, long, decimal, float, bool, datetime e guid;
- Sui caratteri consentiti, come alpha, che impone la presenza delle sole lettere dalla A alla Z o regex per sfruttare le regular expression;
- Sulla dimensione, come min, max e range per indicare gli estremi di valori numerici o minlength, maxlength e length che invece riguardano le stringhe e la loro lunghezza.
Tuttavia, ciò potrebbe non essere sufficiente ad operare un controllo formale completo sul valore inviato dall'utente. In un prossimo script vedremo come creare un nostro validatore personalizzato.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Disabilitare automaticamente un workflow di GitHub
Eseguire una GroupBy per entity in Entity Framework
Eseguire attività pianificate con Azure Container Jobs
Ottimizzare la latenza in Blazor 8 tramite InteractiveAuto render mode
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Generare token per autenicarsi sulle API di GitHub
Creazione di componenti personalizzati in React.js con Tailwind CSS
Eseguire operazioni con timeout in React
Creare moduli CSS in React
C# 12: Cosa c'è di nuovo e interessante
Usare un KeyedService di default in ASP.NET Core 8
Specificare il versioning nel path degli URL in ASP.NET Web API
I più letti di oggi
- Miglioramenti nelle performance di Angular 16
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- HTML5 con CSS e JavaScript
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)