I think it's mainly useful in a (complex) public API.
I haven't actually used it yet, but am considering it, despite the complexity it introduces, since it promises to improve some of our pain points:
1. The client requesting specific fields enables the provider to track which fields are used. This enables fine grained deprecation notices. In my experience I rarely want to replace complete endpoints, but it often turns out that specific fields are either badly named, or don't really make sense anymore.
2. The ability to get data about related objects simplifies the client, but increases complexity on the server. Since there are many different clients (in our case every customer writes their own integration), this is often a worthwhile trade-off. For example when getting an order, the same API call could return needed product or customer data.
For internal APIs with moderate team sizes, I'd define endpoints specifically for each consumer, instead of REST or GraphQL.
I haven't actually used it yet, but am considering it, despite the complexity it introduces, since it promises to improve some of our pain points:
1. The client requesting specific fields enables the provider to track which fields are used. This enables fine grained deprecation notices. In my experience I rarely want to replace complete endpoints, but it often turns out that specific fields are either badly named, or don't really make sense anymore.
2. The ability to get data about related objects simplifies the client, but increases complexity on the server. Since there are many different clients (in our case every customer writes their own integration), this is often a worthwhile trade-off. For example when getting an order, the same API call could return needed product or customer data.
For internal APIs with moderate team sizes, I'd define endpoints specifically for each consumer, instead of REST or GraphQL.