Every API Type Explained

An API (Application Programming Interface) is essentially a set of rules and tools that allows different software applications to communicate with each other.
Think of it like a waiter in a restaurant: you (the user/app) tell the waiter (the API) what you want from the kitchen (another system), and the waiter brings back what you requested without you needing to know how the kitchen actually prepares it.

There are many types of APIs that can be implemented for different applications to communicate.

REST

REST stands for Representational State Transfer. It is the most common type of API that a developer implements for building full stack applications.

It uses the same http method to get data which is used for web browing as well.

A REST API works on the client-server model. The client (like a mobile app or web app) sends a request. The server (which holds the data) sends back a response, usually in JSON or XML format.

Example,

Request:

GET https://api.example.com/users/1

Response:

{
“id”: 1,
“name”: “Aarav”,
“email”: “aarav@example.com”
}

To perform the CRUD operations on the data, REST has the following methods –

MethodPurposeExample
GETRetrieve dataGET /users
POSTCreate new dataPOST /users
PUTUpdate existing dataPUT /users/1
DELETEDelete dataDELETE /users/1

SOAP

SOAP stands for simple object access protocol. SOAP is the one of the oldest method of communication of system over the network. It is more formal and strict way of communicating in the field of network applications.

One of the advantage of SOAP is that is it protocol independent. This means that it is not necessarly dependent on the http protocol for communication. It can also run on other protocols like SMTP, TCP or other protocols. However, it is seen that generally it is used with http only.

The standard structure of SOAP API is XML based. It is also very strict in development as every part of the request has a specific and strict standard.

Here is an example of SOAP request –

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:web="http://www.example.com/webservice">
   <soapenv:Header/>
   <soapenv:Body>
      <web:GetUser>
         <web:UserId>1</web:UserId>
      </web:GetUser>
   </soapenv:Body>
</soapenv:Envelope>

Here is an example SOAP Response –

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <GetUserResponse>
         <User>
            <Id>1</Id>
            <Name>Aarav</Name>
         </User>
      </GetUserResponse>
   </soap:Body>
</soap:Envelope>

Because of this strict nature of SOAP. It has use cases in these sectors where garunteed and secure delivery is very important and critical.


• Banking transactions
• Payment gateways
• Telecom billing systems
• Government data exchange

gRPC

gRPC is google’s Remote Procedural Call protocol which means calling a function or procedure that runs on another computer or server.

Remote Procedural Call is basically some function which is placed on some other computer. It is done communicate between the devices. Here instead of sending the data, direct calls are made.

Before gRPC, xmlRPC, jsonRPC have existed but they were slow and text heavy. They also could not scale as well as gRPC for modern heavy applications.

gRPC uses protocol buffers to compresses data into compact binary format that is very fast to process.

gRPC also uses the new HTTP 2.0 protocol which can handle multiple requests over a single connection.

Because of the fast nature of gRPC it has the following use cases –

  • Microservices within large systems (like Google, Netflix, Uber)
  • Cloud-native applications (Kubernetes, gRPC-Gateway)
  • Low-latency systems (finance, IoT, games, etc.)

There are 4 main types (or patterns) of communication supported by gRPC

PatternDirectionDescription
1. Unary RPCOne request → One responseThe simplest and most common type — just like a function call.
2. Server Streaming RPCOne request → Stream of responsesThe server sends multiple responses (a stream) to a single client request.
3. Client Streaming RPCStream of requests → One responseThe client sends multiple messages, then gets a single response from the server.
4. Bidirectional Streaming RPCStream of requests ↔ Stream of responsesBoth client and server send multiple messages independently and simultaneously.

GraphQL

GraphQL also known as graph query language was created by facebook. It was desgined to tackle the very fundamental question of overfetching and underfetching.

There are scenarios where we want too little data from a particular REST API but still we have to fetch the whole data. This is called overfetching. There are also scenarios where we want more data and for that we have to make multiple different API calls. This is called underfetching. Traditional REST APIs cannot be quantised on the go to solve this problem.

In GraphQL, we can write simple queries for getting the specific amount of data that we need in each call.

For example,

Instead of hitting multiple endpoints like

/users/1
/users/1/posts
/users/1/friends

We can use the query,

{
  user(id: 1) {
    name
    posts {
      title
      comments {
        text
      }
    }
    friends {
      name
    }
  }
}

WebSockets

WebSockets is a communication protocol that provides full-duplex (two-way) communication channels over a single TCP connection. Unlike traditional HTTP requests where the client must initiate every interaction, WebSockets create a persistent connection between client and server that allows both parties to send data at any time.

The protocol starts with an HTTP handshake that “upgrades” the connection to WebSocket, after which data flows freely in both directions without the overhead of repeated HTTP requests.

