<\/span><\/h2>\nAs applications became more dynamic and frontend-driven, REST\u2019s limitations started to surface. And that too, especially in modern web and mobile experiences.<\/p>\n
![\"Limitations](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" "\\"\\"")
<\/p>\n
1. Over-fetching data<\/h3>\n
REST endpoints return a fixed response structure, whether the client needs all of it or not. Example: GET \/users\/42<\/p>\n
Response:<\/p>\n
{
\n\"id\": 42,
\n\"name\": \"Alex\",
\n\"email\": \"alex@example.com\",
\n\"address\": \"...\",
\n\"preferences\": \"...\",
\n\"createdAt\": \"...\",
\n\"lastLogin\": \"...\"
\n}<\/code><\/p>\nIf your UI only needs the user\u2019s name, you are still paying the cost of transferring unnecessary data.<\/p>\n
Why this matters:<\/strong> On mobile networks or low-bandwidth environments, over-fetching directly affects load time and user experience.<\/p>\nMany enterprises faced this issue early on when building mobile apps for global markets, where network speeds and data costs varied drastically. This inefficiency was one of the key reasons GraphQL was created.<\/p>\n
2. Under-fetching data<\/h3>\n
The opposite problem is just as common. A single screen often requires multiple API calls, increasing latency and complexity.<\/p>\n
Example:<\/p>\n
GET \/products\/123
\nGET \/products\/123\/reviews
\nGET \/products\/123\/seller<\/p>\n
Each request:<\/p>\n
\n- Adds network overhead<\/li>\n
- Increases page load time<\/li>\n
- Complicates error handling<\/li>\n<\/ul>\n
For large e-commerce platforms or SaaS dashboards, assembling a single UI view from many REST endpoints can slow down performance. Especially on mobile devices.<\/p>\n
3. Tight coupling between frontend and backend<\/h3>\n
In REST, the backend controls the response shape. If the frontend needs:<\/p>\n