Because then 2 months later a dev refactors the front end to only require one of the fields, and suddenly you have the gorilla holding a banana and the whole jungle when all you asked for was a banana.

GraphQL can support arbitrary numbers of fields and arbitrary nesting of relationships. You can do this:

    {
      hero {
        name
        friends {
          name 
            friends {
              name
            }
        }
      }
    }

But some clients might only need this:

    {
      hero {
        name
      }
    }

This is a small example, but it's pretty clear that "always including all fields and nested relationships in every REST API response" is not a viable solution.

(GraphQL examples based on the schema used in the official documentation: https://graphql.org/learn/queries/)

Because loading all the friends for a user needs to be done in five different places with slightly different data in each one, and loading the data for each request takes 500ms combined but only 150ms separately, plus there are specific questions about each friend like "is this friend in event X?" that only make sense if you know what X is, and when you add a parameter like event=X you notice that there's already an event parameter that does something else and all these different cases are becoming messy, your backend logic had started to reflect the frontend, and you wish you had some kind of way to query your graph of users to retrieve exactly the fields and embedded relationships you need.

The people who write the API would need to know you want that data and implement the change, or write a new endpoint that returns the user details and the friends details in one request. With GraphQL the API wouldn't need to change; you'd just need to write the query on the frontend and it'd work.

For most web apps the overhead of adding a new endpoint is small so the benefit of GraphQL is also small, but if you're Facebook then GraphQL makes a huge amount of sense.

Yeah, it'd sure be nice if there was some way for the client to specify what data it wants.

At my previous job we had a method that became known as a "superset". It would fetch a record and all data related to that, and then a lot of other data related to that. It would return tens of MB of XML every time. It was huge, but so many services came to depend on it because it always had that piece of data someone needed.

All the data you needed was there, but every request caused a lot of memory usage and lots of database queries. GraphQL allows you to just ask for the fields you need without necessarily incurring the cost of returning anything else.