A great example of this today is GraphQL. Even if you disagree with the premise of GQL, you can understand how you can have complicated filtering and sorting logic, and conditional expansion of nested resources. For a nontrivial data model, you may want to select only a minimal number of fields on each nested resource. Having lots of different variants of the same endpoint to serve the same query with different shapes of output is difficult to maintain, so this makes some sense.
I knew someone would bring up GraphQL, as I consider it a sort of way to present a database schema in JSON, so of course it would result in complex SQL-like queries. I understand why it works for Facebook, but it's not something I've ever reached for to solve any programming problem I've had.
Nothing about GQL in particular is necessary to appreciate the need for this. Consider the Stripe API, where you might fetch invoices and expand the customers for each of those invoices, and then fetch the default payment methods for each of those customers. Stripe does this with a mess of query string parameters over a REST-ish API, but it could be accomplished much better with a request body.
GQL solves this problem in a particular way, but even folks who don't turn to GQL still have this problem.
It's absolutely awesome for implementing any kind of faceted search inside of a web application. Generating reports, finding resources, and of course social media do this sort of operation all the time. Gql makes it way cleaner and more efficient than GET this, parse it, POST a query, GET more things.
If you aren't in those spaces it probably seems unnecessary.
