2016-09-01 16 views
2

大規模エンタープライズアプリケーション用にAPIを実装するには、ルートアプリケーション内で実行される複数の子Webアプリケーションが必要です。たとえば、ルート、チャイルド1、およびチャイルド2大規模エンタープライズAPIデザイン

IISでホストされているアプリケーションごとに別々のMVPプロ​​ジェクトがあります。 MVCアプリケーションにはフロントエンドロジックのみがあり、ビジネス&データアクセスレイヤーは別のWCFプロジェクト(すべての子ども用に別々のWCFプロジェクト)でホストされます。フロントエンドのMVCアプリケーションは、WCFアプリケーションをターゲットにするためにのみリクエストをルーティングします。

ここでは、アプリケーションごとにAPIを設計する予定です。すべての子アプリケーションとルートアプリケーションのAPIを保持する個別のアプリケーションを作成するか、各アプリケーションにAPIを追加する必要があるかどうかを判断することはできません。フロントエンドMVCプロジェクトと同様に、APIも集中型WCFアプリケーションにリダイレクトされます。

すべてのAPI(レート制限、認証など)に共通のロジックがあります.APIが各アプリケーションにある場合は、3つのアプリケーションすべてでレプリケーションロジックが必要です。

+1

APIのレート制限はすべて、または個別に行われますか? APIを個別に展開する必要がありますか?スケーリングの違いは? – tomliversidge

+0

@tomliversidgeはい、レート制限などのAPIのプロパティはすべてのAPIに適用されます。 APIを個別にデプロイする必要はなく、すべてを単一のアプリケーションにまとめることができます。 –

+0

別々の場合、API全体でレート制限をどのように計画していますか? – tomliversidge

答えて

0

いずれにしてもトレードオフがあります。

個別のAPIを開発する利点には、次のものがあります。

  1. 分離
  2. すなわち個別に展開可能に変更する方が簡単別の開発チームは、異なるAPIに関与している場合は、独立して
  3. が簡単になります拡張することができ

短所は次のとおりです。あなたは、各APIまたは抽出物に共通のコードを繰り返したい場合は

  1. を決定する必要があります
  2. より多くのインフラストラクチャ/ opsを処理する
  3. すべてのAPIでレート制限の調整が必要な場合は、これがhaです。私はだ - 彼らは、単一のAPIである場合に

私のデフォルトの位置は、別のAPIを開発するだろうが、あなたの特定のユースケース(他のものへの要求をルーティング)は、いくつかの既存のツールなどのnginxによって解決されるかもしれないよりRDERこれらについて知識がないので助言することはできません

+0

ありがとうございます、私はすべてのapisを保持する別々のアプリケーションを使用する予定です。 –

関連する問題