“So… what is an API?” a young woman asked, gesturing at my API Craft Conference t-shirt as we stepped down the escalator together. I hesitated a second, not because I haven’t answered the question dozens of times already, but because I had.
“API stands for Application Programming Interface. It is the interface that allows software applications to communicate with one another...” But as I started with this explanation, her eyes glazed over while she politely nodded. Through this strained conversation, and dozens more, I finally realized that APIs can be understood through 3 analogies.
A Toy Box
An API is like this toy box. Data in the defined forms, such as circles or triangles, can be taken through the lid, or interface, and let through the correct hole. The API expects a certain format, and will reject data in the form of, say, ninja sharks. This forces clients to organize the inputs according to the designer’s specifications and helps set expectations for the transaction.
Data can go in, and it can also be pushed out using an API. This would also be useful because outputs would come out in the place and in the way users expect them to. Squares, for example, would be expected to come out the square hole, not circles.
When using a wall socket, a user doesn’t have to understand the concept of electricity or know what’s going on behind the wall. Similarly, the user doesn’t have to care what happens inside the box. If you wanted to rearrange the blocks or improve the inside of your box, it doesn’t affect your users. They wouldn’t have to relearn how to use the box because the interface is consistent.
Then, an API can be thought of as an agreement, or contract, between two pieces of software saying: “If you give me this instruction, I will perform this action or return this information.”
Who doesn’t love Legos? Lego bricks have a universal way of connecting to each other through small bumps and holes, which can be considered an API. This provides a simple and structured way to allow pieces to be built together in different ways. Similarly, software can connect together through APIs to create new and interesting mashups.
Some APIs can be a service for developers. Every time they write a new program, developers don’t have to start from scratch. They no longer have to build a core application that tries to do everything. Instead, they can contract out certain responsibilities by using already created pieces that do the job better. APIs become the ultimate integrators that fuel product collaboration and innovation.
A Deck of Cards
The power of opening up our data and services to others, through APIs, can also be illustrated by comparing board games to cards.
Or watch here: http://www.youtube.com/watch?v=7r7QpIDEI_o
When you have APIs, the customer doesn’t throw away your tools when they grow and change. Instead, they can change how they interact with your product, given their needs, and the tools provide flexible experiences.
Now, we should all be able to explain what APIs are without spouting too many technical terms and business jargon. And here’s the Twitter headline: APIs are standardized tools for software to communicate with other software, leading to faster development and innovation. Of course, there are different types of APIs and these analogies don't cover them all. We will explore further in future posts.
For everyone else out there, how do you explain APIs to others? Comment below. Are there examples you’ve stumbled upon?