Jsonapi-resources: How to hide Relationship links ?

[tbuyle]

I have two ressource related to each other : Article and Comment

I defined the has_many and has_one relations for the ressources.

When getting Article data (either on /articles or on /articles/:id), the answer always include the relationship links :

{
  "data": [
    {
      "id": "1",
      "type": "article",
      "attributes": {
        "title": "My Article",
         ...
      },
      "relationships": {
        "comments": {
          "links": {
            "self": "http://localhost:4099/articles/1/relationships/comments",
            "related": "http://localhost:4099/articles/1/comments"
          }
        }
      }
    }
  ]
} 

I'd like to remove the "links" for the relationship and, ideally, have the "relationships" block only if there is "data" to display.

[evolve2k]

Hi @tbuyl

This library is attempting to stick tightly to the JSON API Spec 1.0 which is full of MUST and REQUIRED and OPTIONAL sorts of statements.

Please have a read over the spec and report back where you think there is grounds for making this optional.
http://jsonapi.org/format/

Sorry for more work, just trying to help the maintainers as there are a crazy number of open issues on this repo (159 as of today!)

Note to Admins: Recommend close (@tbuyle can reopen if he comes back with a valid use case and a reference to a change that would fit the spec.)

[tbuyle]

According to JSON API Spec 1.0 :

In Structure > Resource Objects

...
In addition, a resource object MAY contain any of these top-level members:

• attributes: an attributes object representing some of the resource’s data.
• relationships: a relationships object describing relationships between the resource and other JSON API resources.
• links: a links object containing links related to the resource.
• meta: a meta object containing non-standard meta-information about a resource that can not be represented as an attribute or relationship.

As I understand it, the specs make it optional to return the _relationships object_ in the _resource object_ since it may (not must) be contained and there is no mention of an obligation to return the _relationships object_ when fetching single or multiple ressources.

My current use case is an API to connect with mobile device (barcode scanner) where we would like to minimize the data returned for a request for two reasons :

• less data = smaller and faster.
• The developer in charge of the device application is not used to JSON API and the less data he receives the easier it will be to have him understand what to do with it (changing developer is currently not an option).

[lgebhardt]

The relationship is being returned as required by the spec http://jsonapi.org/format/#document-resource-object-relationships (technically we could give you the option of returning an empty meta object, but we don't have an option for that).

You are getting the relationships because they are included in the default fields list. You can omit them from the client by specifying the fields you wish to receive. If there are no relationships requested at all the entire relationships section will be removed. I added #855 (default fields option) after thinking about this request.

[tbuyle]

As far as I understand the specs :

http://jsonapi.org/format/#document-resource-objects mentions that the relationships object MAY be included in a resources object.

http://jsonapi.org/format/#document-resource-object-relationships mentions what MUST be included in an relationships object. It does not seem to require the object to be included in resources object.

But I may be wrong in my understanding.

855 would indeed be a good enhancement to cover this case.

I'm closing this issue then.

Thanks

[lgebhardt]

@tbuyle You are correct. For clarification I was saying JR is returning the relationships in a format as required by the spec. JR can choose to not return a relationship and does so based on the fields. Given we have the fields approach I do not wish to extend JR to have a secondary method of excluding the relationship fields as I think it would add a lot of confusion when combined with the existing fields approach. I'll see what I can do to get #855 implemented.

[santostiago]

Hi! Any news on this subject?
I have a request of an endpoint that has plenty of "has_many" relationships, and the links account for more than 80% of the response's load.

[Subtletree]

This is now possible in 0.9.7 🎉
http://jsonapi-resources.com/v0.9/guide/resources.html#Default-Links