Abbiamo visto come il framework sfrutti il meccanismo di routing di ASP.NET ed una serie di convenzioni per individuare il controller di una risorsa ed il metodo da eseguire senza particolari configurazioni. Può essere utile però in certi casi avere la possibilità di andare oltre le convenzioni predefinite e personalizzare il modo in cui mettere in relazione URI, risorse, metodi HTTP e metodi di classe.
Ad esempio, per quanto riguarda la struttura degli URI, abbiamo visto che il sistema propone la struttura predefinita:
/api/{controller}/{id}Il fatto che venga proposto il prefisso /api per gli URI delle nostre Web API è motivato soltanto dalla necessità di evitare collisioni con il routing standard in un progetto ASP.NET MVC. Se nel nostro progetto implementeremo esclusivamente Web API possiamo benissimo modificare lo schema eliminando la parte /api o sostituendola con quello che ci pare.
Se invece non vogliamo sfruttare la convenzione secondo cui ad un metodo HTTP viene fatto corrispondere un metodo del controller che inizia con lo stesso nome, possiamo far ricorso agli attributi HttpGet, HttpPost, HttpPut e HttpDelete.
Ad esempio, possiamo mappare a GET il metodo FindItemByTerm() in questo modo:
[HttpGet]
public Item FindItemByTerm(string id)
{
...
}Abbiamo anche la possibilità di associare più metodi HTTP allo stesso metodo di un controller, come nel seguente esempio:
[AcceptVerbs("GET", "HEAD")]
public Item FindItemByTerm(string id)
{
...
}In questo casi verrà eseguito il metodo FindItemByTerm() sia quando il client invia una richiesta HTTP con metodo GET sia quando viene specificato il metodo HEAD. Come si può intuire dall'esempio, oltre a superare le convenzioni, l'attributo AccetpVerbs può essere utilizzato per mappare metodi HTTP diversi dai quattro principali.
