the default: HTTP and REST

Most client-server interaction fits a simple shape: the client asks for something specific, and the server responds once. A user opening PlateRoute searches for nearby restaurants; the client sends one request, the server sends back one response, and nothing else happens until the user does something else.
This is exactly the shape HTTP was built for, and REST (Representational State Transfer) is the dominant convention for structuring those requests around resources and standard verbs:

GET /restaurants?near=94103        -> 200 OK, list of restaurants
POST /orders                        -> 201 Created, the new order
GET /orders/482                     -> 200 OK, order 482's details
PATCH /orders/482 {"status":"cancelled"} -> 200 OK, updated order
Three properties make HTTP/REST the right default for most client-facing APIs: it's client-driven (the server never has to initiate contact), it's a simple request-response model (one request, one response, done), and it's naturally stateless — any server behind a load balancer can answer any request without needing to remember the client's history.

where request-response breaks down: live updates

Now picture the driver-tracking screen inside an active PlateRoute order — the customer needs to see the delivery driver's position update every few seconds without refreshing the page. Plain HTTP can't push data to a client; it can only respond to a request the client makes.
Three approaches, in order of how well they solve this:
ApproachHow it worksDownside
PollingThe client re-sends a GET request every few seconds, hoping for new data.Wastes bandwidth and server load on requests that usually return "nothing changed."
Long pollingThe server holds the request open for up to some timeout, responding as soon as new data exists (or on timeout).Better, but still re-establishes a new HTTP request/response cycle for every update, and ties up a server thread/connection per waiting client.
WebSocketAfter an initial HTTP handshake, the connection is upgraded to a persistent, bidirectional channel — either side can send a message at any time.The server must hold open one connection per active client, which is a real cost at large scale.

WebSocket in practice

Once a WebSocket connection is open between the driver's app and the tracking server, the driver's app pushes a location update every few seconds directly over that connection, and the server relays it straight to the customer's open connection — no polling, no repeated request overhead, and much lower latency than long polling. The cost is holding open a live connection per active tracker, which is why WebSocket is reserved for features that genuinely need it (live tracking, chat, live sports scores) rather than used by default everywhere.

a third option: RPC

REST models everything as operations on resources ("GET this order", "POST a new order"). RPC (remote procedure call) instead models a call to another service as if it were a plain function call — getDeliveryEstimate(orderId) — hiding the network round-trip behind an interface that looks local. Frameworks like gRPC use this pattern along with a compact binary format (protocol buffers) instead of JSON, trading some human-readability for lower latency and smaller payloads.
RPC is common for internal service-to-service calls where both sides are controlled by the same team and performance matters (e.g. Dispatch Service calling Pricing Service thousands of times a second). REST/HTTP remains the default for public-facing or loosely-coupled APIs, where broad compatibility and human-debuggability (a request you can literally read in a browser) matter more than shaving off milliseconds.

choosing between them

SituationBest fit
Public API, client-driven requestsHTTP/REST
Server needs to push updates without being askedWebSocket
High-throughput internal service-to-service callsRPC (e.g. gRPC)
Tight budget, moderate throughput, simplicity mattersHTTP/REST

related topics

reference