ASP.NET Web Api: Żądany zasób nie obsługuje metody http „GET”

Mam następującą akcję na ApiController:

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

Skonfigurowałem moje trasy w następujący sposób:

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

W wersji beta działało to dobrze, ale właśnie zaktualizowałem do najnowszej wersji Release Candidate i teraz widzę błędy w wywołaniach takich jak ten:

Żądany zasób nie obsługuje metody http „GET”.

Dlaczego to już nie działa?

(Przypuszczam, że mógłbym pozbyć się {action} i po prostu stworzyć mnóstwo kontrolerów, ale wydaje mi się, że to bałagan.)

Jeśli nie skonfigurowałeś żadnego HttpMethod na swojej akcji w kontrolerze, zakłada się, że jest to tylko HttpPost w RC. W wersji Beta zakłada się, że obsługuje wszystkie metody - GET, PUT, POST i Delete. To niewielka zmiana z wersji beta na RC. Możesz łatwo odszyfrować więcej niż jedną metodę http w swojej akcji za pomocą [AcceptVerbs ("GET", "POST")].

Wszystkie powyższe informacje są poprawne, chciałbym również zwrócić uwagę, że [AcceptVerbs()]adnotacja istnieje zarówno w przestrzeni nazw System.Web.Mvc, jak i System.Web.Http.

Chcesz użyć System.Web.Http, jeśli jest to kontroler interfejsu API sieci Web.

Chociaż nie jest to odpowiedź na PO, miałem dokładnie ten sam błąd z zupełnie innej przyczyny; więc jeśli to pomoże komuś innemu ...

Moim problemem był nieprawidłowo nazwany parametr metody, który spowodował, że WebAPI nieoczekiwanie skierowało żądanie. Mam następujące metody w moim ProgrammesController:

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

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

Żądania DELETE do ... / api / programy / 3 nie były kierowane do DeleteProgramme, jak się spodziewałem, ale do GetProgrammeById, ponieważ DeleteProgramme nie miało nazwy parametru id. GetProgrammeById oczywiście odrzucał wtedy DELETE, ponieważ jest oznaczony jako akceptujący tylko GET.

Więc poprawka była prosta:

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

I wszystko w porządku. Naprawdę głupi błąd, ale trudny do debugowania.

Jeśli dekorujesz swoją metodę za pomocą HttpGet, dodaj następujące elementy usingu góry kontrolera:

using System.Web.Http;

Jeśli używasz System.Web.Mvc, może wystąpić ten problem.

To z pewnością zmiana z wersji beta na RC. W przykładzie podanym w pytaniu musisz teraz udekorować swoją akcję za pomocą [HttpGet] lub [AcceptVerbs ("GET")].

Powoduje to problem, jeśli chcesz mieszać akcje oparte na czasownikach (np. „GetSomething”, „PostSomething”) z akcjami nieopartymi na czasownikach. Jeśli spróbujesz użyć powyższych atrybutów, spowoduje to konflikt z jakąkolwiek akcją opartą na czasowniku w kontrolerze. Jednym ze sposobów uzyskania arount, które polegałoby na zdefiniowaniu oddzielnych tras dla każdego czasownika i ustawieniu domyślnej akcji na nazwę czasownika. To podejście może służyć do definiowania zasobów podrzędnych w interfejsie API. Na przykład następujący kod obsługuje: „/ zasób / id / dzieci”, gdzie id i dzieci są opcjonalne.

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

Miejmy nadzieję, że przyszłe wersje interfejsu API sieci Web będą lepiej obsługiwać ten scenariusz. Obecnie w projekcie aspnetwebstack codeplex zarejestrowano problem, http://aspnetwebstack.codeplex.com/workitem/184 . Jeśli jest to coś, co chciałbyś zobaczyć, zagłosuj w tej sprawie.

Mają taką samą konfigurację jak OP. Jeden kontroler z wieloma akcjami ... mniej „bałaganu” :-)

W moim przypadku zapomniałem o "[HttpGet]" podczas dodawania nowej akcji.

[HttpGet]
public IEnumerable<string> TestApiCall()
{
    return new string[] { "aa", "bb" };
}

Ten sam problem, co powyżej, ale znacznie inny root. Dla mnie chodziło o to, że trafiałem na punkt końcowy z regułą przepisywania https. Naciśnięcie go na http spowodowało błąd, działało zgodnie z oczekiwaniami z https.

Zastąp następujący kod w tej ścieżce

Ścieżka:

App_Start => WebApiConfig.cs

Kod:

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

Nie wiem, czy może to być związane z postem OP, ale brakowało mi adnotacji [HttpGet] i to właśnie było przyczyną błędu, jak stwierdzono w metodach @dinesh_ravva, domyślnie przyjmuje się, że jest to HttpPost.

Mój problem był tak prosty, jak posiadanie zerowego odwołania, które nie pojawiło się w zwróconym komunikacie, musiałem debugować mój interfejs API, aby go zobaczyć.