How to Explain APIs to Your Parents (Or Your Sales Team)
Author’s Note: I am not a mechanic. I have never built a car. The views expressed herein do not represent the views of cars everywhere.
I have spent the last four years trying to understand APIs. Whenever they have been explained to me, they inevitably are drawn on a whiteboard like this:
Let’s start from the beginning.
Think of your product – in our case, MediaMath’s TerminalOne – as a car. You have the body, the steering wheel, the seats. These are the parts of your product that most people see and interact with, so we’ll call them the user interface (UI). In the case of T1, the UI is what you see and click on and type into.
In the case of software, your “engine” is made up of many different databases, reporting engines, servers, bidders, etc. It’s these individual pieces working together to power your product’s engine that developers call “services.” And while with a car, you can’t easily access one piece of the engine and use it to power a wholly different machine, in the software world, you can – but you’ll need to build APIs first.
APIs (application program interfaces) can be thought of as the plugs and cords to individual services (credit to my colleague Jake Gardner for help with this analogy). Think of how an iPhone uses a special cable that can only transfer certain information (photos, music, etc.) between certain other products. Try plugging that same cable into your air conditioner, and nothing happens. Coolant data doesn’t travel to your phone, and photos don’t travel to your air conditioner. APIs are like those special cords. They are specialized communication protocols that different services use to talk to each other. Each API will be written to make it possible to access information unique to that service.
But think of the possibilities you could open if each service were built with these plugs and cables! Perhaps you’ve got dreams of building a temperature controlled treadmill, and you to use the air conditioner from the Mini, only you can’t purchase just that feature from the car manufacturer. This is what open API development is all about: Making it possible for people to access software feature by feature or service by service to build all new, incredibly powerful products.
Over the last couple of years at MediaMath, we’ve been hard at work building these plugs and cables for T1 services. We have clients who have innovative ideas for bidder exhaust – all the information of every bid we’ve won, lost, or passed on – so we’ve built an API to our bidder’s firehose of data. Others wanted to build a version of T1 in their native language, so we gave them access to every single service, and they built their own T1.
A great car demands great parts, and we think our carburetor, crankshaft, ignition, and catalytic converter are so great that they should stand on their own and be sold on their own, and that by selling the parts on our own, we’re letting marketers build the best possible car for their need.
We are trafficking hundreds of terabytes of data a day and millions of impressions a second. We can’t even begin to fathom every product idea that could possibly be built using this information, so instead of locking it in our silos, we want to build access channels and empower the ad tech ecosystem with it. We can’t wait to see the super-charged products they’ll come up with.
APIs are works like those special cord and they much specialized communication protocols that varies services use to talk each other, each API will written to make it possible to use unique data.