Correlating Event-Driven Architecture and API-led Connectivity

API-led connectivity illustrates the three tiers of Experience APIs, Process APIs, and System APIs. 

Although application components exchanging events can be organized similarly, this is not an intrinsic part of Event-Driven Architecture.

API-led connectivity restrains communication models according to these three tiers (essentially top to bottom), whereas application components corresponding events do not theoretically have to adhere to the equivalent communication pattern restrictions.

API implementations typically have well-defined static dependencies on other APIs or backend systems or both). While related contacts may emerge in Event-Driven Architecture at runtime, there are no static dependencies between the application elements exchanging events. Instead, these application components only depend on the exchanged event types, the destinations, and the message broker hosting those destinations. Furthermore, event consumers may change dynamically at any time, thereby dynamically reconfiguring the relationship graph of the application components in an Event-Driven Architecture, without the event producers becoming aware of that change

Event-Driven Architecture expects a message broker as an added component of the Technology Architecture, with all application components who want to exchange events having to accept on the same message broker (this is not a strict requirement in some broker architectures).

API-led connectivity and in particular application networks are defined by the API-centric assets published for self-service consumption. The equivalent for Event-Driven Architecture would revolve around target and event types. Fortifying NFRs by applying API policies in Anypoint API Manager on top of existing API implementations has no equivalent in Event-Driven Architecture on Anypoint Platform.

Trading Events Among API Implementations

The compatibility requirement for the 'Customer Self-Service App' product leads to the conclusion that the command-query paths must be 'short-circuited' such that also very recent request submissions, which are not yet exposed by the target system, can be retrieved via the 'PAPI' and 'SAPI.'

One way of architecting this 'short-circuit' is within a proposal not unlike event sourcing on top of CQRS.

• The 'SAPI,' after transmitting a request submitted to the target system must also publish a 'Request related' event.
• The 'SAPI,' in addition to retrieving data from the target system, must also consume 'Submitted' events, store them, and include them in the search results it returns to its API clients, specifically the 'PAPI.'
• This amounts to a non-API communication channel between the 'SAPI' and the target system that follows the general architectural principles of Event-Driven Architecture.