Some people are using graphql, but it's not REST. GET payloads defining filter options is not a bad idea, but with GET people get lazy and start appending query params. With that said, it might be sign that your REST design itself doesn't reflect reality given the need to augment the calls with complexity. But there is also nothing saying that a "query" can't be part of your model - just needs to be incorporated in as high a level as possible. (added) What this question (and the popularity of graphql) tells me is that the underlying data model and the REST model are not coherent with one another. What this also implies is that perhaps what is actually needed is a data abstraction layer since REST really should reveal nothing about the underlying data model itself (e.g., it should provide "data encapsulation" like trad OOP).