Some managers consider APIs a buzzword related to integrations, a problem that they have already addressed with SOA + ESB. Nevertheless, APIs address new demands, which are not well managed by SOA, while SOA focuses on problems that APIs do not have.
With that in mind, how to know if:
The new wave of digital transformation is not only a matter of digitizing internal processes and integrations, but also of exploring the potential of the partner ecosystem, using legacy systems alongside new technologies (IoT, Cloud, AI + Analytics, Blockchain, etc.), having real-time monitoring and reacting quickly, providing experiences through different channels and interfaces, involving customers and collaborators, and overcoming scalability and security challenges, among other elements.
Lack of modern standards and lighter protocols: ESBs have been or tend to be discontinued.
It is a simple, agile and scalable way to integrate systems and create decoupled applications in the shortest possible time. When using an API Management platform, modules are obtained to support security, authentication, scalability, dev commitment, governance, monitoring, monetization, and the test environment, among other resources.
API Management and the ESB can exist alone, depending on the scenario and focus. In most scenarios, companies would benefit from both. In these cases, the architecture is even more robust, as long as we manage to enhance the strengths of each of them:
To reach a high degree of coverage in all the capacities of an integration layer, a possible approach would be to opt for the coexistence of the API Management platform with ESB. This approach enables the utilization of resources of the API Management platform (scalability, security, governance, dev commitment, Monetization, Analytics, etc.) with the capabilities of the ESB (variety of connectors, complex transaction processing, etc.).
There are, however, some limitations in terms of scalability, lock-in, and performance, while the rule engine can be obtained by means of a specific solution.
To cover the capabilities that the API management platform does not focus on, without the limitations of ESB, it is possible to create a layer referred to as API Front.
This layer is composed of APIs, microservices and connectors, thereby reducing the difficulties of scalability, decoupling, reuse, lock-in, and performance, as well as specific platforms for batch processing and the rules engine.
CapabilitiesPatternsAPI ManagementESBAlternative API ManagementAlternative ESB
Communication asynchronousWebSocketYesPartial – some ESBs supportN/AMessaging (eg AMQP)Synchronous communicationREST / JSONYesPartial – some ESBs supportN/AWS-SOAPGraphQLYesNoN/AN/ASecurityOAuth 2.0YesPartial – some ESBs supportN/AWS-Security and Basic AuthDDoSYesNoN/AUse of third-party solutionsWAF (Injections, XSS, CSRF)YesNoN/AUse of third-party solutionsSpike ArrestYesNoN/AUse of third-party solutionsTechnical monitoringReal Time AlertsYesNoN/AN/ATechnical monitoringDashboards & ReportsYesPartial – requires add-onN/ABAM (add-on)Business MonitoringReal Time AlertsYesNoN/AN/ADashboards & ReportsYesPartial – requires add-onN/ABAM (add-on)Dev SupportDeveloper PortalYesNoN/Acustom portalComposition & EnrichmentService CalloutYesYesN/AN/AXSLTYesYesN/AN/Amessage ManipulationYesYesN/AN/AContract and Documentation StandardsOpenAPI SpecYesNoN/AWSDLContract and Documentation StandardsIterative documentationYesNoN/Acustom portalGeneration SDKYesNoN/ASDK manual generationJSON Schema ValidationYesNoN/AXSDGovernanceUsage quotasYesNoN/AUse of third-party solutionsVisibility ControlYesPartial – requires add-onN/AService Registry & Repository (add-on)API / Service CatalogYesPartial – requiresOn dd,N/AService Registry & Repository (add-on)LifecycleYesPartial – requires add-onN/AService Registry & Repository (add-on)Dependency VisibilityYesPartial – requires add-onN/AService Registry & Repository (add-on)TroubleshootingTraceYesYesN/AN/AAsynchronous LoggingYesNoN/AN/ACustom ReportsYesNoN/AUse of third-party solutions to process logsMessage TranslationXSLTYesYesN/AN/AMessage Mapping WizardNoYesCustom Mapping Code SnippetN/AAutomatic Translation (eg XML to JSON)YesYesN/AN/AMessage ManipulationYesYesN/AN/AText ManipulationYesYesN/AN/AProtocol TranslationSOAP to RESTYesPartial – some ESBs supportN/AN/ATo HTTP-based RESTYesPartial – some ESBs supportN/Acustom translationDatabase ConnectorYesYesN/AN/ASAP ConnectorNo – some support as addonYesCustom ConnectorN/AFTP ConnectorNoYesCustom ConnectorN/AOrchestrationProcess ChoreographyNoYescustom orchestration with MicroservicesN/ACompensation FlowNoYescustom orchestration with MicroservicesN/ARetry QueuesNoYescustom orchestration with MicroserviçosN/ABatch processingParallel Processing(High Data Volumes)NoYesUse third-party solutions – Data Integration PlatformsN/AJob SchedulingNoYesUse third-party solutions – Data Integration PlatformsN/AWorkload AutomationNoPartial – requires add-onUse third-party solutions – Data Integration PlatformsN/ARoutingStatic RoutingYesYesN/AN/AContent-based RoutingYesYesN/AN/ARules-based RoutingYesYesN/AN/APolicy-based RoutingYesYesN/AN/ALogging & Traceabilitystack TraceYesYesN/AN/ATransaction IdentifierYesNotN/AN/ATransaction ManagementDatabase Transaction HandlingNoYesCustom with MicroservicesN/AXA Transactions (2 Phase Commit)NoYesCustom with MicroservicesN/AWS-TransactionNoYesCustom with MicroservicesN/ARules EngineBRMSNoPartially – requires add-onUse third-party solutionsN/A