with tutorial started route query net mvc attribute asp asp.net-mvc asp.net-mvc-4 asp.net-web-api

asp.net mvc - tutorial - Todos los controladores API web ASP.NET devuelven 404



web api rest c# (16)

Agregar la siguiente línea

GlobalConfiguration.Configure(WebApiConfig.Register);

en la función Application_Start() en el archivo Global.ascx.cs .

Intento que un controlador API funcione dentro de una aplicación web ASP.NET MVC 4. Sin embargo, cada solicitud da como resultado un 404 y estoy perplejo. : /

Tengo la ruta estándar del controlador API desde la plantilla del proyecto definida como:

public static class WebApiConfig { public static void Register(HttpConfiguration config) { config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } }

El registro se invoca en Global.asax:

protected void Application_Start() { AreaRegistration.RegisterAllAreas(); // Register API routes WebApiConfig.Register(GlobalConfiguration.Configuration); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); }

Tengo un controlador API básico como este:

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) { } } }

Ahora, cuando navego a localhost: 59900 / api / Favorites , espero que se invoque el método Get , pero en su lugar obtengo un código de estado 404 y la siguiente respuesta:

<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>

Cualquier ayuda sería muy apreciada, estoy perdiendo la cabeza un poco por aquí. :) ¡Gracias!


Agregue esto a <system.webServer> en su 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>

Agregar <modules runAllManagedModulesForAllRequests="true" /> también funciona, pero no se recomienda debido a problemas de rendimiento.


Compruebe que si su clase de controlador tiene el atributo [RoutePrefix ("somepath")], todos los métodos del controlador también tienen un atributo [Route ()].

Me encontré con este problema también y me estaba rascando la cabeza por un tiempo.


Crea un atributo de ruta para tu método.

ejemplo

[Route("api/Get")] public IEnumerable<string> Get() { return new string[] { "value1", "value2" }; }

Puede llamar como estos http://localhost/api/Get


Estoy un poco perplejo, no estoy seguro de si esto se debió a un problema de almacenamiento en caché de la salida HTTP.

De todos modos, "de repente comenzó a funcionar correctamente". : / Entonces, el ejemplo anterior funcionó sin que yo agregara o cambiara nada.

Supongo que el código solo tuvo que sentarse y cocinar durante la noche ... :)

Gracias por ayudar, chicos!


He estado trabajando en un problema similar a este y me llevó años encontrar el problema. No es la solución para esta publicación en particular, pero con suerte agregar esto ahorrará a alguien un poco de tiempo tratando de encontrar el problema cuando están buscando por qué podrían recibir un error 404 para su controlador.

Básicamente, deletreaba "Controlador" mal al final de mi nombre de clase. ¡Simple como eso!


He resuelto un problema similar adjuntando con depurador a la aplicación init. Simplemente inicie el servidor web (por ejemplo, acceda a localhost), conéctelo a w3wp y vea si la inicialización de la aplicación finalizó correctamente. En mi caso hubo excepción, y los controladores no se registraron.


Por razones que no tengo claras, he declarado todos mis Métodos / Acciones como estáticos; aparentemente, si lo haces, no funcionará. Así que solo suelta la static

[AllowAnonymous] [Route()] public static HttpResponseMessage Get() { return new HttpResponseMessage(System.Net.HttpStatusCode.OK); }

Convirtió:-

[AllowAnonymous] [Route()] public HttpResponseMessage Get() { return new HttpResponseMessage(System.Net.HttpStatusCode.OK); }


Problema similar con una solución vergonzosamente simple: asegúrese de que sus métodos API sean public . Al dejar cualquier modificador de acceso a métodos, también se devolverá un HTTP 404.

Volverá 404:

List<CustomerInvitation> GetInvitations(){

Se ejecutará como se espera:

public List<CustomerInvitation> GetInvitations(){


Tenía esencialmente el mismo problema, resuelto en mi caso agregando:

<modules runAllManagedModulesForAllRequests="true" />

al

<system.webServer> </system.webServer>

sección de web.config


Tenía este problema Tuve que desmarcar Precompile during publishing .


Tuve el mismo problema 404 y ninguna de las soluciones votadas aquí funcionó. En mi caso tengo una aplicación secundaria con su propio web.config y tenía una etiqueta clara dentro de la sección httpModules web.config del padre. En IIS, todas las configuraciones web.config de los padres se aplican a la subaplicación.

<system.web> <httpModules> <clear/> </httpModules> </system.web>

La solución es eliminar la etiqueta ''borrar'' y posiblemente agregar inheritInChildApplications = "false" en el web.config del padre. InheritInChildApplications es para que IIS no aplique la configuración de configuración a la aplicación secundaria.

<location path="." inheritInChildApplications="false"> <system.web> .... <system.web> </location>


Tuve el mismo problema, luego descubrí que tenía nombres de clase de controlador api duplicados en otro proyecto y, a pesar de que el "routePrefix" y el espacio de nombre y el nombre del proyecto eran diferentes, pero aún así me devolvieron 404, cambié los nombres de clase y trabajó.


Una cosa que me encontré fue tener mis configuraciones registradas en el orden incorrecto en mi archivo GLobal.asax, por ejemplo:

Orden correcto:

AreaRegistration.RegisterAllAreas(); WebApiConfig.Register(GlobalConfiguration.Configuration); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes);

Orden incorrecto:

AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); WebApiConfig.Register(GlobalConfiguration.Configuration);

Simplemente diciendo, este era mi problema y cambiar el orden es obvio, pero a veces se pasa por alto y puede causar mucha frustración.


Voy a agregar mi solución aquí porque personalmente odio las que editan la web.config sin explicar lo que está sucediendo.

Para mí fue así como las Asignaciones de Manejador predeterminadas están configuradas en IIS. Para verificar esto ...

  1. Abra el Administrador de IIS
  2. Haga clic en el nodo raíz de su servidor (generalmente el nombre del servidor)
  3. Abra "Asignaciones de manejador"
  4. En Acciones en el panel derecho, haga clic en "Ver lista ordenada"

Este es el orden de los manejadores que procesan una solicitud. Si el suyo es como el mío, los manejadores "ExtensionlessUrlHandler- *" están debajo del controlador StaticFile. Bueno, eso no va a funcionar porque el manejador de StaticFile tiene un comodín de * y devolverá un 404 incluso antes de llegar a un controlador sin extensión.

Así que reorganizar esto y mover el "ExtensionlessUrlHandler- *" sobre los manejadores de comodines de TRACE, OPTIONS y StaticFile tendrá el manejador Extensionless activado primero y debería permitir que sus controladores, en cualquier sitio web que se ejecute en el sistema, respondan correctamente.

Nota: Esto es básicamente lo que sucede cuando elimina y agrega los módulos en el archivo web.config, pero en un solo lugar para resolverlo. ¡Y no requiere código adicional!


WebApiConfig.Register(GlobalConfiguration.Configuration);

Debería ser el primero en el evento App_start. Lo intenté en la última posición en el evento APP_start, pero eso no funcionó.