Can't filter by id
The filter is ok, unless you try to filter by the id.
I received this exception.
Unhandled rejection BadRequestError: The field "id" is non-existent.
This is expected, I think. Why are you trying to "filter" by ID? If you have the ID of a record, the URL always looks like this:
/:type/:id
Not sure what the use case is.
It's used by Ember to load relationships without making a request for every relationship.
In the adapter we can set the coalesceFindRequests option to true, so we can get all in one request:
{
post: {
id: 1,
comments: [1, 2]
}
}
With this option set to false the request will be:
GET /comments/1
GET /comments/2
And with the option set to true:
GET /comments?filter[id]=1,2
Oh, ok. This is an odd case because the JSON API spec says nothing about the filter query, but it seems that they rely on non-standard features. So in the special case when IDs are not in the route and filter[id] is present, it should actually change the requested IDs.
I don’t think that this is a non-standard feature, it’s likely that is an implicit implementation because the filter must filter any column, independent if is primary key or not.
If I figure out how to implement this, i’ll make a pull request.
Iago Sousa [email protected]
On Mar 10, 2016, at 2:02 PM, ████ [email protected] wrote:
Oh, ok. This is an odd case because the JSON API spec says nothing about the filter query, but it seems that they rely on non-standard features. So in the special case when IDs are not in the route and filter[id] is present, it should actually change the requested IDs.
— Reply to this email directly or view it on GitHub https://github.com/fortunejs/fortune-json-api/issues/18#issuecomment-194956933.
The spec says absolutely nothing about filtering:
JSON API is agnostic about the strategies supported by a server. The filter query parameter can be used as the basis for any number of filtering strategies.
http://jsonapi.org/format/#fetching-filtering
So the fact that Ember Data uses the filter query at all is non-standard.
The filter query parameter is reserved for filtering data. Servers and clients SHOULD use this key for filtering operations. JSON API is agnostic about the strategies supported by a server. The filter query parameter can be used as the basis for any number of filtering strategies.
The problem is that the filter can be applied to any column except ID, that is also a column.
Seems that the script is ignoring the ID as a column.
Iago Sousa [email protected]
On Mar 11, 2016, at 2:25 PM, ████ [email protected] wrote:
The spec says absolutely nothing about filtering:
JSON API is agnostic about the strategies supported by a server. The filter query parameter can be used as the basis for any number of filtering strategies.
http://jsonapi.org/format/#fetching-filtering http://jsonapi.org/format/#fetching-filtering So the fact that Ember Data uses the filter query at all is non-standard.
— Reply to this email directly or view it on GitHub https://github.com/fortunejs/fortune-json-api/issues/18#issuecomment-195465486.
What I meant was that any sort of filtering is out of the spec, and is ad hoc. For example, if I wanted to filter by aggregate sum of an array of numbers greater than some amount, of course the spec won't bother with that. Any client using the filter option is effectively coupled to a particular implementation.
I think that this discussion should belong in JSON API.
Oh yes, sorry for the misunderstanding.
Iago Sousa [email protected]
On Mar 11, 2016, at 2:43 PM, ████ [email protected] wrote:
What I meant was that any sort of filtering is out of the spec, and is ad hoc. For example, if I wanted to filter by aggregate sum of an array of numbers greater than some amount, of course the spec won't bother with that. Any client using the filter option is effectively coupled to a particular implementation.
I think that this discussion should belong in JSON API.
— Reply to this email directly or view it on GitHub https://github.com/fortunejs/fortune-json-api/issues/18#issuecomment-195474626.
This is a server strategy and does not rely on specification.
Actually leave it open, I would like to keep track of it since it's useful for Ember Data.