Choosing the Right API Technology
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Choose the technology from the conversation the systems need, not from a popularity ranking. Ask whether the interaction is a short request and response or a long stream, whether one side or both sides send events, whether clients are public or controlled, and whether normal HTTP caches and intermediaries need to understand the exchange. Those facts narrow the choice quickly.
REST fits resource-oriented APIs used by browsers, partners, mobile apps, and other broad clients. An interaction such as GET /orders/42 can use status codes, ETag, cache metadata, links, and content negotiation that gateways and clients already understand. It is a strong default for public request/response APIs, but it still needs careful resource and representation design.
GraphQL fits clients that need different slices of connected data. One typed schema lets each query select its fields. It also defines subscriptions as response streams, but the API still chooses and operates their transport. The server must control query cost, batch resolver loads, authorize nested fields, and monitor execution rather than treating flexible operations as free.
gRPC fits controlled service-to-service or native-client communication where both sides can use a shared service definition and generated code. A method can be unary, client-streaming, server-streaming, or bidirectional-streaming. That is useful for internal commands and data streams, but browser support, proxy compatibility, contract rollout, debugging, deadlines, and observability must match the real environment.
WebSocket creates a long-lived channel over which either peer can send messages, which can fit chat, collaborative editing, or multiplayer state. The application still defines message types, authorization, ordering, backpressure, reconnect, and recovery. If only the server pushes browser updates, Server-Sent Events may be simpler; webhooks suit server-to-server notifications, and polling can suit infrequent changes.
One product may use REST for partner orders, GraphQL for changing mobile screens, gRPC between inventory services, and WebSocket only for live support. This is useful only when each boundary earns its extra tooling. Test representative payloads, concurrency, connection behavior, failure recovery, and team operations. No protocol is universally fastest, and using one technology everywhere is not automatically simpler.
Choosing the Right API Technology
Direct Answer
Choose between REST, GraphQL, gRPC, and WebSocket by matching the communication pattern and client environment: REST for resource-based HTTP APIs, GraphQL for client-selected connected views, gRPC for typed calls and streams between controlled systems, and WebSocket for a long-lived two-way channel. There is no universal winner, and different boundaries can use different technologies.
Deep Dive & Architecture
Direction asks who can initiate data. REST requests and GraphQL queries or mutations normally follow request and response; GraphQL subscriptions produce an event stream through a separately chosen transport. gRPC supports request-response calls and typed streams. WebSocket provides a general two-way channel, so the application must define message envelopes, correlation, ordering, error behavior, and resumption above it.
Duration asks whether interaction is short-lived or ongoing. A cacheable product read should not require a permanent socket. A rapid collaborative session should not issue a fresh request for every tiny update if a managed stream better fits. Server-sent events are a useful middle ground when only the server needs to push to a browser.
Ownership asks how much the producer controls clients and infrastructure. Generated gRPC clients fit coordinated services better than unknown browser and partner ecosystems. REST's HTTP vocabulary and representations are widely accessible. GraphQL gives clients query flexibility but makes the server responsible for defending a larger execution surface.
Operational fit is decisive. Evaluate gateway and load-balancer support, connection limits, timeouts, observability, schema compatibility, caching, retries, and team skill. Then benchmark representative payloads and concurrency. Protocol overhead is only one part of end-to-end latency; resolver design, database access, and network placement often dominate.
Code Example
Public partner catalog -> REST resources with ETags
Mobile home-screen data -> GraphQL selected view
Inventory service command -> gRPC unary RPC
Inventory update stream -> gRPC server stream
Live support conversation -> WebSocket messages
Order-status browser feed -> Server-Sent Events
This is not a required architecture. It shows how interaction shape can justify different boundaries without claiming one protocol is universally faster or the only way to deliver live updates.
Check your understanding
Answer these without looking back at the article.
- When is server-sent events simpler than WebSocket?
- What operational risks come with flexible GraphQL queries?
- Why should gRPC performance be measured instead of quoted as a fixed multiplier?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.