APIs

In 2002 Jeff Bezos issued the now infamous API Mandate which stated the following:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

Now, at the time creating APIs were not as easy as they are now, so building these interfaces would take time.

As a software engineer, we would never make our database directly available to consumers.

Instead, we would always create an API.

I see data contracts as being at the cross-section of best practices.

In particular, they take the best practices from APIs, Data Governance, and Platform Engineering.

JSON Schema is the most widely adopted representation of JSON APIs. As stated on the website:

A great analogy for a data contract is an API. So, let’s walk through how I’d decide if I want to build something important to me on a particular API.

I’m writing this on the train back from Paris, having spent the last few days at the apidays conference, where I gave a talk titled “Data contracts: The API for Data”. I have a lot of digest and plenty of notes to go through! But one think that struck me is the similarities between software and data.