WebSockets are ideal for applications requiring real-time, bidirectional communication:

  • Chat applications
  • Live notifications
  • Real-time dashboards
  • Online gaming
  • Collaborative tools
  • Live sports scores
  • IoT device communication


WebSockets are widely used in modern applications that require real-time, two-way communication between clients and servers. They enable instant messaging in chat applications, allowing users to exchange messages without delay. Live notifications benefit from WebSockets by delivering push updates directly to users without the need for constant polling. They also power real-time dashboards such as stock tickers, analytics platforms, and monitoring tools, where data needs to refresh instantly. In online gaming, WebSockets help synchronize the game state among multiple players in real time. Similarly, collaborative tools like Google Docs rely on WebSockets for simultaneous editing, ensuring that all users see updates as they happen. WebSockets also drive live sports score updates, providing fans with instantaneous results. Beyond these, they play a vital role in IoT device communication, where sensor data is continuously streamed between devices and servers for real-time monitoring and control.

Here’s a simple chat example of NodeJS Server (Node.js with “ws” library)

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Client connected');
  
  ws.on('message', (message) => {
    console.log('Received:', message);
    
    // Broadcast to all connected clients
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });
  
  ws.on('close', () => {
    console.log('Client disconnected');
  });
});

Here is an example of client code.

const socket = new WebSocket('ws://localhost:8080');

socket.onopen = () => {
  console.log('Connected to server');
  socket.send('Hello Server!');
};

socket.onmessage = (event) => {
  console.log('Message from server:', event.data);
};

socket.onerror = (error) => {
  console.error('WebSocket error:', error);
};

socket.onclose = () => {
  console.log('Disconnected from server');
};

WebHooks

Webhooks are automated HTTP callbacks triggered by specific events in a system. Instead of your application repeatedly asking “has anything changed?” (polling), the external service proactively sends data to your application when an event occurs.

Think of it as a “reverse API” – rather than you calling their API, they call yours. When something happens (like a payment completed, user signed up, or file uploaded), the service makes an HTTP POST request to a URL you’ve configured, delivering event data in real-time.

Webhooks are ideal for event-driven integrations:

  • Payment processing – Stripe notifying you when a payment succeeds/fails
  • CI/CD pipelines – GitHub triggering builds when code is pushed
  • CRM updates – Salesforce notifying you of new leads
  • Email services – SendGrid alerting you of email deliveries/bounces
  • Social media – Twitter/Facebook notifying you of mentions or messages
  • File storage – Dropbox alerting when files are modified
  • E-commerce – Shopify notifying you of new orders
  • Monitoring – Alerting systems sending notifications about incidents

Webhooks advantages:

  • Real-time updates – instant notification when events occur, no delay
  • No polling overhead – eliminates constant “checking” requests that waste resources
  • Reduced API calls – significantly fewer requests to external services (avoids rate limits)
  • Lower latency – immediate notification vs. polling intervals (could be minutes)
  • Server efficiency – your server only processes data when something actually happens
  • Cost savings – fewer API requests means lower costs for metered APIs
  • Scalability – external service handles delivery, you just receive events

WebRTC

WebRTC (Web Real-Time Communication) is an open-source technology that enables peer-to-peer (P2P) audio, video, and data communication directly between browsers and mobile applications without requiring an intermediary server for media transmission.

Unlike traditional video conferencing that routes everything through a central server, WebRTC establishes direct connections between clients, resulting in lower latency and reduced server costs. It provides JavaScript APIs that handle complex tasks like codec negotiation, network traversal (NAT/firewall), encryption, and adaptive streaming automatically.

WebRTC is ideal for real-time media and data communication:

  • Video conferencing
  • Voice calls
  • Live streaming
  • Screen sharing
  • File transfer
  • Online gaming
  • Telemedicine
  • Customer support
  • IoT communication
  • Collaborative tools


WebRTC (Web Real-Time Communication) is a powerful technology that enables seamless, real-time communication directly between browsers and devices without requiring external plugins or servers for media transfer. It powers video conferencing platforms like Zoom, Google Meet, and Microsoft Teams, allowing users to connect face-to-face over the web with minimal latency. WebRTC also supports voice calls and VoIP applications, enabling browser-based phone calls with high-quality audio. In live streaming, it facilitates low-latency broadcasting, ensuring near-instant delivery of video to viewers. The technology also enables screen sharing for remote desktop access or online presentations and supports file transfer through peer-to-peer connections, removing the need to upload files to centralized servers. In online gaming, WebRTC allows real-time data exchange between players for smoother multiplayer experiences. It is also increasingly used in telemedicine, powering secure video consultations between doctors and patients, and in customer support, where live video chat enhances user experience. Furthermore, WebRTC supports IoT communication, allowing direct device-to-device interactions without intermediary servers, and enhances collaborative tools such as whiteboarding and co-browsing, enabling multiple users to interact and edit in real time.