Every request your API handles travels across a network, and networks are never as fast or as reliable as we want them to be. When I design an API, I treat network efficiency as a core design constraint, not an optimization I bolt on after launch. In this article, I want to walk through every technique I actually use to make APIs fast, lean, and resilient over real-world networks — including flaky mobile connections, high-latency international routes, and everything in between.
This matters more than most people think. A chatty, bloated API doesn’t just feel slow — it costs real money in bandwidth, drains mobile battery life faster, and creates a worse experience for every single consumer, especially on weaker connections.
Start by Minimizing Round Trips
The single biggest lever I have over perceived API speed is the number of round trips a client needs to complete a task. Every round trip carries the full cost of network latency, TLS negotiation (unless connections are reused), and server processing time.
The Classic Chatty API Problem
Imagine a mobile app screen that shows an order, its items, and the customer’s name. A naive, resource-per-endpoint design might require:
GET /orders/123
GET /orders/123/items
GET /customers/456
Three round trips for one screen. On a fast wifi connection, that’s mildly wasteful. On a slow mobile connection with 300ms+ latency per round trip, that’s nearly a full second added just from network round trips, before any actual data processing.
Designing Composite Endpoints
I solve this by designing purpose-built composite endpoints for common consumer needs:
GET /orders/123?include=items,customer
{
"id": "123",
"status": "processing",
"items": [
{ "productId": "p1", "quantity": 2 }
],
"customer": {
"id": "456",
"name": "Jane Doe"
}
}
I use an include query parameter pattern (similar to what JSON:API popularized) so consumers who only need the base order can skip the extra data, while consumers who need the full picture can request it in a single round trip. This keeps the API flexible without forcing every consumer to pay for data they don’t need.
Field Selection: Sending Only What’s Needed
Sometimes the problem isn’t too many requests — it’s that each individual response carries more data than the consumer actually needs. I support a fields parameter for exactly this case:
GET /orders/123?fields=id,status,total
{
"id": "123",
"status": "processing",
"total": 49.99
}
This is especially valuable for list endpoints, where returning full nested objects for every item in a 50-item list can bloat a response dramatically for very little practical benefit if the consumer only needs to render a summary table.
Pagination: Never Return Unbounded Lists
An unbounded GET /orders that returns every order a customer has ever placed is both a network efficiency problem and a stability risk. I always paginate list endpoints, and I’m deliberate about which pagination style fits the use case.
Offset-Based Pagination
GET /orders?page=2&pageSize=20
Simple to implement and understand, and works well for smaller, relatively stable datasets — like a typical admin dashboard table. I generally avoid it for very large or frequently changing datasets, since offset pagination can skip or duplicate records if rows are inserted or deleted between page requests.
Cursor-Based Pagination
GET /orders?after=eyJpZCI6IjEyMyJ9&limit=20
I reach for cursor-based pagination for large or fast-changing datasets — activity feeds, transaction logs, anything at real scale — because it stays consistent even as underlying data changes between requests, and it typically performs better on the database side, since it avoids the OFFSET scan cost that grows with page depth.
{
"data": [ ... ],
"pageInfo": {
"nextCursor": "eyJpZCI6IjE0MyJ9",
"hasNextPage": true
}
}
Compression: An Easy, High-Impact Win
I make sure every API response supports gzip or Brotli compression via standard HTTP content negotiation:
Accept-Encoding: gzip, br
Content-Encoding: br
For JSON payloads, which are highly compressible text, this routinely cuts response size by 70% or more with essentially no cost to implement, since virtually every HTTP server and client library supports it natively. I treat this as a baseline requirement, not an optional enhancement.
Caching: Avoiding Unnecessary Network Trips Entirely
The fastest network request is the one that never happens because the client already has a valid cached copy. I design explicit caching support into every read-heavy endpoint.
ETags for Conditional Requests
GET /products/789
Response:
ETag: "a1b2c3d4"
Next request from the same client:
GET /products/789
If-None-Match: "a1b2c3d4"
If nothing changed, I respond with 304 Not Modified and an empty body, instead of resending the full payload. For a product catalog endpoint that changes infrequently but gets requested constantly, this dramatically cuts bandwidth.
Cache-Control Headers
Cache-Control: public, max-age=300, stale-while-revalidate=60
I set explicit cache lifetimes based on how frequently data actually changes. Static reference data (like a list of countries or currencies) might get a max-age measured in days. Frequently changing data (like live order status) might get a very short max-age or none at all, relying instead on ETags for conditional validation.
Choosing the Right Payload Format
JSON is my default for public APIs because of its universal tooling support, but I stay aware of the alternatives when network efficiency is genuinely critical:
- Protocol Buffers / gRPC — binary, strongly typed, and significantly smaller and faster to parse than JSON. I consider this for internal, high-throughput service-to-service communication where both ends are systems I control, and the tooling overhead is worth the efficiency gain.
- MessagePack — a binary drop-in alternative to JSON that keeps a similar data model while reducing payload size, useful when I want efficiency gains without a full move to a schema-driven binary protocol like Protobuf.
For public-facing APIs, I usually stick with JSON despite the overhead, because broad compatibility and ease of debugging matter more than shaving bytes for most consumers. I make this trade-off deliberately, not by default.
Batch Operations: Reducing Round Trips for Bulk Actions
If consumers regularly need to create or update multiple resources at once, I design an explicit batch endpoint rather than forcing dozens of individual round trips.
POST /orders/batch
{
"orders": [
{ "customerId": "1", "items": [...] },
{ "customerId": "2", "items": [...] }
]
}
{
"results": [
{ "status": "created", "id": "order_1" },
{ "status": "error", "code": "invalid_customer" }
]
}
I always design batch responses so each item reports its own success or failure independently — a batch operation shouldn’t be all-or-nothing unless that’s a genuine business requirement, because partial failure handling in a single round trip is exactly the efficiency win the batch endpoint exists to provide.
GraphQL: When Flexible Field Selection Matters Most
For APIs where consumers have wildly varying data needs — different mobile screens, different partner integrations, different dashboards — I sometimes reach for GraphQL instead of, or alongside, REST. GraphQL lets a single endpoint serve exactly the fields and nested relationships each specific consumer needs, in exactly one round trip, without me having to hand-design dozens of composite REST endpoints to cover every combination.
query {
order(id: "123") {
status
total
customer {
name
}
}
}
I don’t treat GraphQL as strictly superior to REST — it introduces its own complexities around caching (since a single endpoint and varying queries make HTTP-level caching harder) and query cost control (a poorly bounded nested query can be expensive to resolve). I choose it specifically when the round-trip and over-fetching problem is severe and varied enough to justify that trade-off.
HTTP/2 and HTTP/3: Let the Transport Layer Help You
Beyond application-level design, I make sure the API is served over HTTP/2 or HTTP/3 wherever possible:
- HTTP/2 enables multiplexing multiple requests over a single TCP connection, removing the old head-of-line blocking problem from HTTP/1.1, and supports header compression (HPACK), which matters a lot for APIs with many small requests carrying repetitive headers (like auth tokens).
- HTTP/3, built on QUIC over UDP, further reduces connection setup latency and handles network changes (like a mobile device switching from wifi to cellular) far more gracefully than TCP-based HTTP/2.
This is largely an infrastructure decision rather than something expressed in the API contract itself, but I always confirm it’s configured correctly at the load balancer or API gateway level, since it’s a “free” performance win that requires no changes to the API design itself.
Designing for Real-Time Needs Without Polling
If consumers need near-real-time updates (like order status changes), naive polling — a client calling GET /orders/123 every few seconds — is one of the most network-inefficient patterns I see in the wild. I design alternatives instead:
- Webhooks, where my API calls the consumer’s endpoint the moment something changes, eliminating polling entirely for server-to-server integrations.
- WebSockets or Server-Sent Events, for long-lived client connections (like a live dashboard) that need a continuous stream of updates without repeated HTTP round trips.
- Long polling as a middle-ground fallback, where a request stays open until there’s new data to return or a timeout is hit, reducing the frequency of “empty” round trips compared to naive short-interval polling.
Measuring What Actually Matters
I don’t optimize network efficiency blindly — I measure it, using metrics that reflect real consumer experience:
- Time to first byte (TTFB) — how long before the client starts receiving any response at all.
- Payload size, both compressed and uncompressed, tracked per endpoint over time so regressions are caught early.
- Number of round trips per common user flow, not just per endpoint in isolation.
- Cache hit ratio, to confirm my caching headers are actually being respected and reducing load in practice, not just in theory.
Common Network-Efficiency Mistakes I Watch For
- Deeply nested, over-fetched responses that include far more data than any realistic consumer needs by default.
- No pagination on list endpoints, which becomes a serious problem the moment real-world data volume grows past initial testing scale.
- Ignoring compression, especially on large JSON array responses where the savings are most dramatic.
- No caching strategy at all, forcing every single request to hit the origin server even for data that barely changes.
- Polling-based “real-time” features that could have been a webhook or a WebSocket connection instead.
Where This Fits Into the Bigger Picture
Network efficiency isn’t purely a technical optimization — it directly shapes how consumers experience your API, especially on constrained connections or at scale. It connects closely to the final topic in this series: designing genuinely simple, consumer-friendly APIs. A network-efficient API that’s still confusing to use hasn’t fully succeeded, and that’s exactly what I cover next in “Focusing on the Consumer’s Perspective to Create Simple APIs.”
Key Takeaways
- Minimize round trips with composite, purpose-built endpoints rather than forcing consumers to stitch together multiple calls.
- Support field selection and pagination on every meaningful list or large-object endpoint.
- Treat compression and HTTP caching (ETags, Cache-Control) as baseline requirements, not optional extras.
- Choose the right payload format and communication pattern (REST, GraphQL, webhooks, streaming) deliberately, based on actual consumer needs, not habit.
- Measure real metrics — TTFB, payload size, round trips per flow, cache hit ratio — rather than assuming your design is efficient.
A network-efficient API respects its consumers’ time, data plans, and battery life. Those things matter just as much as clean code and correct business logic — sometimes more, from the consumer’s point of view.
