Skip to content

DRF J-A renders nested serializers out of spec. #769

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bpleshakov opened this issue Feb 16, 2020 · 3 comments · Fixed by #776
Closed

DRF J-A renders nested serializers out of spec. #769

bpleshakov opened this issue Feb 16, 2020 · 3 comments · Fixed by #776

Comments

@bpleshakov
Copy link
Contributor

Hi there.
Json-api spec states:

Attributes may contain any valid JSON value.

Complex data structures involving JSON objects and arrays are allowed as attribute values. However, any object that constitutes or is contained in an attribute MUST NOT contain a relationships or links member, as those members are reserved by this specification for future use.

Source: https://jsonapi.org/format/#document-resource-object-attributes

However, considering this and this any nested serializer would be rendered as resource relations even though the nested structure is not a resource.

@sliverc
Copy link
Member

sliverc commented Feb 25, 2020

I see your point that nested serializers should actually be serialized as json value. The only thing I am a bit worried about when implementing this is backwards compatibility. If someone uses nested serializer though I guess it would only work with ModelSerializer with the current implementation.

So an implementation could be that nested model serializer continue to be serialized as relations but a deprecation warning will be printed that ResourceRelatedField should be used.
All other serializers can then render to a json value.

This is just an idea but open for discussion and PRs.

As a side note currently when using using JSONField it is possible to contain any JSON value in attribute which might be used as a workaround till a fix has been developed for this issue.

@bpleshakov
Copy link
Contributor Author

Actually it is possible to implement two strategies and configure which one to be used in settings:
The first strategy is to leave it as it works now, and the second is to serialize any nested serializer as an attribute.

For now, the first strategy would be set as default with a deprecation warning, and we will change this behavior in the future releases.

Or we can think about a mechanism to specify how to treat each nested serializer separately which is even more flexible.

@sliverc
Copy link
Member

sliverc commented Mar 8, 2020

I like your first idea with a strategy setting. This way the deprecation warning can warn new users which might think nested serializer serialize to json and what they need to do if they want to. And for old users it shows them that they should adjust their code to use ResourceRelatedField.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants