Как я могу указать URL-адрес в Swashbuckle / Swaggerwork, когда api обслуживается из другого проекта?

все. Я пытаюсь задокументировать WebApi 2 с помощью пакета Swashbuckle.

Все отлично работает, если API работает сам по себе, т.е. localhost / api / swagger переводит меня в ui, а localhost / api / swagger / docs / v1 - в json.

Однако производственное приложение инициализирует этот же проект Webapi, запустив метод webapiconfig этого проекта из global.asax.cs в другом - теперь веб-проекте (главном приложении). Таким образом, URL-адрес api выглядит как localhost / web / api вместо localhost / api.

Теперь автоматическая автоматика так не работает.

  • localhost / api / swagger генерирует ошибку, не удается загрузить API.WebApiApplication, ну, конечно
  • локальный / веб / чванство = 404
  • локальный / веб / API / чванство = 404

Я пытался поискать везде, но все, что я нашел, - это обходной путь.

c.RootUrl(req => req.RequestUri.GetLeftPart(UriPartial.Authority) + VirtualPathUtility.ToAbsolute("~/").TrimEnd('/'));

К сожалению, это не работает, теперь, может быть, это и нужно, и мне просто нужно что-то изменить, но я даже не знаю, что именно ожидает это свойство и что оно должно быть установлено.

Может быть, это даже не применимо - может быть, для установки требуется что-то еще или какие-то изменения кода автомата.

Буду признателен за любую помощь, которую вы можете оказать. Мне действительно начинает нравиться чванство (и автомат) для остальной документации.


person Dmitriy    schedule 01.05.2015    source источник


Ответы (1)


Для Swashbuckle 5.x:

Это, по-видимому, установлено с помощью an extensionSwashbuckle. Swashbuckle 5.x указывает на замену этого файла readfag, заменяющий этот файл readfag для миграции, SwaggerDocConfig RootUrl () специально заменяет ResolveBasePathUsing () из 4.x.

Практически это работает так же, как и раньше, похоже, самым большим изменением было то, что он был переименован и перемещен в SwaggerDocConfig:

public void RootUrl(Func<HttpRequestMessage, string> rootUrlResolver)

Пример из readme, измененный для краткости:

string myCustomBasePath = @"http://mycustombasepath.com";

httpConfiguration
    .EnableSwagger(c =>
        {
            c.RootUrl(req => myCustomBasePath);

            // The rest of your additional metadata goes here
        });

Для Swashbuckle 4.x:

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

ResolveBasePathUsing:

public SwaggerSpecConfig ResolveBasePathUsing(Func<HttpRequestMessage, string> basePathResolver);

Мой API находится за балансировщиком нагрузки, и это было полезным обходным путем для предоставления базового адреса. Вот глупый пример использования ResolveBasePathUsing для разрешения пути с известным базовым путем.

string myCustomBasePath = @"http://mycustombasepath.com";

SwaggerSpecConfig.Customize(c =>
{
    c.ResolveBasePathUsing((req) => myCustomBasePath);
}

Я жестко запрограммировал конечную точку для ясности, но вы можете определить ее где угодно. Вы даже можете использовать объект запроса, чтобы попытаться очистить ваш URI запроса, чтобы он указывал на / web / api вместо / api.

Разработчик прокомментировал этот обходной путь на GitHub в прошлом году:

Лямбда принимает текущий HttpRequest (то есть запрос для данного Swagger ApiDeclaration) и должна возвращать строку, которая будет использоваться в качестве baseUrl для вашего Api. Для приложений с балансировкой нагрузки это должно вернуть путь к балансировщику нагрузки.

Реализация по умолчанию следующая:

(req) => req.RequestUri.GetLeftPart(UriPartial.Authority) +  req.GetConfiguration().VirtualPathRoot.TrimEnd('/');

...

Что касается относительных путей, спецификация Swagger требует абсолютных путей, потому что URL-адрес, по которому обслуживается Swagger, не обязательно должен быть URL-адресом фактического API.

...

Лямбда передается экземпляр HttpRequestMessage ... вы должны иметь возможность использовать это для получения RequestUri и т. Д. Другой вариант, вы можете просто поместить имя хоста в свой web.config, а лямбда просто прочитает его оттуда.

person Anthony Neace    schedule 02.05.2015
comment
Эта статья на github была первой, которую я прочитал, последний комментарий - это именно то место, где я получил код, который я вставил в свой вопрос. Это не сработало. Я хотел бы попробовать, как вы описываете, потому что, по крайней мере, теперь я вижу то, что ожидается, как ценность. Но предоставленный вами код не работает как есть. VS жалуется на SwaggerSpecConfig как на undefined. Можете ли вы предоставить полный код и версию автомата, с которой работает этот код? Пожалуйста. - person Dmitriy; 02.05.2015
comment
@ user1803063 Смотрите мое обновление. Я использую Swashbuckle.Core 4 с некоторыми несвязанными расширениями. Глядя на Swashbuckle 5, похоже, что эта функция для базового URL-адреса была немного очищена, и ее стало проще найти и использовать. Не беспокойтесь о SwaggerSpecConfig и ResolveBasePathUsing, если вы используете 5, он был заменен методом расширения httpConfiguration EnableSwagger. Извините за путаницу, мне еще не нужно было обновляться до 5, и это выглядело очень похоже на проблему, которая у меня была раньше. :) - person Anthony Neace; 02.05.2015
comment
К сожалению, это не работает. Я начинаю думать, что это может быть ошибка. Я попытался поместить все в RootUrl localhost, localhost / web и localhost / web / api для меня все еще генерирует 404. - person Dmitriy; 03.05.2015
comment
Приведенный выше ответ верен, проблема, с которой я столкнулся, была установлена ​​в API. После того, как он был установлен в веб-проекте (и были изменены некоторые параметры переписывания URI), он начал работать правильно. Сложно иметь такое сочетание маршрутов, реальных и абсолютных путей. Но теперь это работает. Спасибо за помощь. - person Dmitriy; 20.05.2015
comment
@Dmitry Вы имеете в виду, что вы установили swagger в веб-проект, но он работал для api aproj? - person Kate; 09.09.2020