Метод WebAPI 2 говорит 404 для одного, но не другого метода - PullRequest
Новая
       4

Метод WebAPI 2 говорит 404 для одного, но не другого метода

0 голосов
/ 31 октября 2018

У меня есть проект WebApi 2.0. У меня есть два контроллера. Один работает как положено, другой дает мне 404. Рабочий контроллер: 

    namespace SubscriptionApi.Controllers
    {
        using System.Threading.Tasks;
        using System.Web.Http;
        using Models.Services;

        [RoutePrefix("api/SubscriptionCheck")]
        public class SubscriptionCheckController : ApiController
        {
            public SubscriptionCheckController(IQuerySubscription queryService)
            {
                QueryService = queryService;
            }

            private IQuerySubscription QueryService { get; }

            [HttpGet] 
            [Route("Get/{email}/{productCode}")]
            public async Task<bool> Get(string email, string productCode)
            {
                return await QueryService.IsSubscribed(email, productCode);
            }
        }
    }

В своем браузере я могу запустить приложение и ввести http://localhost:55816/api/SubscriptionCheck/Get/bob@place.org/PRD в браузер. Он возвращает истину или ложь, как я ожидаю. Отказ контроллера очень похож. 

    namespace SubscriptionApi.Controllers
    {
        [RoutePrefix("api/RepresentativeCheck")]
        public class RepresentativeCheckController : ApiController
        {
            public RepresentativeCheckController(IQuerySubscription queryService)
            {
                QueryService = queryService;
            }

            private IQuerySubscription QueryService { get; }

            [HttpGet]
            [Route("Get/{email}")]
            public async Task<bool> Get(string email)
            {
                return await QueryService.IsPrimaryOrAlternateRepresentative(email);
            }
        }
}

Когда приложение запущено, я ввожу http://localhost:55816/api/RepresentativeCheck/Get/bob@place.org, и оно сообщает «Ошибка HTTP 404.0 - Не найдено» Ресурс, который вы ищете, был удален, изменилось его имя или временно недоступен. "

В global.asax нет ничего странного: 

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        GlobalConfiguration.Configure(WebApiConfig.Register);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }

WebApi настраивается перед страницами MVC. Используя атрибутную маршрутизацию, я не ожидал бы, что таблицы маршрутов окажут какое-либо влияние, но для полноты: 

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

У меня возникли проблемы с разницей между SubscriptionCheck, который работает нормально, и PresidentCheck, который обращается ко мне 404. Любая помощь приветствуется.

Windows 10, VS Pro 2017 15.8.8, IIS Express

Ответы [ 2 ]

0 голосов
/ 04 ноября 2018

Кажется, больше а. (точка) проблема. Когда у вас есть точка, в параметрах, передаваемых через URI, WebAPI ожидает символ «/» в конце переменной. Чтобы это работало, вы должны сделать звонок таким образом 

http://localhost:55816/api/RepresentativeCheck/Get/bob@place.org/

Вот почему ваш первый звонок 

http://localhost:55816/api/SubscriptionCheck/Get/bob@place.org/PRD

работал.

Попробуйте добавить. (точка) в PRD, и он не будет работать даже в SubscriptionCheck. В любом случае, в этом случае, когда у вас есть параметры, которые могут иметь какой-то специальный символ, я предлагаю вам использовать глагол POST и отправить JSON на контроллер.

0 голосов
/ 01 ноября 2018

Я нашел обходной путь, который не совсем решает проблему, потому что я его не совсем понимаю. RAMMFAR. Если я добавлю атрибут runAllManagedModulesForAllRequests к своему элементу модулей, установите true, он будет работать как положено. Я обнаружил это, потому что случайно нажал клавишу возврата, прежде чем завершил аргумент адреса электронной почты. API вел себя так, как и следовало ожидать для плохого адреса электронной почты. Это заставило меня гуглить о символах '@' в приложениях MVC, и RAMMFAR был ответом. Есть какой-то модуль, который смотрит на URL с '@' и ворует его из канала. Похоже. Если я хочу испытать побочные эффекты RAMMFAR, мой API теперь работает. Я все еще стремлюсь узнать детали.

...