What exactly is an API? (Part 1)
Fun Fact: At one point or the other, you have interacted with an API.
If you are wondering how, let’s go through a couple of things you might have done, at least once, to find out if you’ve made use of an API.
So have you ever found yourself ordering an item online, and you had to pay with your credit/debit card or PayPal? Did you ever decide to go on a trip and then just before you packed your bags, chose to do a quick check on your phone to find out what the weather at your destination was like, thus determining the kind of clothes to pack? Have you stalked your ex on Instagram, or Facebook by inputting their name in the search bar? Or have you updated your LinkedIn profile to show your new role or job? If you’ve done any of these things, or are currently doing so as we speak, congrats! You’ve just interacted with an API, or at least you’ve done so at some point.
Understanding an API
I don’t want to believe you’re freaking out and going, “Oh, my goodness! I’ve interacted with an API, and I don’t even know what it is.” Have no fear. I’ll show you what it is in a second.
API is an acronym for application programming interface. Do you remember how we’ve previously described the client and server, and the parts they play in a web system? How that the client sends a request to the server, and the server responds to that request. The API is that part of the server that receives the request that the client sent, and sends back a response.
Now an API is designed to receive requests from external applications apart from the application in which it is built. So because of this, it is a very useful gateway for different software applications to communicate with one another. What does this mean? Imagine we have an application that shows a list of users, as well as some outdoor events, happening this weekend, but we need a way for the users to access the location of the events through a map. Instead of building the business logic for a map from scratch, we can leverage an already built platform with an API like Google Maps. It really doesn’t matter if both applications are built using different languages or tools, and we totally do not need to know the logic used on the Google Maps software. Once we have access to the API, all we literally need to do is figure out how to integrate it into our application, because it is suited to work with any application.
Now, understand that the API is not the database or server, but the gateway or access point for the server. Let’s look at it this way…you go into a restaurant and then place an order. The waiter comes, takes your order, and brings to you exactly what you order. You can look at the waiter in this case as an API. He takes a request, tells the system what to do, and then delivers what you need.
An API is a software-to-software interface, and what this means is that it’s different from a user interface that a real person can interact with directly by the click of a button or a link. When you go to the grocery store to purchase food items for the week, you might make payment using your credit/debit card. The POS machine, which is a point of sale machine, or the website (if your purchase is online), is what interacts with this interface. It’s responsible for sending a request to the remote application with your card information to verify that your information is correct. The remote location then sends a response back through this interface to show that the payment was successful or not, depending on the information received.
Essentially, a company can allow third-party developers to make use of their application data and functionality through the use of an API. As a developer making use of the API, as I said before, I do not need to know how the API was built. I simply need to know how to use the API to have access to the products and functionality that my application requires.
Types of Requests
So let’s talk briefly about how APIs actually work. Basically, the client app initiates an API call through a URL.
There are four major types of requests that could be made.
- GET request
An example of this will be the kind of request you make when you pull up your list of followers on Instagram, or when you enter an item name in your Amazon search box and click on Enter. You basically fetch a whole bunch of data. And for you to get this data, you have to make a GET request. - PUT request
You typically do a PUT request when you’re trying to make an update. So for example, when you’re trying to update your LinkedIn profile, update an already existing order on Amazon, or you’re trying to update just anything, you’ll have to make a PUT request for that to work. - POST request
You make a POST request when trying to create a resource of some sort. For example, creating an order on Amazon or any other e-commerce store. - DELETE request
As the name shows, this kind of request is what you send when you need to remove or cancel a resource. So for example, if you created a blog post and you want to delete it, you make use of a DELETE request.
After the API receives any of these requests — a GET, PUT, POST or DELETE request, it makes a call to the external server and the server then sends you back a response. The API then transfers this response data to the client application that requested it in the first place.
And that basically, is how an API works.
In the next post, I’m going to take you guys through why businesses use APIs and discuss some APIs commonly used by software teams.
