Hi 👋
Would be great to have more control (being able to customize) how a resource relationships object is serialized.
Per the v1.1 spec https://jsonapi.org/format/#document-resource-object-relationships
A “relationship object” MUST contain at least one of the following: links, data, meta.
Being able to control the content of data, links and meta for the relationship object.
To name a few:
- Being able to render only links - no data or meta (not possible, example naive patch)
- Being able to render only data - no links or meta (technically possible, but you need to globally set
add_auto_links: false which also removes pagination links and other links elsewhere)
- Able to customize which links are rendered (not possible)
- only self
- only related
- both
- other?
- being able to customize what the links are set to instead of the defaults
- continue to have control of whether the relationship is included in
included for a compound document or not (possible)
- Being able to render meta (not possible)
As of today all you can do to customize a relationship is to set :included or not in the 3rd tuple element in
defmodule PostView do
use JSONAPI.View, type: "posts"
def relationships do
[comments: CommentView]
end
defmodule PostView do
use JSONAPI.View, type: "posts"
def relationships do
[comments: {CommentView, :included}]
end
Maybe we could use this 3rd element to eventually be a more capable configuration structure? Like accept there a keyword list with configuration options?
Thanks in advance.
Hi 👋
Would be great to have more control (being able to customize) how a resource relationships object is serialized.
Per the v1.1 spec https://jsonapi.org/format/#document-resource-object-relationships
Being able to control the content of
data,linksandmetafor the relationship object.To name a few:
add_auto_links: falsewhich also removes pagination links and other links elsewhere)includedfor a compound document or not (possible)As of today all you can do to customize a relationship is to set
:includedor not in the 3rd tuple element inMaybe we could use this 3rd element to eventually be a more capable configuration structure? Like accept there a keyword list with configuration options?
Thanks in advance.