DEV Community

Cover image for Teaching you all about APIs in 12 mins
Rohit
Rohit

Posted on

Teaching you all about APIs in 12 mins

Did you know, With every passing day, the use of APIs and new APIs being released is growing massively, almost every application on our phone, web or Desktop is now using some sort of an API. Don't believe me? Do you listen to music through apps like Spotify or YT Music? Do you ever use transportation service apps like Uber? Do you watch movies on platforms like Netflix, Youtube etc? Do you use social media apps like Instagram, Hashnode or Twitter?

If you used/use any one of the apps of those categories above, You've interacted with an API already. You might not know it, but even hashnode(The platform you're reading this on) uses an API. As I said, with every passing day, APIs are growing in demand and new APIs are being built for multiple use cases.

So Today, Give me 5 minutes of your time so I can teach you all there is about APIs and help you get started right away! What are we waiting for? Let's dive right into it πŸ‘‡πŸ»

What are APIs and Why use them?

You may have heard it before - it's short for "Application Programming Interface." It sounds like a fancy term, but it's actually quite simple. Let's break it down.

I am sure you have heard of Application, Programming and interface as separate words with different meanings.

An interface is like a doorway that allows different things to connect and interact. Think of the UI on your favourite app - it's how you use the app and communicate with it. That's an interface. But how do apps communicate with each other? That's where programming comes in.

Application and Programming are self-explanatory, but I will brief you about them anyways. Systems and devices don't understand our language and we cannot exactly write in their language, Programming is a way of communicating with computers, and systems by writing a set of instructions to perform any task. But how do different applications, systems or services talk to each other? That's where APIs come in.

In simple words, An API is a program or set of programs that allow different applications, codes or systems to talk to each other.

Still not sure you understand APIs? APIs act as mediators between a client( Typically an End-user or application) and a Server (The backend which consists of a database, functions etc).

Let's say, you use Paypal. When you click on pay, Ever wondered how is it that the app processes money from your account to the other person? APIs do it for you. APIs take care of going back to the server with your request and processing the request for you and come back with a response. More on this in a moment.

Why use APIs?

As humans and especially developers, we wanna streamline and optimise our systems and processes as much as possible. APIs are one such step in modern software development.

APIs enable code talking to each other and sharing of resources/services across various applications, devices and more.
You can build an API to automate tasks or events like checking the weather and integrate them directly with the application. How cool!
Some might have already seen this coming, The ability to build APIs to automate tasks, and events make it a digital product that can be used as a service or revenue stream for companies. For instance, Twitter recently made their API paid.
You can always learn and build APIs tailored to your use for internal organisation functions too.
Classifying APIs

APIs are of different types with each of them having different strengths, capabilities and use cases. They are not too many though, APIs can be classified into three simple types:

Types of APIs

*Hardware API
*

These are the type of APIs that are used to interact or talk to hardware components like devices or cameras of a device etc
Web API

These are the type of APIs used for code or software to interact with other code/software over a network. For instance, Fetching the score of a Live cricket match or tracking crypto prices
Software Library API

These are the type of APIs used to interact or give direct access to pre-written libraries which have various functions or methods that can be used to add specific functionality to our application.
Here's the part I love about APIs. You can use more than one API or multiple APIs to achieve the same task or integrate various APIs in an application. For instance, Uploading a tweet with an image on Twitter, it uses Hardware API to talk to the camera and get the image, then uses the software library API to apply any effects or filters of your choice, and then uses Web API to publish it on the server so users of Twitter can see your tweet and interact with it.

While you can use multiple APIs in an application, You cannot use all APIs everywhere meaning you need to know about accessibility.

Accessibility of API

Like variables in programming have a scope, similarly, APIs have a scope of who can use them too. What are they?

Public or Open API

These are the most common or widely used APIs since these are open to all for use and typically free. Anyone on the internet can have access to these APIs and can use them in their applications.

Private API

These are the type of APIs built internally for certain organisations or companies. These cannot be accessed but everyone, they can only be accessed by members of the org or people with access.

*Partner API
*

This is the type of API that is used by organisations that are related or have some kind of agreement in place.
So, these are the different types of APIs. With so many APIs out there already, How do you choose which API is the best for your application? More so, how do you build an API of your own? For that, you need to know about the different architectures of APIs.

Architectures of API

There are actually quite a few architectures that one can use to build their own API. I will be writing individual articles on each of these architectures including how to build your own API using certain architectures very soon, so make sure you subscribe to my newsletter here so you don't miss out on them.

For now, Let's take a brief look at different architectures

REST API

A REST API is probably the most widely used API architecture, especially for WebAPI. REST is an abbreviation of "Representational State Transfer". Ever used a food delivery app? Apps like these have menus that you can read from, edit and add to the cart and checkout. Here, your menu is like a REST API, it allows you to view different options, and perform actions based on your interaction.

SOAP

SOAP (Simple Object Access Protocol) defines a set of rules and protocols that describe how software applications should communicate with each other. It typically uses the XML format for data exchange and includes a WSDL, or Web Services Description Language, a file that describes the API's functions and data structures.
SOAP APIs are often used in more complex applications where security, reliability, and error handling are critical. Referring back to our Paypal example, A application might use a SOAP API to transfer funds between accounts or retrieve account information. The SOAP API would define the specific methods and data formats that the application needs to use to communicate with the bank's servers.

GraphQL

GraphQL is a relatively new API architecture that was developed by Facebook. GraphQL APIs use a query language to retrieve and manipulate data, allowing clients to specify exactly what data they need and reducing the amount of unnecessary data that is transferred.

