Customizing relationships

[pattisdr]

Problem

extract_relationships should be able to handle specialized cases, like allowing a links or meta object instead of a data object. For example, in our application it needs to:

1. recognize other field types as relationships
2. return a links object instead of a data object with type/id

The relationship data is read-only.

Desired

Potential solutions

@jerel suggested a serializer hook like add_relationships for customization.

According to the spec, under relationships you must include a links, data, or meta object. http://jsonapi.org/format/#document-resource-object-relationships. The current extract_relationships just allows for a data object. It would be valuable for users to be able to have a links object, instead.

[jsenecal]

Commenting for clarity: According to the spec, a "relationship object" MUST contain at least one of the following: links, data, or meta object.

Going through the data included in fields looking for link-like data would require too much processing power and IMO introduce too much magic.

What is your API structure if you don't mind?

[pattisdr]

What do you mean by API structure?

[jsenecal]

I'm trying to get a glimpse of what/how you are using the endpoints. What are your registered URLs looking like?

On Aug 17, 2015 10:05 AM, Dawn Pattison notifications@github.com wrote:

What do you mean by API structure?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54#issuecomment-131828667.

[pattisdr]

We have projects, called 'nodes'. If I want to access node detail, I get this:

Note: To get this formatting I am using a fork of your package pattisdr@f12101f. The relationships like children and contributor are using a custom HyperlinkedIdentityField that returns a link, optional meta information like count, and optional link type like self or related.

From Swagger docs, here is a list of available url's:

[jsenecal]

Okay, so I introduced support for HyperLinkedIdentityField in #80 (Commit 389db44)

Please check if this solves your use case. I would strongly advise waiting for PR #82 before using this in production though as some bugs were fixed there...

[jerel]

@pattisdr closing this based on feedback in Gitter chat room. If it was premature let me know