Chatty API

A chatty API requires a client to make many fine-grained requests to accomplish a single logical operation. Rendering one screen might mean fetching a list, then looping to fetch each item's details, then fetching related entities — a flurry of small calls.

Why It Happens

It often results from mapping endpoints directly onto database tables or domain objects, one resource per call, without considering how clients actually use the data. Strict CRUD-per-entity REST design encourages it. As the UI grows, clients stitch together more and more endpoints. Microservice decomposition can amplify it when a client must call several services to build one view.

Why It Hurts

Each request carries fixed overhead — connection setup, headers, authentication, latency. Multiply that by dozens of calls and total latency balloons, especially over high-latency mobile or cross-region links. Sequential dependent calls (fetch A to know what B to fetch) serialize the cost. The server handles far more requests than necessary, hurting scalability. On mobile, radio wake-ups for each call drain battery. Users feel it as sluggish, janky screens.

Warning Signs

• Loading one view triggers tens of API calls.
• Clients loop over a list calling a detail endpoint per item (request-side N+1).
• Latency is dominated by request count, not payload size.
• Mobile users report slowness and battery drain.

Better Alternatives

Design coarser-grained endpoints that return what a use case needs in one call. Provide batch endpoints so clients fetch many items at once. Use a backend-for-frontend (BFF) or aggregation layer that composes multiple services server-side, where latency between services is low. GraphQL or sparse fieldsets let clients request exactly the data they need in a single round trip. Embed or expand related resources when they are usually needed together.

How to Refactor Out of It

Instrument clients to see calls-per-task; the worst screens reveal themselves. Introduce aggregation endpoints or a BFF that collapses chains into one request, keeping the underlying services fine-grained for reuse. Add batch variants of hot detail endpoints to kill request-side N+1. Allow expansion parameters so callers can pull related data inline. Measure latency before and after — the win is usually dramatic. Balance granularity: not so chatty that clients thrash, not so coarse that responses become bloated.