J'essaie de faire fonctionner un contrôleur API dans une application Web ASP.NET MVC 4. Cependant, chaque requête entraîne un 404 et je suis perplexe. : /
J'ai la route du contrôleur API standard à partir du modèle de projet défini comme:
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
L'enregistrement est appelé dans Global.asax:
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
// Register API routes
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
}
J'ai un contrôleur d'API de base comme ceci:
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)
{
}
}
}
Maintenant, lorsque je navigue sur localhost: 59900/api/Favoris Je m'attends à ce que la méthode Get soit appelée, mais j'obtiens un code de statut 404 et la réponse suivante:
<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>
Toute aide serait grandement appréciée, je perds la tête un peu par ici. :) Merci!
Une des choses que j’ai rencontrée a été d’enregistrer mes configurations dans le mauvais ordre dans mon fichier GLobal.asax, par exemple:
Dans le bon ordre:
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
Mauvais ordre:
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
WebApiConfig.Register(GlobalConfiguration.Configuration);
Cela dit, c’était mon problème et changer l’ordre est évident, mais parfois négligé et peut causer beaucoup de frustration.
Avait essentiellement le même problème, résolu dans mon cas en ajoutant:
<modules runAllManagedModulesForAllRequests="true" />
au
<system.webServer>
</system.webServer>
section de web.config
Ajouter la ligne suivante
GlobalConfiguration.Configure(WebApiConfig.Register);
dans Application_Start()
fonction dans Global.ascx.cs fichier.
J'ai travaillé sur un problème similaire à celui-ci et il m'a fallu beaucoup de temps pour le trouver. Ce n'est pas la solution pour ce poste en particulier, mais j'espère que cela permettra à quelqu'un d'économiser du temps à essayer de trouver le problème alors qu'il cherche à savoir pourquoi il risque d'obtenir une erreur 404 pour son contrôleur.
Fondamentalement, j'avais mal orthographié "Controller" à la fin du nom de ma classe. Aussi simple que cela!
Créez un attribut Route pour votre méthode.
exemple
[Route("api/Get")]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
Vous pouvez appeler comme ceci http: // localhost/api/Get
J'ai eu le même problème, puis j'ai découvert que j'avais des noms de classes de contrôleurs d'API en double dans un autre projet et malgré le fait que le "routePrefix" et l'espace de noms et le nom du projet étaient différents, noms de classe et cela a fonctionné.
Problème similaire avec une solution simple et embarrassante - assurez-vous que vos méthodes API sont public
Si vous laissez n'importe quel modificateur d'accès à une méthode, vous obtiendrez également un HTTP 404.
retournera 404:
List<CustomerInvitation> GetInvitations(){
Exécute comme prévu:
public List<CustomerInvitation> GetInvitations(){
Je suis un peu perplexe, je ne suis pas sûr que cela soit dû à un problème de cache de sortie HTTP.
Quoi qu'il en soit, "tout à coup, cela a commencé à fonctionner correctement". :/Ainsi, l'exemple ci-dessus a fonctionné sans que j'ajoute ou modifie quoi que ce soit.
Devinez, le code vient de s'asseoir et de cuisiner du jour au lendemain ... :)
Merci d'avoir aidé, les gars!
Pour des raisons qui ne me semblent pas claires, j'avais déclaré que toutes mes méthodes/actions étaient statiques - apparemment, si vous le faites, cela ne fonctionne pas. Alors laissez tomber la static
[AllowAnonymous]
[Route()]
public static HttpResponseMessage Get()
{
return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
}
Est devenu:-
[AllowAnonymous]
[Route()]
public HttpResponseMessage Get()
{
return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
}
Je vais ajouter ma solution ici parce que je déteste personnellement ceux qui modifient le fichier web.config sans expliquer ce qui se passe.
Pour moi, c’est ainsi que les mappages de gestionnaires par défaut sont définis dans IIS. Pour vérifier cela ...
C'est l'ordre des gestionnaires qui traitent une demande. Si les vôtres sont comme les miens, les gestionnaires "ExtensionlessUrlHandler- *" sont tous situés sous le gestionnaire StaticFile. Cela ne fonctionnera pas, car le gestionnaire StaticFile a un caractère générique * et renverra un 404 avant même d’avoir un contrôleur sans extension.
Par conséquent, si vous réorganisez cette opération et déplacez "ExtensionlessUrlHandler- *" au-dessus des gestionnaires génériques de TRACE, OPTIONS et StaticFile, le gestionnaire Extensionless sera activé en premier et devrait permettre à vos contrôleurs, quel que soit le site Web du système, de répondre correctement.
Remarque: C’est essentiellement ce qui se produit lorsque vous supprimez et ajoutez les modules dans le fichier web.config, mais qu’un seul endroit pour le résoudre pour tout. Et cela ne nécessite pas de code supplémentaire!
Avait ce problème. A dû décocherPrecompile during publishing
.
J'ai résolu le même problème en joignant avec le débogueur à l'application init. Démarrez simplement le serveur Web (par exemple, accédez à localhost), attachez-le à w3wp et voyez, si l'initialisation de l'application s'est terminée correctement Dans mon cas, il y avait une exception et les contrôleurs n'étaient pas enregistrés.
WebApiConfig.Register(GlobalConfiguration.Configuration);
Doit être le premier dans l'événement App_start. Je l'ai essayé à la dernière position dans l'événement APP_start, mais cela n'a pas fonctionné.
Vérifiez que si votre classe de contrôleur a l'attribut [RoutePrefix ("somepath")], toutes les méthodes de contrôleur ont également un attribut [Route ()].
J'ai aussi rencontré ce problème et je me suis égratigné la tête pendant un certain temps.
Ajoutez ceci à <system.webServer>
dans votre 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>
L'ajout de <modules runAllManagedModulesForAllRequests="true" />
fonctionne également, mais n'est pas recommandé en raison de problèmes de performances.
J'ai eu le même problème 404 et aucune des solutions favorisées ici n'a fonctionné. Dans mon cas, j'ai une sous-application avec son propre web.config et j'avais une balise claire dans la section httpModules web.config du parent. Dans IIS, tous les paramètres web.config du parent s'appliquent à la sous-application.
<system.web>
<httpModules>
<clear/>
</httpModules>
</system.web>
La solution consiste à supprimer la balise 'clear' et éventuellement à ajouter inheritInChildApplications = "false" dans le fichier web.config du parent. InheritInChildApplications est pour IIS ne pas appliquer les paramètres de configuration à la sous-application.
<location path="." inheritInChildApplications="false">
<system.web>
....
<system.web>
</location>