You can still design an immutable REST api to match the client's needs. Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.
I see your point about reducing network requests (graphql lets you co-mingle mutations and queries), but I don't think that feature is used often enough, b/c what if one query fails, then everyone has to fail).
> Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.
Caching is trivial to do with REST.
The "really nice caching" that Apollo does literally deserializes and deep inspects both the request and the response to try and figure out caching on specific fields. Also, POST requests are not cacheable according to HTTP spec.
With REST you set an ETag and/or Cache-Control headers and let your existing infra and client browsers handle that.
You can make a REST endpoint match a client's needs, but if you have multiple clients (for example, 1 for mobile and 1 for desktop) that all need different amounts of data (for example, the mobile client shows a simplified view with less data), then you would need to write 2 different REST endpoints to handle each clients. Multiply that by the number of pages with a difference.
I see your point about reducing network requests (graphql lets you co-mingle mutations and queries), but I don't think that feature is used often enough, b/c what if one query fails, then everyone has to fail).