An API is an Application Programming Interface. Let’s break down what each part of that means.

An application is anything that lets you perform a specific task that isn’t a core function of the thing running it. For example, receiving a phone number on a smartphone is a core function of the device, but if you want to do something more important like taking a selfie where you look like a dog, you need to download a specific application made for doing just that.

In some ways you can think of an application like a toaster. You plug it into your power source and it does a specific task. The electricity in your home was previously incapable of producing toast until you installed the toaster. Smart move. Toast is delicious.

Programming is getting a machine to perform an operation or a set of operations by giving it instructions. Let’s go back to our provider of warm, slightly browned bread: the toaster. You’re all set up with your shiny new toaster, and it’s time to make some delicious sourdough toast. You’ve even gone out to the store and bought the fancy European butter (unless you’re in Europe, where that’s just butter). Now you need to give the toaster some instructions to tell it how dark you want the toast to be. You yell “HEY TOASTER, MAKE MY TOAST LIGHTLY TOASTED!” But the toaster doesn’t listen to you, and stares at you like you’re a fool.

Next time you should read the instructions. You need to use an Interface that the toaster understands. If we instead turn the toast darkness dial, we are now giving the toaster instructions in a way that it expects and understands. That’s an example of “application programming”—you’ve told your application how you expect it to behave by giving it instructions. But they didn’t mean anything until we had an interface that provided those instructions to the toaster in a way that is meaningful to both us and the toaster. An interface is a connection point that allows some interaction to take place between discrete components.

Playing by API rules

The cool thing is that the components don’t care about how the other is going to act, as long as it plays by the rules. For example, think of the standard electrical wiring in your house. You can plug any device into a power outlet, and as long as it follows the rules defined by the system (it can operate at the right frequency and voltage) it will work.

Interfaces are not just limited to hardware like a power outlet or a dial on a toaster. They can also describe connection points between software. Think of any software that uses plugins or add-ons, such as your browser extensions, or macros in Excel. Those extensions are interfacing with the rest of the browser or the rest of the spreadsheet via software connection points; in fact, they are talking to those applications via an API.

APIs describe a set of expectations, but they don’t actually describe how those expectations are going to be implemented and used. You can’t open up an API on your iPhone or your laptop and run it like an application. APIs are generally invisible to end users, but you use them every day without realizing it. You interact with real, concrete implementations of APIs rather than with the APIs themselves.

Web API examples

For example, your Twitter client on your smartphone plugs into the Twitter API to perform certain tasks, such as showing tweets by people you follow or posting a new tweet. As long as the Twitter client you are using adheres to the expectations of the Twitter API, it works. The API doesn’t care if you’re using Android or an iPhone or if the code using the API is written in Java or Objective C. Read more about what we at SendGrid have learned about APIs over the years.

Let’s think back to the toaster. In order to tell the toaster how we wanted our toast, we had to turn a knob that is hardwired to the heating element. But imagine if our toaster had an API to describe and handle instructions like “change the toast setting” or “start toasting” and instead of being wired directly to the hardware, the knob interfaced with an API? Remember that the API doesn’t care what’s talking to it, only that whatever is talking to it follows the rules. The knob being turned would tell the API “change the darkness setting”, and the API would then apply that setting to the toaster.

Now that we have a layer that abstracts the interface, we could add a voice module that knows what we mean when we yell that we want darker toast. The voice module code would interpret the command, translate it so it can communicate with the API, and the API would again communicate with the toaster to affect the necessary changes. Now we’ve got a toaster you can yell at! What hath science wrought?

Update: Someone actually hacked together a toaster you can talk to earlier this month (see left).

If you’re interested in learning about SendGrid API’s, download the SendGrid API Guide. And look for my next API post, which will break down the different types of APIs.



Brandon West
As Director of Developer Relations for SendGrid, Brandon's focus is on empowering developers to build things, gathering feedback for new features and improvements, and fostering a cooperative developer community for anything that needs email integration.