18

全て。Swashbuckle パッケージを使用して WebApi 2 を文書化しようとしています。

API が単独で実行されている場合、すべてうまく機能します。つまり、 localhost/api/swaggerで ui に移動し、localhost/api/swagger/docs/v1で json に移動します。

ただし、本番アプリは、このプロジェクトの webapiconfig メソッドを別の global.asax.cs から実行することにより、この同じ Webapi プロジェクトを初期化します。これは、別の Web プロジェクト (メイン アプリケーションのプロジェクト) です。したがって、API の URL はlocalhost/apiではなく、localhost /web/apiのようになります。

現在、スワッシュバックルはそのようにまったく機能しません。

  • もちろん、localhost/api/swagger は「API.WebApiApplication」を読み込めないというエラーを生成します。
  • ローカルホスト/ウェブ/スワガー = 404
  • ローカルホスト/web/api/swagger = 404

私はどこでも見ようとしましたが、見つけたのは回避策だけです。

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

残念ながら機能しません。おそらく機能するはずであり、何かを変更する必要があるだけですが、このプロパティが正確に何を期待し、何に設定する必要があるかさえわかりません。

当てはまらないかもしれません - 私たちが持っているセットアップには何か他のものやスワッシュバックルのコードの変更が必要かもしれません.

あなたが提供できるどんな助けにも感謝します。私は残りのドキュメントのために、swagger (およびスワッシュバックル) が本当に好きになり始めています。

4

1 に答える 1

20

スワッシュバックル 5.x の場合:

これは、 EnableSwagger という httpConfiguration の拡張メソッドによって設定されているようです。Swashbuckle 5.x移行の readmeには、これが SwaggerSpecConfig を置き換えることが記載されています。SwaggerDocConfig RootUrl() は、特に 4.x の ResolveBasePathUsing() を置き換えます。

これは実際には以前と同じように機能します。最大の変更点は、名前が変更されて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
        });

スワッシュバックル 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);
}

わかりやすくするためにエンドポイントをハードコーディングしましたが、どこでも定義できます。リクエスト オブジェクトを使用して、 /api ではなく /web/api を指すようにリクエスト uri をクリーンアップすることもできます。

開発者は昨年、GitHubでこの回避策についてコメントしました。

ラムダは現在の HttpRequest (つまり、特定の Swagger ApiDeclaration の要求) を受け取り、Api の baseUrl として使用される文字列を返す必要があります。負荷分散されたアプリの場合、これはロード バランサー パスを返す必要があります。

デフォルトの実装は次のとおりです。

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

...

相対パスに関して、Swagger 仕様では絶対パスが必要です。これは、Swagger が提供される URL が実際の API の URL である必要がないためです。

...

ラムダには HttpRequestMessage インスタンスが渡されます...これを使用して RequestUri などを取得できるはずです。別のオプションとして、ホスト名を web.config に配置し、ラムダにそこから読み取らせることができます。

于 2015-05-02T00:32:54.690 に答える