Turns out there are 6 other API types worth knowing. Not because REST is bad, but because some problems genuinely need a different tool.

REST

The default for a reason. Stateless, HTTP-based, and everyone on your team already knows it. Great for most web and mobile apps.It starts showing cracks when your client needs very specific data — you either fetch too much or make too many calls. But for 80% of use cases, REST is fine.

SOAP

Probably the one you’ll least choose voluntarily. XML-heavy and verbose. But if you’re ever integrating with a bank or a healthcare system, it’s almost certainly SOAP on the other end.The strictness that makes it annoying is also what makes it trusted in regulated industries. You don’t have to like it, but it’s good to know it exists.

gRPC

This one clicked for me when I started working with microservices. Instead of JSON, it uses binary (Protocol Buffers) over HTTP/2 — which means faster and smaller payloads.The tradeoff is debugging is less straightforward. But for internal service-to-service calls where you own both sides, it’s noticeably more efficient than REST.

GraphQL

The client asks for exactly what it needs. No over-fetching, fewer round trips. Frontend devs love it because they’re not waiting on backend changes to update a view.Where it gets messy: badly written queries can murder your database. It moves complexity from the API into query design and resolvers. Worth it when used carefully.

Webhooks

Simple concept — instead of your app asking “anything new?”, the other service calls you when something happens. Way more efficient than polling.You do need to handle retries and verify incoming requests, but for payment events or third-party integrations, it’s cleaner than constantly checking for updates.

WebSockets

HTTP is request-response. You ask, you get an answer, connection closes. WebSockets keep the connection open so the server can push data whenever it wants.Useful for chat, live dashboards, anything where waiting to be asked doesn’t make sense. Managing connections at scale takes some thought, but the model itself is straightforward.

WebRTC

Peer-to-peer, no server in the middle for the actual data. Built for real-time audio and video. It’s what powers most video calling apps

So when do you use what?

• Request/response, standard data → **REST**
• - Client needs very specific data shapes → **GraphQL**
• - Fast internal service calls → **gRPC**
• - React to external events → **Webhooks**
• - Server pushes updates live → **WebSockets**
• - Real-time audio/video → **WebRTC**
• - Someone else’s legacy system → **SOAP**