Imagine you’ve got a black box with a big red button on top. When you press the button, the black box lights up.
In this example, pressing the red button means the black box will light up. There is an understanding between you and the box that says “if I press the button, the box will light up.”
Think of an interface as the understanding between you and the box. Now let’s extend the metaphor:
Instead of your finger, you’ve got a computer with – you guessed it – a mechanical finger. You can tell the computer to press the button, and the box will light up. See how this is still functionally the same? You told a computer to do your bidding, instead of your finger.
Let’s extend even further: instead of hitting a mechanical button, let’s pretend that you have to say “Light Up!” to the box in order to light it up. If you could program your computer to say this, the black box will light up. Still functionally the same thing.
Now imagine instead of saying this verbally, you write it out as a written command for the box. And – this part is the most critical – the black box tells you the exact wording to use: lightMeUp(). The box also has an instruction manual on how to submit this command to the box.
API stands for Application Programming Interface. In this example, the application is the box itself. The interface is the understanding between you and the box. In other words, it is an interface for programming the application (the box). The API, therefore, lets you know how to write out the commands to make the box do stuff.