More often than not, we use and say stuff without thinking about what is underneath. And sometimes that’s just the way it has to be; it is necessary for our brains to filter certain things in order to function. Just think about language, for instance. We speak and we write and we read and most of the time we are not processing what is happening. We are not actively thinking about conjugations, or pronouns or where a sentence starts or ends (verbally, at least). But it is there. Oh, it most certainly is there, and while we don’t think about it now, there was a time when we had to learn about it (either empirically or formally) to know how to use it naturally.
Well, something similar happens with the internet.
We use it every day, we browse, we read, etc. but we rarely think about what lies behind the scenes. That is, until we try to make software. Then all those things we took for granted start appearing and we suddenly notice it’s not just magic (although in a way it still is :)). We notice most things related to software work with a front-end and a back-end, and that there has to be a way to connect those two worlds. Enter: APIs, or Application Programming Interfaces.
If you’ve ever heard about APIs, there is a very high chance you have known about it through the waiter analogy. For everyone who is unfamiliar, it goes like this:
Your software is like a restaurant, right? On one side, you have your tables, where clients will seat down, look at the menu and order their food. This resembles your front-end, where users get to your web app and check out what is available for them to do with it.
On the other side, you have your kitchen, where you have your necessary ingredients and tools to cook and get the orders ready. This resembles the back-end, where you might have databases, and workflows to create what the end-user gets to see when he interacts with the product.
But how can you connect your dining area to your kitchen? How will the chef know what the clients want to eat? That happens through the waiter. The waiter will take the client’s order and notify the kitchen. When the meal is ready, he will take it back to the dining area for the client to eat. This same thing happens with APIs. APIs take the interaction the user is having on the front-end to the back-end. The latter one does what the API asked on behalf of the user, and then it takes the product back to the front-end, resulting in what the user asked for.
For a real world example, let’s pretend we need to search for electronic products on Amazon. The front-end will have to ask the back-end for this information via the API. This is known as a request. What the API will do is define a language to communicate how the request will be sent to the back-end to get those resources.
But while everyone might use APIs for some things, like searching for songs or artists on Spotify, there are others that are only available to a specific group of people or to the team responsible for the development of a certain software, like billing information or user data. This divides APIs into public and private ones correspondingly.
And boy oh boy, this is just a glimpse into the world of APIs. If you would like to know more, we strongly suggest you check our course on APIs, get a broader view, and even get to know how to connect an API. What are you waiting for? It’s free!
Other courses that might be of interest: