内部および外部APIアーキテクチャ

私が働いている会社は、長年にわたって「有機的に」成長した成功したSaaS製品を維持しています。既存の製品とデータを共有する一連の新製品でラインを拡大する予定です。これをサポートするために、ビジネスロジックを1つの場所、つまりWebサービスレイヤーに統合することを検討しています。WSレイヤーは以下によって使用されます。

• Webアプリケーション
• データをインポートするツール
• 他のクライアントソフトウェアと統合するためのツール（APIそのものではありません）

また、それを使用して独自の統合を作成できるお客様が使用できるAPIを作成したいと考えています。次の質問に取り組んでいます：

内部API（別名WSレイヤー）と外部APIは同じものであり、セキュリティとアクセス許可の設定により、誰が何を実行できるかを制御するか、外部APIが内部APIを呼び出すだけの2つの別個のアプリケーションである必要があります他のアプリケーションのように？これまでの議論では、それらを分離する方が安全かもしれませんが、オーバーヘッドが追加されます。

同様の状況で他の人は何をしましたか？

自分のドッグフードを食べることは常に良いことです。また、認証と承認のオーバーヘッドを考慮しても、1つのAPIは2つよりも保守が簡単です。

Aneurysm9には同意しますが、システムのすべての機能を公開したくない場合があります。この場合、2つのAPIを持つことが望ましいだろう... しかし 、あなたはとても明確な2とは対照的に、一方が他方の拡張版であることIE、すべての一般的な機能は同じAPIを共有していることを確認しない...この道を選んだならばコードのセット。

このようにして、プライベートAPIを変更せずに新しいものを公開して使用できるようにしつつ、プライベートで機密性の高い実験的な作業を進めるための場所を確保しながら、自分用に使用することができます。

私はこれに何度も遭遇しましたが、私が好んでやってきたことは次のとおりです：

WebサイトからBLを取り出します。WebサイトをAPIのコンシューマーにします。WebサイトをAPIの他のクライアントとして扱います。APIがサービスです。

Webサイト専用の特別なAPIメソッドが必要だと思ったら、もう一度考えてみてください！それがガチョウに良いなら、それはガンダーに良いです。もしあなたが本当に本当にウェブサイトに特別な機能を必要とするなら、あなたが本当に見つけたのは「ユーザープロファイル」の違いだとお勧めします。承認を介してそれらを制御します。

納得できない？

パラダイムをさらに一歩進めて......

電話アプリは、バイトコードが実行されるプラットフォームで実行され、アプリは電話に常駐し、HTTP / JSONを介してAPIサービスを消費します

Webサイトは、HTML + Javascriptが実行されるプラットフォームで実行されるアプリであり、アプリはブラウザーに存在し、HTTP / JSONを介してAPIサービスを消費します

同じ同じ！

タブレット、テレビ、その他の電話プラットフォーム、プラグイン、サードパーティのアプリ、マッシュアップなどに拡張してください...

多くの異なるユーザーエクスペリエンスがすべて共通のAPIにプラグインされています。

アプリはAPIです。ウェブサイトは（多くの）たった1つのクライアントです

1つのAPIを使用する

サービスAPIをRESTレイヤーとして実装している場合は、保護されているルートに認証を追加するだけです。

おそらく、あまり多くの「魔法」を焼き付けない開発フレームワークを使用することになるでしょう。大量のリバースエンジニアリングなしでルートを直接定義できる場所。

Node.js / Express、python / pylons、python / googleアプリエンジンなどのように考えてください。

最近、これをREST / Datastore APIのGoogle App Engineに実装しましたが、もっと簡単だったとは思いません。コントローラーはクラスとして実装され、その後のHTTP要求（つまり、GET / POST / PUT / DELETE）はそれらのクラスのメソッドとして実装されます。デコレータとしてbasic-authを実装できました。これにより、@ basicAuthデコレータを添付するのと同じくらい簡単に、要求に認証要件を追加できました。

そうすれば、受信したGETリクエストをパブリックにして、そのモデルの同じコントローラー上のPOST / PUT / DELETEリクエストに認証要件を追加できます。

RESTで話す方法を知っていれば、RESTのサポートはすでに本質的にすべてのWebサーバーに組み込まれているため（つまり、HTTPはREST APIの一種です）、生活がずっと楽になります。ネットワーク経由で大量のデータを送信する場合は、透過的なgzip圧縮を選択することもできます。

私の第一印象は、同じAPIである必要があり、セキュリティはまったく別のレイヤーにあるべきだということです。おそらくウェブフロントで処理されますか？