JSONAPI linked entity names.

[wln]

Hi -- finally getting around to preparing tested version of the modifications I made to my fork a couple months ago, and looking for how-to-handle advice.

JSONAPI specifies that:

Related documents MUST be included in a top level "linked" object, in which they are grouped together in arrays according to their type.

The type of each relationship MAY be specified in the "links" object with the "type" key. This facilitates lookups of related documents by the client.

The oat mechanism for linked entities (entity or entities) currently collects linked entities under the relationship name, rather than the type of the linked entity. (in some examples from the JSONAPI spec, under author rather than people).

A change to use types instead of link names would be a breaking change to the current behavior of the entity/entities serializer rules. Should I handle these by:

• fully replacing the functionality (cause the break) and modifying the tests to match,
• provide a global flag to use new/old behavior (default which way?)
• provide a per-invocation flag to use one behavior or the other (plus maybe a global to specify default?, which way to default if not specified?),
• some other approach?

Thanks.

[ismasan]

Hi. Sorry I took so long to respond. I'm just back from holidays!

Specs like JSON API are still moving targets and that's why I suggested extracting them into separate gems a while ago. Maybe this would be a good time to do that? In that way individual adapters can be evolved incrementally (with their own release cycle to match new version of the corresponding specs) with less fussing about with the core Oat library, and without the dependency on me as the maintainer. It would give JSON API Oat users more freedom of movement.

Of course for that to work well Oat needs to have a stable and solid API that 3rd party adapters can rely on, so I'll be happy to discuss what might be missing or needs to change.

@kjg might be interested in this discussion as well, as he's contributed most of the JSON API stuff.

Hope this helps.

[kjg]

I created a repo and everything for the extraction :) I just never finished https://github.com/kjg/oat-jsonapi. I'll try to finish that up

[ahx]

Hey @kjg do you have something to show already? Even if it's just a hack, maybe you can make it available so we can try to help with the extraction?

[smasry]

I've implemented most of the latest changes for the jsonapi spec here https://github.com/smasry/oat/tree/jsonapi-updates

[smasry]

@ismasan I've got the jsonapi adapter to a good spot. Do you still want to have this as a gem or would you rather I submit a pull?

[ismasan]

@smasry hey thanks. I think a gem would be ideal. We can announce it here with a link to your repo, before publishing the gem, so Oat users actively using JsonAPI can chip in and help polish off any kinks? I'm also interested in coming up with a good public API for gem authors. When it's published I can remove JSONAPi from Oat and point users to the new gem.

[sandstrom]

Has this issue been solved?

I'm considering using Oat instead of AMS. I often checkout issues to get a feel for where the project stands.