A calm API uses situational awareness

In “Now Urbanism” Jan 13, 2011 on Informal Urbanism Celine D’Cruz explains:

“It’s important to look at all these aspects … In 20 years what will the structure look like … what do we have to do to make it simple … it’s not so complex to repair”

This post is part 2 of the series "You don't manage the API, the API manages you", which is a story of my experiences with API's over the last years and by no means a guideline for others.

In my first post, I had argued that the the distributed model of stand-alone API gateways is interesting, because it has some semantics from within the system, but no tools on the market fully support it. While there are some standards, like RFC 5988 and JSON-LD, and some implementations like OData, if you like XML/Atom, JSON API (Katharsis) or HAL/ALPS (Spring Data Cloud), they are very limited and with it limit the use of REST itself.

You don't manage the API, the API manages you

We live lives that are waveforms constantly changing with time, now positive, now negative. Only at moments of great serenity is it possible to find the pure, the informationless state of signal zero.

Gravity's Rainbow

Kick-Off for a 5-part series on API's

Inspired by a good, simple, API best practices post from Yahoo, I figured it might help to collect all the stuff I've learned in different companies and projects over the last years on API's - anything non-trivial beyond 12 Factor App, Web API Design and Serverless Architecture. For me, API's are the uniform access point to one or multiple systems. For the sake of this article I exclude API's within the same binary here, so you could argue I speak about stand-alone API's if you want (I don't like the term Web API or Front-End API too much).

Stand-Alone API's, and with it Microservices, are being promoted as "SOA, the good parts". Here, an API as front end to multiple systems is lean approach to SOA with right-sized governance, less canonical data models, and a distributed, scalable, containerised, architecture. Quite simply though, they are just a natural evolution of open ecosystems with ubiquitous, uniform HTTP interfaces, propelled by contemporary service-based business models leveraging duck testing for continuous delivery. A good example of such an API is Firebase for instance, a portal to a PaaS.

Over the course of this week I will share a few ideas I stumbled across in the last years. Some of them might have worked, others not, on some I might have worked directly, on others not. This is not a tutorial, this is a story.