Ik probeer een API-controller te laten werken in een ASP.NET MVC 4-webapp. Elk verzoek resulteert echter in een 404en ik ben stomverbaasd. :/
Ik heb de standaard API-controllerroute van de projectsjabloon gedefinieerd als:
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
De registratie wordt aangeroepen in Global.asax:
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
// Register API routes
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
}
Ik heb een standaard API-controller zoals deze:
namespace Website.Controllers
{
public class FavoritesController : ApiController
{
// GET api/<controller>
public IEnumerable<string> Get()
{
return new [] { "first", "second" };
}
// PUT api/<controller>/5
public void Put(int id)
{
}
// DELETE api/<controller>/5
public void Delete(int id)
{
}
}
}
Als ik nu naar localhost:59900/api/Favoritesblader, verwacht ik dat de Get-methode wordt aangeroepen, maar in plaats daarvan krijg ik een 404statuscode en het volgende antwoord:
<Error>
<Message>
No HTTP resource was found that matches the request URI 'http://localhost:59900/api/Favorites'.
</Message>
<MessageDetail>
No type was found that matches the controller named 'Favorites'.
</MessageDetail>
</Error>
Alle hulp wordt zeer op prijs gesteld, ik word hier een beetje gek. 🙂 Bedankt!
Antwoord 1, autoriteit 100%
Eén ding waar ik tegenaan liep, was dat mijn configuraties in de verkeerde volgorde waren geregistreerd in mijn GLobal.asax-bestand, bijvoorbeeld:
Juiste volgorde:
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
Verkeerde bestelling:
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
WebApiConfig.Register(GlobalConfiguration.Configuration);
Ik zeg alleen dat dit mijn probleem was en het wijzigen van de volgorde ligt voor de hand, maar wordt soms over het hoofd gezien en kan veel frustratie veroorzaken.
Antwoord 2, autoriteit 11%
Had in wezen hetzelfde probleem, in mijn geval opgelost door toe te voegen:
<modules runAllManagedModulesForAllRequests="true" />
naar de
<system.webServer>
</system.webServer>
sectie van web.config
Antwoord 3, autoriteit 9%
Ik heb aan een soortgelijk probleem gewerkt en het kostte me eeuwen om het probleem te vinden. Het is niet de oplossing voor dit specifieke bericht, maar hopelijk zal het toevoegen van dit iemand wat tijd besparen bij het proberen het probleem te vinden wanneer ze zoeken naar waarom ze mogelijk een 404-fout voor hun controller krijgen.
Eigenlijk had ik ‘Controller’ verkeerd gespeld aan het einde van mijn klasnaam. Zo simpel is het!
Antwoord 4, autoriteit 7%
Volgende regel toevoegen
GlobalConfiguration.Configure(WebApiConfig.Register);
in Application_Start()functie in Global.ascx.csbestand.
Antwoord 5, autoriteit 5%
Ik had hetzelfde probleem, toen kwam ik erachter dat ik dubbele api-controllerklassenamen had in een ander project en ondanks het feit dat de “routePrefix”en de naamruimte en projectnaam anders waren, maar toch waren ze 404 geretourneerd, ik heb de klassennamen gewijzigd en het werkte.
Antwoord 6, autoriteit 4%
Vergelijkbaar probleem met een beschamend eenvoudige oplossing – zorg ervoor dat uw API-methoden publiczijn. Als u een modifier voor methodetoegang weglaat, wordt ook een HTTP 404 geretourneerd.
Zal 404 retourneren:
List<CustomerInvitation> GetInvitations(){
Wordt uitgevoerd zoals verwacht:
public List<CustomerInvitation> GetInvitations(){
Antwoord 7, autoriteit 2%
Maak een Route-kenmerk voor uw methode.
voorbeeld
[Route("api/Get")]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
Je kunt zo bellen http://localhost/api/Get
Antwoord 8
Ik ben een beetje stomverbaasd, ik weet niet zeker of dit te wijten was aan een probleem met de HTTP-outputcaching.
Hoe dan ook, “het begon ineens goed te werken”. :/ Dus het bovenstaande voorbeeld werkte zonder dat ik iets toevoegde of veranderde.
De code moest een nachtje wachten en koken… 🙂
Bedankt voor het helpen, jongens!
Antwoord 9
Om voor mij onduidelijke redenen had ik al mijn Methoden/Acties als statisch gedeclareerd – blijkbaar werkt het niet als je dit doet. Zet dus gewoon de staticuit
[AllowAnonymous]
[Route()]
public static HttpResponseMessage Get()
{
return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
}
Werd:-
[AllowAnonymous]
[Route()]
public HttpResponseMessage Get()
{
return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
}
Antwoord 10
Heb dit probleem gehad. Moest Precompile during publishinguitschakelen.
Antwoord 11
Controleer of als uw controllerklasse het kenmerk [RoutePrefix(“somepath”)] heeft, alle controllermethoden ook een kenmerkset [Route()] hebben.
Ik ben dit probleem ook tegengekomen en zat al een tijdje aan mijn hoofd te krabben.
Antwoord 12
Ik ga mijn oplossing hier toevoegen omdat ik persoonlijk een hekel heb aan degenen die de web.config bewerken zonder uit te leggen wat er aan de hand is.
Voor mij was het hoe de standaard Handler Mappings zijn ingesteld in IIS. Om dit te controleren…
- IIS-beheer openen
- Klik op het hoofdknooppunt van uw server (meestal de naam van de server)
- Open “Handler-toewijzingen”
- Klik onder Acties in het rechterdeelvenster op “Geordende lijst weergeven”
Dit is de volgorde van handlers die een verzoek verwerken. Als die van jou hetzelfde zijn als de mijne, bevinden de handlers “ExtensionlessUrlHandler-*” zich allemaal onder de StaticFile-handler. Nou, dat gaat niet werken omdat de StaticFile-handler een wildcard van * heeft en een 404 retourneert voordat hij zelfs maar bij een extensieloze controller komt.
Dus door dit te herschikken en de “ExtensionlessUrlHandler-*” boven de wildcard-handlers van TRACE, OPTIONS en StaticFile te plaatsen, wordt de Extensionless-handler als eerste geactiveerd en zouden uw controllers, in elke website die in het systeem wordt uitgevoerd, correct moeten reageren.
Opmerking:
Dit is eigenlijk wat er gebeurt als je de modules in de web.config verwijdert en toevoegt, maar één plek om het voor alles op te lossen. En er is geen extra code voor nodig!
Antwoord 13
WebApiConfig.Register(GlobalConfiguration.Configuration);
Moet de eerste zijn in het App_start-evenement. Ik heb het geprobeerd op de laatste positie in het APP_start-evenement, maar dat werkte niet.
Antwoord 14
Voeg dit toe aan <system.webServer>in uw web.config:
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
<remove name="OPTIONSVerbHandler"/>
<remove name="TRACEVerbHandler"/>
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"/>
</handlers>
Het toevoegen van <modules runAllManagedModulesForAllRequests="true" />werkt ook, maar wordt niet aanbevolen vanwege prestatieproblemen.
Antwoord 15
Ik heb een soortgelijk probleem opgelost door met debugger aan de init van de toepassing te koppelen. Start gewoon de webserver (bijvoorbeeld toegang tot localhost), koppel aan w3wp en kijk of de app-initialisatie correct is voltooid. In mijn geval was er een uitzondering en waren controllers niet geregistreerd.
Antwoord 16
Ik had hetzelfde 404-probleem en geen van de oplossingen die hier werden gestemd, werkte. In mijn geval heb ik een subtoepassing met zijn eigen web.config en ik had een duidelijke tag in de httpModules web.config-sectie van de ouder. In IIS zijn alle web.config-instellingen van de ouder van toepassing op de subtoepassing.
<system.web>
<httpModules>
<clear/>
</httpModules>
</system.web>
De oplossing is om de tag ‘clear’ te verwijderen en eventueel inheritInChildApplications=”false” toe te voegen in de web.config van de ouder. De inheritInChildApplications is voor IIS om de configuratie-instellingen niet toe te passen op de subtoepassing.
<location path="." inheritInChildApplications="false">
<system.web>
....
<system.web>
</location>
Antwoord 17
Ik heb tientallen installaties van mijn app met verschillende clients die allemaal goed werkten en deze keerde gewoon altijd 404 terug bij alle API-aanroepen. Het bleek dat toen ik de toepassingsgroep in IIS voor deze client maakte, deze standaard naar .net Framework 2.0 in plaats van 4.0 ging en ik heb het gemist. Dit veroorzaakte de 404-fout. Volgens mij had dit een 500 error moeten zijn. Zeer misleidende Microsoft!
Antwoord 18
Ik had dit probleem: mijn Web API 2-project op .NET 4.7.2 werkte zoals verwacht, daarna wijzigde ik de projecteigenschappen om een ​​specifiek paginapad te gebruiken op het tabblad Web. Toen ik het sindsdien elke keer uitvoerde, kreeg ik een 404-fout – het raakte niet eens de controller.
Oplossing: ik vond de verborgen map .vs in mijn bovenliggende map van mijn VS-oplossingsbestand (soms dezelfde map) en verwijderde deze. Toen ik mijn VS-oplossing nogmaals opende, opschonde en opnieuw opbouwde met de optie Opnieuw opbouwen, werkte hij weer. Er is een probleem opgetreden met de bestanden in de cache die zijn gemaakt door Visual Studio. Toen deze werden verwijderd en de oplossing opnieuw werd opgebouwd, werden de bestanden opnieuw gemaakt.
Antwoord 19
Als u de IIS beheert en u bent degene die een nieuwe site moet maken, controleer dan de “Applicatiepool” en zorg ervoor dat de CLR-versie moet worden geselecteerd. In mijn situatie was het geselecteerd “Geen beheerde code”. Na wijziging naar v4.0 begon het te werken.