Should filtering be supported? about json-api HOT 5 CLOSED

Have you given any thought to a good way forward?

I really need to think through the implementation details and would welcome feedback. But my tentative plan is to allow users of the library to plug in different filtering "strategies". I'm imagining it would work like this:

Each filter parameter would be formatted as filter[strategy_name][arg]=val. Then, all the query parameters with the same strategy name would be put into an object and passed off to some user code implementing the strategy (for all adapters or on a per adapter basis, I'm not sure).

So, for example, if a user wanted to define a "not equal to" filter, they could create a strategy called "neq". Then a request might come in like GET /events?filter[neq][venue]=Lincoln Center&filter[neq][date]=01/10/2015. From this, the api controller would construct the object {venue: "Lincoln Center", date: "01/10/2015"} and pass it to the user code implementing the neq strategy, which could implement any semantics it wishes.

(Query parameters with multiple arguments, e.g. filter[strategy_name][arg_1][arg_2]=value, would also be allowed--though perhaps discouraged--and these would simply be parsed into nested objects as express does by default).

Thoughts?

I can’t figure out exactly how to use it or what syntax is supported, at least not without spending a lot of time debugging and reverse engineering it.

Two things are built in now: the "simple" strategy (though there isn't yet an interface for users to add custom strategies) and the option to use a label mapper in the resource type description (which can be quite powerful for frequently recurring queries; see the readme).
The simple strategy has equality semantics for (non-complex) attribute values and to-one relationships, and "contains" semantics for to-many relationships. That is: filter[simple][name]=Bob&filter[simple][parents]=eeacb152efgh726282 matches resources for which the name attribute is exactly equal to "Bob" and the parents relationship contains a resource with an id of eeacb152efgh726282. (Note that this may not work yet with polymorphic to-many collections.)

from json-api.

Hmm. That sounds like a pretty good plan, but I can’t decide how the implementation should work. With Mongoose, it would be pretty easy to provide the query builder object to a filter strategy hook. I can’t really think of a way that this could be adapter-agnostic though.

For total customization of querying behavior, I guess users could always subclass the adapter.

At any rate, I finally figured out that what you have is already good enough for me thanks to Mongoose’s super flexible API. I thought I would have to do some custom stuff to filter by dates later than something, but because Mongoose lets you do query.where({ date: { $gte: new Date('2015-05-01') } }), I can use the URL query ?filter[simple][date][$gte]=2015-05-01.

from json-api.

I'm glad you figured out a way to make it work! Seeing your solution though, I wonder if my current approach has some security issues...I'll have to think about it. (Though, no matter what, the final approach will allow you do the "newer than"-style filtering you're looking for.)

I'm utterly swamped right now, but will try to think this through more thoroughly in a couple weeks.

from json-api.

Update on this: I think most of the filtering strategies should be adapter specific, for performance. Each strategy could be registered with the adapter when it's constructed, and can be called by it (with a querybuilder) after that.

It might be possible to support adapter-agnostic filtering strategies as well, but these would essentially be beforeRender transforms that return undefined to remove certain elements. (In general, we should think about how to refactor the transform stuff to make it a bit more "pipeline-y", especially in light of #17 and #18.)

from json-api.

This is addressed in v3, through 801724e, which allows the user to define a list of allowed filtering operators on a per adapater basis, which can then be used in the library's default query parameter format or in whatever format the user wants (if they override the parsing logic by passing a new parser to the registry).

from json-api.