---
title: "7 API types, and when to actually use each"
category: "systems"
summary: "Why Uber and Netflix don't just use REST for everything — a decision framework for REST, SOAP, gRPC, GraphQL, Webhooks, WebSockets, and WebRTC."
date: "2026-05-12"
---

The question that got me down this rabbit hole: why doesn't every company just use REST for everything? The answer is that API choice depends on latency requirements, data shape, communication direction, and infrastructure — and each of these seven options optimizes for a different combination of those four.

## A rough decision flow

Real-time requirement is the first fork. If you don't need real-time: is this an enterprise/legacy system (SOAP), does the client need flexible data shapes (GraphQL), or are you optimizing high-performance microservice calls (gRPC) — otherwise, REST. If you do need real-time: peer-to-peer media goes to WebRTC, one-way server-push goes to Webhooks, two-way goes to WebSockets.

## REST

Stateless, JSON over HTTP/1.1, the standard verbs (GET/POST/PUT/DELETE/PATCH). Best for general-purpose web and mobile apps — easy to cache, easy to debug. Where it falls short: when a client needs several related resources in one request, REST tends toward over-fetching or under-fetching, which is exactly the problem GraphQL solves.

## SOAP

XML-based with a rigid schema (WSDL) and built-in WS-Security. Verbose, but formally specified — which is exactly why it's still standard in banking, healthcare, and government systems where compliance requires a formal contract.

## gRPC

Uses Protocol Buffers (binary, smaller than JSON) over HTTP/2, with generated client code across languages. This is what Netflix and Google use internally for service-to-service calls — 5–10× faster than REST at scale, because you're not paying JSON's serialization tax.

## GraphQL

The client specifies exactly which fields it needs, through a single `/graphql` endpoint. Used by GitHub, Shopify, and Meta — it eliminates over-fetching and under-fetching entirely, which matters most for bandwidth-sensitive mobile clients or apps where different clients need different data shapes from the same backend.

## Webhooks

The server calls *you* when something happens — an HTTP POST to a URL you registered. Stripe payments, GitHub CI/CD triggers, Slack notifications all work this way. The limitation: one-way only, no back-and-forth.

## WebSockets

A persistent TCP connection after an initial HTTP handshake, where either side can send at any time. This is what chat apps, live dashboards, multiplayer games, and collaborative editors run on. The distinction from Webhooks: WebSockets are two-way and persistent; Webhooks are one-way HTTP pushes.

## WebRTC

Peer-to-peer audio, video, and data — the connection bypasses the server entirely after initial signaling, using STUN/TURN servers for NAT traversal. This is Google Meet, Discord, and Zoom. The distinction from WebSockets: WebSockets route through your server; WebRTC connects the peers directly.

## Summary

| API | Protocol | Direction | Latency | Use case |
|-----|---------|-----------|---------|---------|
| REST | HTTP/1.1 | Request/response | Medium | Web & mobile apps |
| SOAP | HTTP/XML | Request/response | High | Enterprise, banking |
| gRPC | HTTP/2 + Protobuf | Request/response (streaming) | Low | Microservices |
| GraphQL | HTTP/1.1 | Request/response | Medium | Flexible data needs |
| Webhooks | HTTP POST | Server → client | Eventual | Event notifications |
| WebSockets | TCP (persistent) | Bidirectional | Very low | Real-time apps |
| WebRTC | P2P (UDP/TCP) | Peer-to-peer | Lowest | Audio/video/data |