Rockford Lhotka

 Monday, June 18, 2018
« Windows Server heads toward End Of Line | Main | In place list editing in Razor Pages »

In my microservices presentations at conferences I talk about APIs like this. I go into more depth in my presentations in terms of the background, but these are the high level points of that section of the talk.

From 1996 with the advent of MTS, Jaguar, and EJB, a lot of people create a public service API with endpoints like this pseudo-code:

int MyService(int x, double y)

That is not a service, that is RPC (remote procedure call) modeling. It is horrible. But people understand it, and the technologies have supported it forever (going back decades, and rolling forward to today). So LOTS of people create "services" that expose that sort of endpoint. Horrible!!

A better endpoint would be this:

Response MyService(Request r)

At least in this case the Request and Response concepts are abstract, and can be thought of as message definitions rather than types. Not that hardly anybody thinks that way, but they should think that way.

With this approach you can at least apply the VB6 COM rules for evolving an API (which is to say you can add new stuff, but can't change or remove any existing stuff) without breaking clients.

However, that is still a two-way synchronous API definition, so achieving things like fault tolerance, scaling, and load balancing is overly complex and WAY overly expensive.

So the correct API endpoint is this:

void MyService(Request r)

In this case the service is a one-way call, that can easily be made async (queued). That helps the mental adjustment that Request is a message definition. It also makes it extremely easy and cost-effective to get fault tolerance, scaling, and load balancing, because the software architecture directly enables those concepts.

Monday, June 18, 2018 9:54:09 AM (Central Standard Time, UTC-06:00)  #    Disclaimer