2015-03-12 14 views
0

Я разрабатываю веб-приложение с использованием ASP.NET MVC и веб-API. мне нужно следующее отображение:Весь маршрут с Web API и ASP.NET MVC?

http://mysite/  => Welcome page (MVC) 
http://mysite/Help => Help page (MVC) 
http://mysite/anything_else_here => Web API Search with "anything_else_here" param 

Я использую следующие привязки:

// RouteConfig.cs, MVC routing   
routes.MapRoute(
      name: "Default", 
      url: "{controller}/{action}/{id}", 
      defaults: new { controller = "Home", 
       action = "Index", id = UrlParameter.Optional } 

и

//WebApiConfig.cs 
config.Routes.MapHttpRoute(
      name: "CatchAll", 
      routeTemplate: "{q}", 
      defaults: new { controller = "Search", action = "GetGeneric" }, 
      constraints: new { q = @"\S+" } 

Этой конфигурация отлично подходит для всех запросов, за исключением тех, кто работает там, где есть процент mark (используется для пространственного кодирования).

E.g. запросы, как

http://mysite/shop 
http://mysite/get+discount 
http://mysite/redeem+code 

работают отлично, но

http://mysite/shopping%20experience 
http://mysite/get%20discount 
http://mysite/redeem%20code 

нет. Вместо этого я получаю сообщение об ошибке 404 «Ресурс не найден».

Любые идеи, как я могу поймать эти запросы?

Ограничение "\ S +" соответствует значению процента.

ответ

1

По-моему, это по дизайну. Ваши противоречия проверяются, но только после декодирования части URL-адреса, которая соответствует параметру. Ваш %20 на самом деле является пространством.

Ваш знак плюса не является кодированным символом и обрабатывается буквально, поэтому он соответствует классу «не-whitespace» выражения ограничения.

Что вызывает вопрос: почему у вас есть ограничение на этот маршрут?

+0

Мне нужен этот случай, чтобы пустые маршруты (ничего не поставлялись вообще) были перехвачены диспетчером маршрутов ASP.NET MVC и покажите мне обработанное представление, а не вызов контроллера WebAPI. –

+0

Соглашение заключается в том, чтобы префикс всего материала веб-API с помощью «/ api», так что было бы намного сложнее путать проблемы маршрутизации между ними. –

+0

Да, я знаю это соглашение. Проблема в том, что веб-приложение служит прокси для корпоративного приложения, которое я не могу изменить. Это корпоративное приложение отправляет запрос в форме 'http: // endpoint/parameterstring'. Мое веб-приложение, которое размещено на 'http: // endpoint /', анализирует строку параметров и возвращает ожидаемые данные обратно в это приложение, имитируя исходную (более недоступную) услугу. Поэтому я не могу полагаться на какое-либо соглашение на маршруте. Если строка параметров не указана, я возвращаю страницу справки для пользователя с пояснениями об этой службе прокси. –

Смежные вопросы