API - Agreement to communicate

In the previous post, we understood what an API is using simple examples like translators, keyboards, and TV remotes.

Being a human being we always look out for a connection or a way to connect with another being. From 2020 human being have been heavily relying on Social Media Apps to communicate ( example: posting foods on instagram and making it foodagram, posting workout videos or any other videos to ocnnect globally.

Let's explore how these app communicates via Server to enterntain us, to enlighten us or to train us.

When you open Instagram, Facebook, X, or LinkedIn, a lot is happening quietly in the background.

1. Posts are loading
2. Likes are being counted
3. Comments are appearing
4. Notifications are updating

Our beloved device (phone, tablet, computer etc) is not doing all of this by itself.

Different systems are constantly talking to each other via API - the contract agreed upon to communicate.

But how exactly do they talk?

There are multiple ways communication through APIs. Let’s explore most common ones.

1. REST APIs (the most common one)

REST is the most widely used way for applications to communicate today.

Think of REST like ordering food from a menu.

You ask for something specific.
You get exactly that.
Clear request, clear response.

In social media apps, REST-style APIs are often used for things like:

1. Loading a list of posts
2. Fetching user profiles
3. Showing comments under a post
4. Getting notification counts

Why REST is popular

1. Easy to read for humans
2. Easy to understand for developers
3. Works well over the internet
4. Simple structure

Because of this, REST APIs are often the first choice when:

1. Apps need to fetch data
2. Mobile and web apps talk to servers
3. Readability and simplicity matter

2. XML-based APIs (older but still around)

Before modern APIs became popular, many systems talked using XML.

XML is more verbose and structured. It looks heavier, but it is very strict and well-defined.

You’ll still find XML-based APIs in:

1. Older enterprise systems
2. Banking and financial integrations
3. Government systems
4. Telecom platforms

Why XML is still used

1. Very strict structure
2. Strong validation rules
3. Works well for complex, formal data contracts

Readability

XML is harder for humans to read compared to REST-style responses.
But machines love its strictness.

That’s why XML APIs are often used where:

1. Precision matters more than simplicity
2. Systems are large and slow to change
3. Stability is more important than developer comfort

3. GraphQL (asking exactly what you need)

GraphQL is a newer way of communicating through APIs. Instead of the server deciding what data you get, the client asks exactly what it wants.

Imagine going to a restaurant and saying:
“I want rice, one piece of chicken, no curry, and extra salad.”

That’s GraphQL.

In social media apps, GraphQL is useful when:

1. Screens need different shapes of data
2. Mobile apps want to reduce data usage
3. Multiple data sources are involved

Why teams use GraphQL

1. Avoids over-fetching data
2. Flexible for frontend teams
3. Reduces the number of API calls

Trade-off

GraphQL is powerful, but more complex to design and maintain.
It’s often used by teams that already have mature systems.

4. Event-based communication (not asking, just informing)

So far, all examples were about asking for data.

But sometimes systems don’t ask. They just inform.
This is called event-based communication.

Example:

1. You like a post
2. The system emits an event: “Post liked”
3. Notifications update
4. Analytics systems record it
5. Recommendation engines react

All without you waiting. Where this is used

1. Notifications
2. Activity feeds
3. Analytics
4. Real-time updates

Event-based APIs are common in:

1. Social media
2. E-commerce
3. Financial systems
4. Real-time platforms

They help systems scale without constantly calling each other.

Conclusion

Social media apps don’t use just one type of API. They usually combine multiple approaches which differ in:

1. Readability
2. Structure
3. Flexibility
4. Use cases

But the core idea remains the same.

One system talks.
Another system listens.
Both agree on how the conversation works.