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

Question

J'ai l'action suivante sur un ApiController:

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

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 Release Candidate et maintenant je reçois 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 me semble compliqué.)

Answer 1

Si vous n'avez pas configuré de HttpMethod sur votre action dans le contrôleur, il est supposé être uniquement 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, je tiens également à souligner que l'annotation [AcceptVerbs()] existe à la fois dans les espaces de noms System.Web.Mvc et System.Web.Http.

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

Answer 3

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

Le problème pour moi était un paramètre de méthode mal nommé qui a causé une redirection inattendue de la requête par WebAPI. J'ai les méthodes suivantes dans mon ProgrammeController :

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

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

Les requêtes DELETE vers .../api/programmes/3 n'étaient pas redirigées vers DeleteProgramme comme je m'y attendais, mais vers GetProgrammeById, parce que DeleteProgramme n'avait pas un paramètre nommé id. GetProgrammeById rejetait ensuite bien sûr le DELETE car elle est marquée pour accepter seulement les GETs.

Donc la correction était simple :

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

Et tout est bien maintenant. C'était en réalité une erreur bête 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 se produire.

Answer 5

C'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 des actions basées sur le verbe (c'est-à-dire "GetSomething", "PostSomething") avec des actions non basées sur le verbe. Si vous essayez d'utiliser les attributs ci-dessus, cela entrera en conflit avec toute action basée sur le verbe dans votre contrôleur. Une façon de contourner cela serait de définir des routes séparées pour chaque verbe et de 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 facultatifs.

        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") }
        );

Idéalement, les futures versions de Web API offriront un meilleur support pour ce scénario. Il y a actuellement un problème signalé sur le projet aspnetwebstack codeplex, http://aspnetwebstack.codeplex.com/workitem/184. Si c'est quelque chose que vous aimeriez voir, veuillez voter pour le problème.