Over-Fetching
Transferring fields the interface will not display, which costs bandwidth and parse time on exactly the devices least able to afford them.
A resource endpoint returns the whole resource because it does not know which screen is asking. A list view showing a name and a status receives forty fields per row, and on a list of a hundred rows that is a payload several times larger than necessary, parsed on a device with limited CPU.
The three common responses trade differently. Sparse fieldsets — a query parameter naming the fields wanted — are a small change to a REST API and put the burden on every client to ask correctly. GraphQL makes the client's declaration of need the interface itself, which solves over-fetching by construction and introduces query cost control, caching complexity and a new class of denial-of- service concern. A BFF solves it by shaping the response server-side, which is often the least disruptive answer when a small number of clients are involved.
The counterpart problem is under-fetching, where avoiding large payloads produces many small requests and the round trips cost more than the bytes saved. The measurement that settles it is time to render on a throttled connection, not payload size — a single larger response frequently beats four smaller ones.