Using filter for relationship's related link


#1

Article belongs-to-many tags. To get all the tags that belong to article 1 then /articles/1/tags. This will provide me with collection of tag resource objects that belong to article 1.

To get tags that doesn’t belong to article 1, i am creating a relationship url - /articles/1/nonAssociatedTags. To my understanding, this nonAssociatedTags is a subresource of article and of type tags. Is it possible to filter nonAssociatedTags with Tag-attributes. If yes, then which of the below approach is correct [assume tag has property: type - popular/unpopular]

/articles/1/nonAssociatedTags?filter[type]=popular /articles/1/nonAssociatedTags?filter[Tags.type]=popular /articles/1/nonAssociatedTags?filter[unAssociatedTags.type]=popular


#2

I would suggest tags are their own resource, not a subresource, as such it should be /articles/1/relationships/tags.

Further, depending on your filtering syntax, the appropriate solution would be something like …

/tags?filter[article]!=1;[type]=popular

#3

hi @michaelhibay, thanks for your reply.

Tags is an independent resource. It has ‘many-to-many’ relationship with articles resource.It is related to Article resource since /articles belongs to many /tags. If article resource is fetched - /articles/1 then /articles/1/relationship/tags will be the article-tag relationship’s self link and /articles/1/tags will be relationship’s related link.

/articles/1/relationship/tags - will provide me with resource linkage object as primary object i.e., collection of tag resource identifier objects belonging to article 1

/articles/1/tags - will provide me with collection of tag resource objects belonging to article 1

How the filter on this related link /articles/1/tags should be? If i need to filter the tags of type popular in that self link something like /articles/1/tags?filter[type]=popular

Similar to this, I need to get what are all the tags that doesn’t belong to article 1. For that case i am creating a subresource ‘nonAssociatedTags’ of type tags [the resource will be of type tags. similar to author resource of type people in JSONAPI example]

In this case article belongs to many non associated tags, /article/1/nonAssociatedTags
will provide me with tag resource object collection that does not belong to article 1.


#4

This implies that tags are sub-resources to articles, and they aren’t as per my previous post and complex resources should be composed through relationships. The better way to return the data would be include the data yourself, without requiring the use of the include parameter.

Despite this example being in the spec (I think it’s a mistake for a couple of reasons), how would you expect to prove a negative from the set of items positively related to your resource?

/articles/1/tags

Will return the tags associated with the articles, this isn’t the entire collection of tags. The set of tags you expect to be compared to the results of this call is not returned here. I understand from your explanation what you are looking for, however this doesn’t make sense.

The related link should actually be something like this:

/tags?filter[article]=1

That way, you are able to logically talk about retrieving the set of tags which are not related to the article.

Remember that filtering works on properties AND relationships. To answer the filter related popular tags, simply add that additional filter parameter.

/tags?filter[article]=1,[type]=popular

The syntax of your filtering strategy would come into play here, but I think this demonstrates the appropriate approach.