0

次の構造の Web プロジェクト プロジェクトがあります。

Web プロジェクト
- コントローラー
    - API
        - サブスクリプションコントローラー
        - ユーザーコントローラー
    - サブスクリプションコントローラー
- ビュー
    - サブスクリプション
        - 確認.cshtml
        - ConfirmationSuccessfull.cshtml

サブスクリプションを扱っていると仮定して、新しいサブスクリプションを作成またはキャンセルするメソッドを API で公開します。これらのメソッドは、外部アプリケーションから呼び出されます。

要件の一部として、ユーザーはサブスクリプションを確認する必要があります。これは URL にアクセスすることによって行われ、確認時にユーザーは成功ページを取得します。

ここに問題があります: API を (http://api.myapp.com/subscription -> サブスクリプション api コントローラーの場合) のようなアドレスで公開し、プロジェクトの確認部分を別のアドレス (http:/ /myapp.com/subscription/confirm -> サブスクリプションの確認用) ですが、API URL の Web サイト部分にアクセスしたり、その逆をしたりしたくありません。

これを 2 つの異なる方法で制限することを考えました。

  1. 両方のドメインに応答する 1 つの IIS サイトにアプリケーションを保持し、要求と共に送信されたホスト ヘッダーを調べて、どこにルーティングするかを調べます。Web サイトの呼び出しが API ドメインから着信した場合、404 が返されます。ここでの問題は、ドメイン制限がコード内で「ハードコーディング」されていることと、コード内でこの種のインフラストラクチャを処理する必要があることです。
  2. アプリケーションを 2 つの異なる Web プロジェクトに分け、IIS の異なる Web サイトに配置します。これは、要件を処理する最もクリーンな方法ですが、扱いたくない複雑さをもたらします。2 つの異なるサイトを 2 つの異なるフォルダーで管理し、2 つの異なるコードと展開プロセスを使用する必要があります。

では、できれば両方の長所を生かした 3 番目のオプションはありますか?

ありがとう！

4

1 に答える 1

0

オプション 1 は実装が非常に簡単で、実際のインフラストラクチャ自体は必要ありません。単純なカスタム ルート制約です。以前の質問How to configure Webapi Selfhosted for multiple HostHeaders で、ホスト ヘッダーを使用してルーティングを制御する方法を示そうとしました。

于 2013-01-24T08:56:50.020 に答える