# "hide" unfetchable relationships, return 404, other?

**URL:** <https://discuss.jsonapi.org/t/hide-unfetchable-relationships-return-404-other/1405>\
**Category:** Uncategorized\
**Created:** [October 17, 2018, 5:29pm UTC](https://discuss.jsonapi.org/t/hide-unfetchable-relationships-return-404-other/1405 "2018-10-17T17:29:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![n2ygk](https://avatars.discourse-cdn.com/v4/letter/n/50afbb/32.png) [@n2ygk](https://discuss.jsonapi.org/u/n2ygk)\
**Post date:** [October 17, 2018, 5:29pm UTC](https://discuss.jsonapi.org/t/hide-unfetchable-relationships-return-404-other/1405/1 "2018-10-17T17:29:00Z")

</div>

Is there a best practice for the case where [relationships](https://jsonapi.org/format/#document-resource-object-relationships) resource objects are not authorized to be fetched even when fetching their “parent” [resource object](https://jsonapi.org/format/#document-resource-objects) is allowed? Potential options could be to “hide” those relationships’ [resource linkage](https://jsonapi.org/format/#document-resource-object-linkage) [resource identifier object(s)](https://jsonapi.org/format/#document-resource-identifier-objects) by returning `null` for a to-one relationship or omitting some or all array elements for a to-many.

Hiding the relationships has the advantage of protecting the disallowed resource object(s) from being fetched (even if it’s just the type and id) but the disadvantage of misrepresenting the lack of existence of relationships – which is OK by me if the child related resource is not allowing itself to be fetched.

An alternative would be to fail the entire fetch of the resource object, returning a not found error object (or set of error objects perhaps identifying that the related resource fetch was the cause).