If the main metric for success for an API is payload size, then the implementations of GraphQL are tough to beat. Though there is nothing stopping you from doing the same thing with REST (what some call sparse field sets), GraphQL already has a solid implementation of reducing those responses. And it has great tooling. That doesn't exist for most web APIs.
GraphQL also has its own complexities. It's caching story is not great. Pagination is not as nice as adding next and prev links in an API like GitHub used. Errors are lacking compared to what HTTP allows.
I suppose my long-winded point here in the context of the post is that while those are great technologies, I'm still unconvinced people are going out to search for solutions for overfetching or underfetching. And I'm not sure these technologies make it conceptually a better choice than REST. REST has a lot of ideas outlined in the original spec that most people don't use. That makes it harder to compare for me.
I’m speaking more about the entire GraphQL ecosystem in my comment. The stories around what I mentioned are fuzzy and developing over time. You are right, the implementation is up to the providers and the issues are not addressed in the spec.
The HTTP ecosystem on the other hand has several widespread specs and implementations for these things.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.