there are some old close issues#547 (comment)

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.

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.

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 setJSON_API_FORMAT_FIELD_NAMES andJSON_API_FORMAT_TYPES tocamalize. This is fairly simple and is backwards compatible
2. Change default field format tocamelize. 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 alwayscamelize. 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?

To talk about @-Members: As far as I understandthe 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?

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