ASP.NET Web Api: La ressource demandée ne supporte pas la méthode http 'GET'

Question

J'ai l'action suivante sur un ApiController:

public string Something()
{
    return "valeur";
}

Et j'ai configuré mes routes comme suit:

routes.MapHttpRoute(
    name: "DefaultApi",
    routeTemplate: "api/{controller}/{action}/{id}",
    defaults: new { id = RouteParameter.Optional }
);

Dans la version bêta, cela fonctionnait très bien, mais je viens de passer à la dernière version candidate et maintenant je rencontre des erreurs sur des appels comme celui-ci:

La ressource demandée ne prend pas en charge la méthode http 'GET'.

Pourquoi cela ne fonctionne-t-il plus?

(Je suppose que je pourrais me débarrasser de {action} et simplement créer beaucoup de contrôleurs, mais cela semble désordonné.)

Answer 1

Si vous n'avez pas configuré de HttpMethod sur votre action dans le contrôleur, il est supposé être seulement HttpPost en RC. En Beta, il est supposé prendre en charge toutes les méthodes - GET, PUT, POST et Delete. Il s'agit d'un petit changement de beta à RC. Vous pourriez facilement décorer plus d'une méthode HTTP sur votre action avec [AcceptVerbs("GET", "POST")].

Answer 2

Toutes les informations ci-dessus sont correctes, j'aimerais également souligner que l'annotation [AcceptVerbs() ] existe à la fois dans les espaces de noms System.Web.Mvc et System.Web.Http.

Vous voulez utiliser le System.Web.Http s'il s'agit d'un contrôleur API Web.

Answer 3

Bien que cela ne soit pas une réponse à la question d'origine, j'ai eu exactement la même erreur pour une cause complètement différente ; donc au cas où cela aiderait quelqu'un d'autre...

Le problème pour moi était un paramètre de méthode incorrectement nommé, ce qui a conduit WebAPI à router la demande de manière inattendue. J'ai les méthodes suivantes dans mon ProgrammeController :

[HttpGet]
public Programme GetProgrammeById(int id)
{
    ...
}

[HttpDelete]
public bool DeleteProgramme(int programmeId)
{
    ...
}

Les demandes DELETE vers .../api/programmes/3 n'étaient pas routées vers DeleteProgramme comme je m'y attendais, mais vers GetProgrammeById, car DeleteProgramme n'avait pas un paramètre nommé id. GetProgrammeById rejetait ensuite bien sûr le DELETE car il est marqué pour n'accepter que des GET.

Donc la correction était simple :

[HttpDelete]
public bool DeleteProgramme(int id)
{
    ...
}

Et tout est rentré dans l'ordre. Une erreur stupide vraiment mais difficile à déboguer.

Answer 4

Si vous décorez votre méthode avec HttpGet, ajoutez le using suivant en haut du contrôleur :

using System.Web.Http;

Si vous utilisez System.Web.Mvc, alors ce problème peut survenir.

Answer 5

Ceci est certainement un changement de Beta à RC. Dans l'exemple fourni dans la question, vous devez maintenant décorer votre action avec [HttpGet] ou [AcceptVerbs("GET")].

Cela pose un problème si vous souhaitez mélanger les actions basées sur des verbes (c'est-à-dire "GetSomething", "PostSomething") avec des actions non basées sur des verbes. Si vous essayez d'utiliser les attributs ci-dessus, cela causera un conflit avec toute action basée sur un verbe dans votre contrôleur. Une façon de contourner cela serait de définir des routes séparées pour chaque verbe, et définir l'action par défaut sur le nom du verbe. Cette approche peut être utilisée pour définir des ressources enfants dans votre API. Par exemple, le code suivant prend en charge : "/resource/id/children" où id et children sont optionnels.

        context.Routes.MapHttpRoute(
           name: "Api_Get",
           routeTemplate: "{controller}/{id}/{action}",
           defaults: new { id = RouteParameter.Optional, action = "Get" },
           constraints: new { httpMethod = new HttpMethodConstraint("GET") }
        );

        context.Routes.MapHttpRoute(
           name: "Api_Post",
           routeTemplate: "{controller}/{id}/{action}",
           defaults: new { id = RouteParameter.Optional, action = "Post" },
           constraints: new { httpMethod = new HttpMethodConstraint("POST") }
        );

Hopefully future versions of Web API will have better support for this scenario. Il y a actuellement un problème signalé sur le projet codeplex aspnetwebstack, http://aspnetwebstack.codeplex.com/workitem/184. Si c'est quelque chose que vous aimeriez voir, veuillez voter sur la question.