Quelle est la différence entre API Gateway et ESB?
ESB est un intergiciel traditionnel utilisé dans les solutions SOA pour le routage, la transformation de messages, Le pontage de protocole, entre autres choses. Une nouvelle catégorie de solutions middleware appelée API Gateway sont maintenant offertes par plusieurs fournisseurs. Ces solutions sont généralement décrites comme étant le point central pour accéder aux services REST et SOAP offerts publiquement par une organisation. Toutefois, les solutions API Gateway semblent offrir un sous-ensemble de fonctionnalités typiques de L'ESB.
oui, quelles sont les différences entre ESB et API Gateway? Quand devrais-je utiliser l'un ou l'autre?
2 réponses
une passerelle API est quelque chose qui agit typiquement comme un proxy pour vos services web et fournit une valeur intéressante, telle que: journalisation, rendre les services SOAP appelables comme les services de repos, aide au débogage, traçage, etc... Parce que la passerelle API est une position assise entre le consommateur et vos services, elle peut facilement capturer le trafic et faire ce genre de choses.
un Bus de service D'entreprise (comme nServiceBus) est conçu pour s'asseoir sur un protocole de messagerie (comme RabbitMQ) pour lui donner fonctionnalité qui ne vient pas avec (ou la fonctionnalité qui est difficile à mettre en œuvre) la messagerie de base ou pub-sub, par exemple: base de données stockées des messages durables, logique de Rety, encapsulation de l'auditeur, des façons plus faciles de s'abonner aux messages, et sagas. Vous pouvez utiliser le protocole de messagerie sans utiliser un ESB mais pas l'inverse. Par exemple, vous pouvez utiliser RabbitMQ sans l'aide de nServiceBus.
étant donné que les passerelles API et les ESB sont toutes deux capables de servir des mandataires de service, si l'on ne considère que les capacités de médiation et de transformation des deux outils, elles peuvent sembler identiques. La principale différence dans une passerelle API pour moi réside dans le but précis pour lequel elle est créée. Une passerelle API devrait pouvoir servir de point d'entrée aux ressources qu'elle propose, en plus de fournir des capacités de transformation et de routage. De plus, ils devraient être en mesure de déléguer le contrôle d'accès et l'étranglement. aspects à d'autres composants spécialisés, en les utilisant, il devrait être en mesure de garantir le comportement souhaité. Comme une passerelle API ferait partie d'une solution de gestion D'API, toutes ces fonctionnalités seront supportées OOTB.
il peut être possible d'obtenir un comportement similaire pour les mandataires de service en utilisant un ESB et d'autres composants externes ou un logiciel. Toutefois, étant donné que les ase sont conçues pour répondre à un ensemble plus vaste d'exigences d'intégration et qu'elles ne sont pas spécialisées pour L'IPA cas d'utilisation par la direction il serait beaucoup plus difficile de les réaliser.