Adding support for JSON:API v1.1

[pauloxnet]

JSON:API v1.1 was finalized September 30, 2022

Here is a list of what has changed and we need to implement in Django REST framework JSON:API to be fully compatible. This list may not be complete. Please comment in case there is something missing.

• @-Members
• return included array even if nothing is included - JSON API 1.1: return included array even if nothing is included #1109
• lid attribute
• profiles
• extensions
• return what jsonapi version is used
• camelCase recommendation

Those are just keywords and links what has changed, but it is not necessarily clear, how to implement it in DJA. Let's use this discussion to discuss the single changes. Once it is clear how it can be implemented, we can then create single issues and start implementing it.

[auvipy]

there are some old close issues #547 (comment)

[sliverc]

Thanks for the heads up. That is great news! I recommend we analyze what needs to change in DJA to support JSON:API 1.1 and collect it in this discussion. Some changes might be obvious and issues can be created directly. Other changes might need more in depth discussion how we implement it.

[sliverc]

I have changed the initial description so we can use it to observe our progress implementing JSON:API v1.1. I have added what I have found has changed going through the new specification. As noted, those are just links and keywords. It is not necessarily clear how to implement it in DJA. Let's discuss it here one by one and create an issue once the implementation details are clear. Once the issues are created we can then start implementing it.

Also, I have pinned this discussion so it is easily discoverable by others as well.

[sliverc]

So, starting this thread that we can discuss how we want to implement the camelCase recommendation.

I see three ways forward:

1. add recommendation to documentation/README.md to set JSON_API_FORMAT_FIELD_NAMES and JSON_API_FORMAT_TYPES to camalize. This is fairly simple and is backwards compatible
2. Change default field format to camelize. Not backwards compatible, but easy for new users to follow JSON:API recommendation. We would have to have a deprecation cycle so that existing users know of this change ahead of time.
3. Drop support to have custom formatting and always camelize. This would remove complexity of DJA, but as it is only a recommendation it would also restrict DJA users.

When we look at our goals, one is to be as easy to pick up as possible. So for that reason, option 2 or maybe even option 3 would be the best. In terms of simplicity, option 1 would be better as it does not affect existing users. To start with, I tend towards option 1. What are your thoughts?

[auvipy]

we can always start with the small steps like the option 1 to kickstart

[sliverc]

Sure, that is an option. Start with option 1 and once our JSON:API 1.1 implementation is more complete, move towards option 2.

On another note, I created issue #1109 as there is no discussion needed for that item.

[sliverc]

To talk about @-Members: As far as I understand the specification there is no real use case for DJA directly so we can simply ignore them. The question for us is, what does a developer need to do, if they want to use @-Members while using DJA.

My first impression is that we simply clean out all @-Members in our parser. So for @-Members to be used, a developer would need to implement a custom parser and renderer which can be derived from the DJA classes. That is the easiest for us, but might not be the best for external dev. However, I am not so sure what those @-Members could be used for though so hard to say. Any thoughts?

[auvipy]

return what jsonapi version is used I think this option would be easier too