Tech Crunch contributor Chet Kapoor recently proclaimed “the future of coding is here and it threatens to wipe out everything in its path.” If you missed the article, you can read it here. It’s filled with the usual influencer lingo (“disruption”) and scare tactics (“a major risk for developers and companies who don’t [adopt]”).
But what does API-first really mean for product-based businesses, specifically those selling electrons?
To answer that question it’s important to get level set on what an “API” even is anyway. It stands for Application Programming Interface, which is a fancy way of describing a method for how one piece of software can communicate with another piece of software.
The “interfacing” between the systems is simply an exchange of data akin to watching How To videos on YouTube — somebody shows me how to fold a fitted sheet and then I can fold a fitted sheet by following those instructions.
APIs are neither new, nor threatening. And they certainly aren’t going to wipe out everything in their path. They are as old as software.
So why is everybody suddenly talking about APIs?
To answer that question I want to take you back in time, to 1908, when the Ford Motor Company unveiled the Model T.
The Model T wasn’t the first car and it was not Ford’s first car. It also wasn’t the first mass-produced automobile. What it was was an exceptionally affordable car (made possible by advancements in production line efficiency that Henry Ford oversaw himself).
Unbelievably, at its lowest price point the Model T cost just $260, which is a mere $6,900 today. The car was a huge success, selling over 16.5 million over 19 years. The Model T still ranks number eight in the list of most sold cars of all time.
Perhaps the most important factor to the success of the Model T was its design. In particular, it’s interchangeable parts. The Model T could be a tractor or a portable engine. I compare the Model T to a RESTful JSON-based API today.
“REST” is an architectural style of making APIs and its core tenet (the “S”) is that it’s stateless. What this means practically is that you can ask it anything, at anytime, and get the answer you want. Imagine asking a person their age before asking gentler qualifying questions like “what’s your name?” and “what do you like to do for fun?” As humans we need a little warming up, but with APIs you have license to seek out only the information you want. “Hey system, what’s the temperature in Los Angeles right now?” System: “45 degrees.” Thanks, system. Got what I wanted.
Much like the Model T, RESTful APIs “disrupted” by bringing a well-established form of application interfacing to the masses.
How?
JSON stands for JavaScript Object Notation — a super lightweight data-interchange format. It’s easy for machines to parse and generate and, more importantly, it’s easy for humans to read.
Before this approach, APIs were complex, difficult to understand, expensive to implement and hardly interchangeable.
I remember an experience of building an eCommerce site in the 90s. I had to implement shipping calculations into the checkout workflow. At that time Fedex had an API. I would argue that it would have been easier to operate a space shuttle than to implement their API then. The only information we needed to query was price — to calculate shipping product X, using service Y, from point A to point B. It took months to complete.
Today shipping APIs are super simple. Using REST and JSON you can set up a call (a specific request for information) and get your answer back in minutes.
And shipping is just one example. APIs exist for virtually everything you can think of. Want to know what the weather will be in Los Angeles tomorrow? No problem. Need to know how many flights run between New York and Chicago daily? Easy. Care to see how many friends I have in my Facebook network? Piece of cake.
A developer in today’s world can easily implement APIs today because they are simple to understand and there are readily available frameworks for creating and handling them. APIs can be mixed and matched too — you can query information from multiple sources (or applications) and bring it all back into one place: your software product or website. You can also send information or features from your software product to somebody else’s.
That last point is what’s most vital to the conversation. If you have valuable services or data, you have to think about APIs. Specifically, creating your own API and a developer community around your API. A developer on a mission to solve a problem is inevitably going to come searching for information. Don’t you want your data to be right there waiting with open arms? Do you want to be the source of valuable information that dozens of other platforms and hundreds of thousands of users rely on?
The old school mentality of guarding your information and services in order to control pricing or have clients beholden to you is crumbling. Transparency and cooperation are at the heart of the open-source movement and APIs are its lifeblood.
Tech Crunch says that you have to think API-first in today’s world. That’s true as an engineering strategy. But even before you set your developers down the path of building your API, you, management, need to become the architect. Ask yourself, what information or functionality of ours offers the most value? Where else but in our own yard can we seed that value so that it can be found, used, revered and, ultimately, depended upon.
