What Are Events? API Calls

It is always interesting to note how even today's Cloud giants continue to draw a largely imaginary line between Synchronous and Asynchronous HTTP Requests, such as in the case of a typical REST API call. This line, we are asked to believe, very clearly separates Synchronous Requests – where the Request is made and the caller holds the line until receiving a Response from the relevant HTTP API Endpoint – from Asynchronous Requests – where the caller fires off their Request, (typically) gets a 202 Status Code in reply, and then waits for the actual API Response via some other channel; such as a Webhook, WebSocket, or using the 'HTTP Polling' Pattern described by Microsoft in its Asynchronous Request-Reply pattern Article.

We read in this same Article that: "Most APIs can respond quickly enough for responses to arrive back over the same connection… In some scenarios, however, the work done by [the] backend may be long-running, … [and] it isn't feasible to wait for the work to complete before responding to the Request. This situation is a potential problem for any synchronous request-reply pattern… Some architectures solve this problem using a message broker to separate the request and response stages… But this separation also brings additional complexity when the client requires success notification, as this step needs to become asynchronous."

What is quite unbelievable about this text from Microsoft is that Synchronous Request-Response complexity is far lower in their analysis primarily because they fail to notice it. We are told that using a Broker "brings additional complexity when the client requires success notification, as this step needs to become asynchronous." We are not told what happens when a Synchronous API Request is made, and there is a timeout. Any idea which party is responsible for managing recovery? Any idea what happens if a second – duplicate – API call is made by the client, resulting in a duplicated resource – such as a duplicated Bank Payment – on the target system? How can the client ever know if the original API Request resulted in the creation of the requested resource in the case of a timeout or a sudden network failure? Isn't that also a complex problem to manage? Should we bother to think about it?

The reality is, instead, much different from what we have been asked to believe for the last twenty or so years. Every HTTP Request – whether Synchronous or Asynchronous – represents an 'Event' in the EDA context. Once an API Request has been received by a target system – I believe I can confidently assert without the help of any grammarian – the API has, at that moment, been 'RequestED' to perform some work. This reality is laid plain by the example I have just given of a timeout: it is most often the case that the target system will do the work that was 'Requested' of it by the Synchronous API call, regardless of the fact that the caller never receives a (Synchronous) Response confirming that the work was successfully performed.

For all the reasons just mentioned, I believe we should start calling apples, apples. API calls always represent an 'Event,' so those invocations should, as such, always be represented in exactly that format using the 'Requested (R7D) Event Pattern' that I proposed two years ago. Anyone taking the few minutes necessary to read about this Pattern will also learn that it offers a very significant benefit that is completely unavailable to us when using an 'old school' Request-Response approach, whether Synchronous or Asynchronous.