# \`include\` resource, but only if current user created it **URL:** \ **Category:** Uncategorized\ **Created:** [February 26, 2018, 7:26pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218 "2018-02-26T19:26:48Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![patience.tema.baron](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@patience.tema.baron](https://discuss.jsonapi.org/u/patience.tema.baron)\ **Post date:** [February 26, 2018, 7:26pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/1 "2018-02-26T19:26:48Z")
Imagine you have Posts, which can have many Likes. If a user is logged in and has previously liked a post, you want to include that like, though not all likes for that post. So far, the only way I can think of expressing this through JSON API is: `include: post, post.current_user_like`, and then have the API return just the current user’s like as a pseudo-relationship. I’m curious how other people approach this problem. ---
**Author:** ![michaelhibay](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/michaelhibay/32/405_2.png) [@michaelhibay](https://discuss.jsonapi.org/u/michaelhibay)\ **Post date:** [February 27, 2018, 10:36am UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/2 "2018-02-27T10:36:13Z")
Is this the default scenario, or an edge case you would like to support? If it is an edge case, you can simply add my-likes relationship. If this is the default behavior, why not just include it by default with that relationship? ---
**Author:** ![patience.tema.baron](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@patience.tema.baron](https://discuss.jsonapi.org/u/patience.tema.baron)\ **Post date:** [February 27, 2018, 3:02pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/3 "2018-02-27T15:02:47Z")
Good point. This could totally be included by default, and now that you mention it, that’s exactly what I’ll do. After thinking about this for awhile though, I’m still curious how I would express this with {json-api}, if anyone else has come up with an approach they’re happy with. ---
**Author:** ![michaelhibay](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/michaelhibay/32/405_2.png) [@michaelhibay](https://discuss.jsonapi.org/u/michaelhibay)\ **Post date:** [February 27, 2018, 6:58pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/4 "2018-02-27T18:58:30Z")
That is completely legitimate {json:api}, I’m not sure what else you’re looking for. You could add some kind of filter alias and use that as a search term for it on the front end, but it’s completely valid design as far as the spec is concerned. ---
**Author:** ![patience.tema.baron](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@patience.tema.baron](https://discuss.jsonapi.org/u/patience.tema.baron)\ **Post date:** [February 28, 2018, 12:47am UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/5 "2018-02-28T00:47:10Z")
Just wanted to make sure I wasn’t missing something. Thanks for the help, @michaelhibay! ---
**Author:** ![michaelhibay](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/michaelhibay/32/405_2.png) [@michaelhibay](https://discuss.jsonapi.org/u/michaelhibay)\ **Post date:** [February 28, 2018, 12:37pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/6 "2018-02-28T12:37:49Z")
My pleasure, I think you pretty much had it right from the get-go but glad things are cleared up for you! ---
**Author:** ![Toby](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/toby/32/628_2.png) [@Toby](https://discuss.jsonapi.org/u/Toby)\ **Post date:** [August 17, 2019, 4:57pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/7 "2019-08-17T16:57:46Z")
I’ve been scratching my head over this use-case as well and I have a few questions: 1. Is there no issue with having a relationship for “current-user-like” or “my-like” on the post resource that **has a different value depending on what user is authenticated**? That would also result in the posts/1/my-like endpoint representing a different resource depending on who is authenticated. I’ve read in some places that resources should have the same representation regardless of who is viewing them. 2. If that’s not an issue, then does it go for attributes as well? Could you simply have an “isLiked” attribute on the post resource which is true/false depending on if the authenticated user has liked it? ---
**Author:** ![maark](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/maark/32/184_2.png) [@maark](https://discuss.jsonapi.org/u/maark)\ **Post date:** [August 18, 2019, 2:35pm UTC](https://discuss.jsonapi.org/t/include-resource-but-only-if-current-user-created-it/1218/8 "2019-08-18T14:35:21Z")
@Toby I think your point is valid and I would **never** implement the feature discussed here this way. Authentication should only impact your permission to make a certain request. It’s a yes or no. You either can or can’t. I’m not saying it’s not valid JSON:API. It’s a personal choice. If I couldn’t find a nice way to implement this feature without avoiding this, I would just make the client do two requests.