gRPC

gRPC (Google Remote Procedure Call) API architecture is a modern, high-performance framework for building APIs that was developed by Google. It's designed to be fast, efficient, and scalable, making it ideal for large-scale distributed systems.
gRPC uses Protocol Buffers, a language-agnostic binary serialization format, to define the API contract and message format.
gRPC supports streaming and bi-directional communication, which allows servers and clients to exchange large amounts of data in real-time, without the need for multiple round-trip requests.

WebSockets

WebSockets API architecture is a protocol that provides a bi-directional, real-time communication channel between a client and a server over a single, long-lived connection. It's designed to enable real-time communication between web browsers and servers, making it ideal for building applications that require real-time data updates like chat rooms, online gaming, and real-time data visualization.
WebSockets support multiple message types, including text and binary messages, as well as support for custom protocols that can be defined by the application developer.

Webhooks

Webhooks are an API Architecture pattern that is designed to enable data integration across applications meaning able to send data from one application to another in response to a specific event or trigger, without the need for the receiving application to constantly poll for updates.

MTT

MTT (MQ Telemetry Transport) API architecture is a lightweight messaging protocol that's designed for connecting remote devices over unreliable networks with limited bandwidth. It's often used in Internet of Things (IoT) applications, where devices need to communicate with each other over low-bandwidth, high-latency connections.

Quite a few options and A lot to remember? Which is why you shouldn't. Yes, you don't have to learn about all the architectures now and cram them, it's of no good use.

Over time, based on your application requirement and more, pick the one that suits the best for you and start building or using one. As I earlier mentioned, the above is just a gist of API architectures available.

I will be writing blogs focused on each of them from defining and explaining them to building your own API. So, Make sure you follow and subscribe to my newsletter so you don't miss out :)

Now, you understand API types and architecture, But One thing you must've observed that's common in all is sending a Request and Receiving a Response. Are you wondering how exactly the API carry out instructions or makes calls? That's where Request and Response come in. Let's take a look at them

Request and Response

API calls were earlier made using the command line or cURL. Now there are actual tools like Postman out there that make it more easy, visual and human-friendly. You can choose to work with any of them, No wrong choice there. Irrespective of the tools you use to carry out calls, let's see how calls work.

This is something called Request-Response Pattern, which represents how computers communicate over a network. An API is an interface that lets us know what kind of response to expect when we make certain calls to a server.

Let us understand this with an example. Let's make an API call using Github API to retrieve a user's (In this case, Mine) details.

The API call using cURL would look something like this:

curl https://api.github.com/users/TRohit20

The above is a request you are making to the API Endpoint. And the response would look something like this:

It's a JSON File. Let us understand the request call and response more deeply now.

Each API has different types of Request methods that can be used to Read, Write, Delete and Update data or use APIs.

Request methods

When we make an HTTP call to a server, we specify a request method such as GET, POST, PATCH, or DELETE that indicates the type of operation we are about to perform. These are also called HTTP verbs.

In addition to a request method, a request must include a request URL that indicates where to make the API call.

A request URL has three parts: a protocol (such as http:// or https://), host (location of the server), and path (route on the server). In REST APIs, the path often points to a reference entity, like "users" in this case

Paths and full URLs are also sometimes called API endpoints.

But how do you know about the request methods of an API? Take the help of your best friend. Use the documentation of an API to get a better understanding of the API. The documentation has all the request methods and more with code snippets and examples

In fact, You can further optimise your API call by passing on Query and Path parameters.

Query Parameters

Query parameters are a way to pass information or filters for retrieving data. These are often appended to the Request URL followed by a '?'.

curl https://api.example.com/movies?genre=fiction&release=2023

Yes, you can have more than one query parameter passed by using a '&' between them.

Query parameters are given in Key-value pairs
**
Path Parameters**

A path parameter (or "path variable") is a dynamic section of a path and is often used for IDs and entity names such as usernames. These are located directly after a slash in the path. Can be anywhere in the path. It also accepts Dynamic values.
Often used for Entities names and IDs
Passing specific filters or data is fine, Now that you are requesting, what's a response? How does it work?

Response

API responses are the data that is sent back to the client after an API request has been made. A well-designed API response should contain all the information the client needs to understand what happened during the request and what data was returned.

API responses typically consist of two parts: the status code and the response body. The response body contains the data that is returned by the API, such as a JSON object or an HTML page as demonstrated earlier.

Response Status Code

The status code is a numerical code that indicates whether the API request was successful, unsuccessful, or encountered an error.

Status codes have conventions. For example, any status code starting with a "2xx" (a "200-level response") represents a successful call. Get familiar with other status code categories:

Again, you don't have to memorise them all, get a gist and learn them on the go as you work with APIs

Next steps

Now that you have a comprehensive idea of what APIs are, the different types, and how they work on a superficial level, it's time to get your hands dirty.

APIs usage is only growing by the day, learning about them and working with them is exciting. I will try to make them just as exciting for you.

This was the first of a series I am starting today on APIs. Here, I will be writing regular, consistent and fun blogs on API where I go from explaining to implementing and even building your own APIs with different architectures, use-cases and more. Subscribe to my newsletter and follow me on Hashnode Rohit T if you haven't already so you don't miss out on them.

Closing Remarks

That was it for today guys. I will see you very soon again. Until then,

Like |Comment | Share | Follow Rohit T for more!

You can catch me on my socials here, and even let me know how this article helped you, and what would you like me to cover next!

Top comments (0)