API Definitions Influence API Design

I was having a conversation recently about whether I should be putting my API definition or my API design work first. Which comes earlier in the lifecycle of an API? The conclusion was to put the definition first because you need a common set of definitions to work with when designing your API(s). You need definitions like HTTP and HTTP/2. In 2017, you should be employing definitions like OpenAPI Spec and JSON Schema. These definitions help set the tone of your API design process.

In my opinion, one of the biggest benefits of designing, developing, and operating APIs on the web is that developers have been forced to pick up their heads and pay attention to what everybody else is doing and wanting. I suffer from this. Doing web APIs, providing my own, and consuming third-party APIs forces me to pay attention to providers and consumers outside my bubble. This is good.

Common definitions help us elevate the design of our APIs by leveraging common concepts, standards, and schema. Every time you employ ISO 8601, you have to think about folks in another time zone. Every time you use ISO 4217, you have to think about people who buy and sell their products and services in a different currency than you. When you use Schema.org, your postal addresses considers the world beyond just US zip codes and considers a worldwide web of commerce.

I am placing definitions before design in my API research listing. In reality, I think this is just a cycle. Common definitions feed my design process, and the more experienced I get with design, the more robust my toolbox of API definitions gets. Ultimately, this depends on what I'm calling a definition — but for the sake of this story, I am considering the building blocks of the web as the first line of definitions and the definitions that are using OpenAPI Spec and JSON Schema as the next line of definitions. Definitions influence my design process, and the design process is refining the definitions that I am putting to work.