I’m in the same situation, having implemented a permissions system where after user A comments on user B’s post, user B might make that post private. /api/comments/{comment_id} returns a comment like:
{
"data": {
"type": "comments",
"id": 123,
"attributes": {
...
},
"relationships": {
"author": {
"data": {
"type": "users",
"id": 456
}
},
"post": {
"data": {
"type": "posts",
"id": 789
}
}
}
}
}
So if I visit /api/…/comments/{comment_id}?include=posts I’m not sure what to put in the “included” array after user B’d post 789 becomes private. I think my choices are:
-
return the relationship’s post’s id but don’t include the post in the “included” array when ?include=posts is requested (I think this violates JSON API wanting every included item for corresponding relationship ids to be listed when requested)
-
return 200 for non-include requests but return “400 Bad Request” for include requests if the server can’t fulfill the request because the included post is private: http://jsonapi.org/format/#fetching-includes (however this makes returning collections of comments brittle because one private post could kill the whole response)
-
don’t return the comment at all (have the comment inherit the post’s privacy), however this makes it hard for users to delete their own comments after related posts become private (because they can’t see their own comments after that)
-
list the post in the included array but only include the type and id, leaving out attributes (this could crash clients that aren’t expecting this behavior)
-
don’t include the “post” key in relationships, which avoids it being included (this could crash clients that aren’t expecting this behavior)
-
include the post in “included” but set all of the attributes to their default values (empty strings etc) to obscure them. this prevents clients from crashing but could be confusing for users
I’m leaning towards #1 and making clients check for the posts’s existence in the “included” array. If they forget to check, their app will crash if it’s expecting an included post there. This is how my ORM is behaving currently due to implementing permissions.
Update - this message recommends failing completely, however that would be brittle for collection responses: Multi-status responses (partial success in particular)