What I want to talk about in "part deux" is server-to-server interactions where there isn’t really the distinction between who is the client and who is the server. Just because you initiated the conversation doesn’t mean that you are the client. Imagine responding to a push advert for an offer of fish and chips by phoning the chippy. They initiated the conversation, but they are the server. So who are you in this scenario? The whole client/server relationship breaks down. Let’s just talk about autonomous agents working in collaboration with others where the objective is to be able to communicate whilst still working asynchronously so that the interaction between the two agents doesn’t block the activity of either.

Application Programming Interfaces - APIs - are everywhere and take many forms and styles.

Which is fine if you know how computer programs work and the kind of things they need to communicate with each other.

“...a way for two or more computer programs to communicate with each other”.

How to explain an API to a non-technical person? “Oh, APIs are like waiters in restaurants…” you start off glibly, not knowing the deep water into which you’re about to wade.

It’s a commonly used analogy. I’ve used it myself many times: An API is like a waiter…