Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint.
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
where "work" is a sub-resource in the same vein as GraphQL. The difference between this and GraphQL is purely syntactic: [1] http://jsonapi.org/format/#fetching-sparse-fieldsets