APIs For Beginners

APIs For Beginners

·

7 min read

Everyone these days uses a smartphone. People order their favorite food by just clicking a button in an app. People buy their favorite clothes also by just clicking on a button in an app. But have you ever wondered what happens when you click a button? Doesn’t it look like magic? Let’s say you open a food app. Find “Butter Chicken” in the search bar and get a series of responses according to its availability at various restaurants. You click on the restaurant where you want to order from. You place the order and pay. The order arrives. Here you are basically communicating with the restaurant without even messaging/calling the restaurant. But how is this even possible? APIs make it possible. image.png API( Application Program Interface ) is defined in different ways by different organizations. Let’s look at some definitions.

Wikipedia says

“An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software”.

IBM says

“An application programming interface, or API, enables companies to open up their applications’ data and functionality to external third-party developers, business partners, and internal departments within their companies. This allows services and products to communicate with each other and leverage each other’s data and functionality through a documented interface”.

Okay, I believe these definitions sound complex. Let me make it simpler for you by using a standard restaurant scenario that many people use in order to explain APIs to beginners.

A RESTAURANT, YOU & A WAITER

Say, you go to your favorite restaurant today with your friends( I could have even said “ with your girlfriend/boyfriend” to make the example interesting but I didn’t want you to dream already XD. So yes, come back!). So as you go to a restaurant you sit at a table and wait for the waiter to come near the table and pick your order. Before picking the order what does the waiter do? He/She comes up with a menu and you check the menu and select the item of your choice and tell the order to the waiter [ Let’s call this part - Request for food]. Now, after noting down the order the waiter goes to the kitchen and gets your order processed and gets back the requested food to your table [ Let’s call this part - Response]. So here the 3 main entities are YOU, WAITER & THE KITCHEN IN THE RESTAURANT that processes your food and one more important entity is the inventory where raw items are available that are cooked in the kitchen.

kate-townsend-hEC6zxdFF0M-unsplash.jpg So in terms of computer science and tech, I’d say an API is the same as a waiter. YOU are the client, The kitchen that processes the request can be a server/application/device and the inventory is nothing but a database. You can ignore the fact that there is an inventory separately and can include the inventory in the kitchen itself. Similarly, you can include the Database directly connected to the server (or) the server can directly be a database server. Frame 10.png So when we use an API. We(client) specify a request to the server saying “This is something that I want”, the API carries this request (called an API request) and gives this request to the server. Now the server understands and processes the request and gives back a response(called an API response). This response is again carried by the API from the server to the client. So here two entities are communicating with each other with an API acting as a messenger. So the first part of my simple definition would be “ An API is nothing but a messenger that helps in communication between 2 entities here the entities can be applications/devices etc”.

API is a piece of code/program?

chris-ried-ieic5Tq8YMk-unsplash (1).jpg The answer is Yes. An API is nothing but a program (or) a piece of code with some specific functionality. Let’s say you are using swiggy/zomato/uber eats to order food. Here when you click on a restaurant of your choice you get a list of food items available. An API is something that gets you the list. So, an engineer has written a computer program where, if a user clicks on a restaurant the Database of the restaurant is checked and the available items are displayed to the user. So the user makes a request( clicking on a restaurant ) and gets a response ( list of food items).

Who makes APIs?

henry-perks-BJXAxQ1L7dI-unsplash.jpg APIs can be made by anyone. Sometimes a single person makes an API. Sometimes the whole organization makes an API. Let us also understand this using a real-life example. So let’s say you are going to a new place from your home and you don’t know the route. The first thing you’ll do is open Google Maps and search for your destination and reach the destination by following the directions. Google Maps for obvious reasons is coded by the Google team. Okay, now let’s go back to your favorite food ordering app. Other than you ordering food, there are delivery people who deliver food at your doorstep and update it on their smartphone that the food was delivered to your house.

What do you think people use in order to reach your place(Swiggy/Zomato delivery people)? They use their own organization apps to reach your home. But do you think these organizations write code to implement their own maps? The answer is NOOO! They use the Google Maps API and integrate it into their APP. Even Ola/Uber uses Google Maps API in their apps to trace quick routes.

Why are APIs made?

Do you think that the code written to implement Google Maps is easy? No right!. Plus is it really necessary to code something that already exists in the market and can be used? Again no right!. That is the reason why APIs are made. Okay, let’s go into detail with an example. Let’s say you are making an app that scans the human face, recognizes the human, and marks attendance in the class. Now, will you use different APIs for different classes? No, you’ll use only a single face recognition API because the functionality that it needs to satisfy is the same everywhere.

Organizations make their APIs available to the world and anyone anywhere can make use of them. Some APIs are free, some are paid according to the number of API calls you are making. API calls are nothing but the request and response as a whole that we discussed above in the blog. You can see some examples of APIs provided by Google at developers.google.com/apis-explorer , Find APIs provided by Amazon at developer.amazon.com/apps-and-games/service..

Types of APIs based on access

Public APIs

APIs that are accessible to everyone in the world for use.

Private APIs

APIs that are accessible to only some group of people. Let’s say you work at an organization, the organization has some APIs that are only accessible by the people at the organization for internal development purposes.

Types of APIs based on architecture

REST APIs

REST stands for Representational State Transfer. Basically, this architecture makes use of HTTP so it is bound to work on all platforms. In simple terms, HTTP is an application layer protocol that helps client systems communicate with the world wide web. Mozilla org defines HTTP as communication between web browsers and web servers. REST basically tries to identify resources with a unique URL called the API endpoint. Speaking about resources; a resource is nothing but something that an API can get information about. Let's say if you are using a Weather API then the resources you get from this API are weather details of a certain place at a certain date and time. Other than just getting the resources a client can also create resources or edit the existing resources using the HTTP methods GET, POST, PUT, and DELETE. GET is to retrieve a resource, POST creates a resource, PUT is used to edit/replace the content of the resource the record & DELETE deletes the resource.

SOAP APIs

SOAP stands for Simple Object Access Protocol. SOAP is a standardized protocol that focuses more on security and is more complex compared to REST. Companies use SOAP when they are very much security-centric and reliable-centric. This doesn't mean that REST is not secure (or) reliable. SOAP is a protocol and REST is an architecture.

So yes guys, that is all about this blog. Hope you had a good time reading it. Peace!

Credits

Photo by Kate Townsend on Unsplash

Photo by henry perks on Unsplash

Photo by Chris Ried on Unsplash

TastyIgniter