L'instradamento webapi2 basato su attributi restituisce 404 per alcuni metodi

Question

Attualmente sto lavorando a un progetto che è stato aggiornato a Webapi2 da Webapi. Parte della conversione include il passaggio all'utilizzo del routing basato su attributi.

Sono opportunamente configurazione miei percorsi in Global.asax (come segue)

GlobalConfiguration.Configure(config => config.MapHttpAttributeRoutes()); 

e rimosso dalla configurazione di routing precedente.

ho decorato tutti i miei controllori API con l'appropriato System.Web.Http.RouteAttribute e System.Web.Http.RoutePrefixAttribute attributi.

Se ispeziono System.Web.Http.GlobalConfiguration.Configuration.Routes con il debugger, posso vedere che tutti i percorsi previsti sono registrati nella raccolta. Allo stesso modo, i percorsi appropriati sono disponibili all'interno della documentazione generata inclusa Webapi Help Page come previsto.

Anche se tutto sembra configurato correttamente, un buon numero di chiamate REST genera una risposta 404 non trovata dal server.

ho trovato alcune somiglianze notevoli specifica per ottenere metodi (questo è tutto quello che ho provato finora)

• Se un metodo accetta 0 parametri che sarà fallire
• Se un percorso override il prefisso è sarà fallire
• Se un metodo prende un parametro di stringa è probabile per avere successo
• ritorno tipo s EEMS avere alcun effetto
• Denominazione di un percorso sembra non avere alcun effetto
• Ordinazione di un percorso sembra non avere alcun effetto
• Rinominare il metodo sottostante sembra non avere effetto

Degno di nota è che il mio I controller API appaiono in un'area separata, ma dato che alcuni percorsi funzionano, non mi aspetto che questo sia il problema in questione.

Esempio di chiamata di metodo non funzionale

[RoutePrefix("api/postman")] 
public class PostmanApiController : ApiController 
{ 
    ... 
    [HttpGet] 
    [Route("all", Name = "GetPostmanCollection")] 
    [ResponseType(typeof (PostmanCollectionGet))] 
    public IHttpActionResult GetPostmanCollection() 
    { 
     return Ok(...); 
    } 
    ... 
} 

mi aspetto che questo sia disponibile tramite http://[application-root]/api/postman/all

È interessante notare che una chiamata a

Url.Link("GetPostmanCollection", null) 

restituirà l'url sopra previsto

Un esempio molto simile di chiamate di metodo all'interno dello stesso controller dove alcuni funzionano e altri no.

[RoutePrefix("api/machine")] 
public class MachineApiController : ApiController 
{ 
    ... 
    [HttpGet] 
    [Route("byowner/{owner}", Name = "GetPostmanCollection")] 
    public IEnumerable<string> GetByOwner([FromUri] string owner) 
    { 
     ... 
    } 
    ... 

    [HttpGet] 
    [Route("~/api/oses/{osType}")] 
    public IEnumerable<OsAndVersionGet> GetOSes([FromUri] string osType) 
    { 
     ... 
    } 
    ... 
} 

Quando un invito a http://[application-root]/api/machineby/ownername riesce e http://[application-root]/api/oses/osType non lo fa.

Sto indagando troppo a lungo, qualche idea su quale potrebbe essere il problema?

Answer 1

Verificare che si configura il HttpConfiguration tramite il metodo MapHttpAttributeRoutes prima qualsiasi ASP.NET MVC registrazione di routing.

In accordo con l'ingresso CodePlex di Microsoft sul Attribute Routing in MVC and Web API le design sezione si afferma:

Nella maggior parte dei casi, MapHttpAttributeRoutes o MapMvcAttributeRoutes sarà chiamato prima in modo che le rotte degli attributi sono registrati prima che i percorsi globali (e quindi avere la possibilità di sostituire le rotte globali). Le richieste di attribuzione di controller instradati verrebbero anche filtrate su solo quelle originate da una route di attributo.

Pertanto, all'interno del Global.asax (o dove la registrazione delle vie aeree) è opportuno chiamare:

GlobalConfiguration.Configure(c => c.MapHttpAttributeRoutes()); // http routes 
RouteTable.Routes.MapRoute(...); // mvc routes 

Answer 2

Nel mio caso si trattava di un errore stupido, sto inviando questo modo che le persone dietro di me fare lo stesso l'errore è stato letto prima che controllino tutto il resto a livello quantico.

Il mio errore è stato, il nome del mio controller non è terminato con la parola Controller.

Felice anno nuovo