3 ms·
The SO answer by user1907906 would be my preference as well. It appears that you trying to wrap generic SQL queries with REST. That is not really the intended
by CyberFonic 9y ago
The SO answer by user1907906 would be my preference as well.
It appears that you trying to wrap generic SQL queries with REST. That is not really the intended use case for REST. A GET should be retrieving a single resource or small set of resources with relatively few query parameters.
Since REST is not suitable for "query heavy" use, I would prefer to use GraphQL if that is the nature of your API. If you are prevented from using GraphQL, then the SO solution is probably your next best bet.
- michaelsbradley 9y agoYou're spot on. This pertains to a more or less homegrown query DSL (or family of DSLs) that gets "translated," in a sense, by the server to SQL and/or MongoDB queries. The read-only endpoints being queried represent collections of a great many items, so being able to filter–search for, say, a dozen to a few thousand at a time is a real need. Using GraphQL would probably be better, but if it's not an option then it's not an option. I am, though, looking at dynamic-rest[1] and Eve's "projections"[2] for inspiration, i.e. to allow for flexible queries that more closely match particular use cases (of the API's users). [1] https://github.com/AltSchool/dynamic-rest https://github.com/AltSchool/dynamic-rest [2] http://python-eve.org/features.html#projections http://python-eve.org/features.html#projections