APIゲートウェイとESBの違いは何ですか？
私が働いている会社は、Webサービスのガバナンス、計測、およびセキュリティのためのいくつかのミドルウェアソリューションを評価しています。現在、この目的のためにEnterprise Service Bus（ESB）を使用していますが、一部の管理職のクールな人たちは、API管理ミドルウェアをデプロイすることに決めました。
これらのAPI管理（別名APIゲートウェイ）ソリューションについて少し調べましたが、それらと実際のESBの違いを見つけることができませんでした。 Mule、WSO2、Oracleなどのホワイトペーパーをいくつか評価しましたが、両方の製品で提供される機能はほとんど同じようです。問題は、ESBができないAPI管理とAPI管理ができることは何ですか？ API GatewayのESBを置き換えることにより、ITインフラストラクチャにどのような価値を追加できますか？
コンセプトが混乱しているのは、ベンダーがそれらをパッケージで販売しているためです。しかし、それらは明らかに別の概念です。
API Gatewayは、公開されているWebサービスへのアクセスを管理、監視、および保護するための中央アクセスポイントを提供します。また、すべてが単一のホストから提供されているかのように、異種のエンドポイント間でサービスを統合することもできます。たとえば、10個の異なるサービスエンドポイントがあり、すべてが単一の「スイート」のサービスの一部であったとします。サービスのコンシューマーに、あるサービスにはservice1.yourcompany.comを使用し、別のサービスにはservice2.yourcompany.comを使用するように通知するのではなく、それらすべてをapi.yourcompany.com/service1またはapi.yourcompany.comにポイントさせることができます。/service2とゲートウェイは、要求を適切なエンドポイントにリダイレクトする責任があります。
ESBは内部の「バス」であり、これにより、アプリケーションとサービスは分離した方法で相互に通信できます。すべてのアプリケーションはバスにフックでき、別のアプリケーションによって公開されたときに興味のあるメッセージを受信できます。また、別のアプリケーションがリッスンして応答する可能性のある独自のメッセージを公開することもできます。アプリケーションは相互に直接接続する責任はありません。アプリケーションはバスにメッセージを発行し、すべての関係者が聞いて反応します。
論理的には、API GatewayはESBの代わりではなく、サービス指向アーキテクチャーの拡張です。