Clarify processing rules for malformed ext and profile members of JSON:API object
#1607
Conversation
… JSON:API object The applied extension and profiles must be provided as `ext` and `profile` media type parameters of `Content-Type` header. Additionally they may be listed as `jsonapi.ext` and `jsonapi.profile` member of a JSON:API document. This opens up the possibility of having different values in both places. So far the specification has not defined processing rules for such malformed documents. This clarifies that a client and server must honor the `Content-Type` header in case of a conflict. Additionally it clarifies that they should not reject the document but ignore the invalid `jsonapi.ext` and/or `jsonapi.profile` members. Ignoring them in case of a conflict rather than rejecting the document allows server and clients to _not_ process them at all - even if present. This avoids computing overhead just for the sake of validating the document.
|
I agree entirely with the sentiment behind this PR, which is that content negotiation should occur using headers ( I believe that the guarantees we want to provide are:
I think this combination of guarantees should prevent unnecessary validation while still providing a reasonable assumption of correctness if these members are present. @jelhan what do you think? Would this combination of normative changes address your concerns? |
There was a problem hiding this comment.
Yes. I think your proposal makes sense. Enforcing validation was not my intent. I provided a potential rewording as review comment.
To be honest I'm not sure what value ext and profile members of jsonapi provide. They seem to only duplicate information already available in Content-Type header. Not sure if I missed a relevant discussion about the use cases they address.
Co-authored-by: Jeldrik Hanschke <jelhan@users.noreply.github.com>
The applied extension and profiles must be provided as
extandprofilemedia type parameters ofContent-Typeheader. Additionally they may be listed asjsonapi.extandjsonapi.profilemember of a JSON:API document.This opens up the possibility of having different values in both places. So far the specification has not defined processing rules for such malformed documents.
This clarifies that a client and server must honor the
Content-Typeheader in case of a conflict. Additionally it clarifies that they should not reject the document but ignore the invalidjsonapi.extand/orjsonapi.profilemembers.Ignoring them in case of a conflict rather than rejecting the document allows server and clients to not process them at all - even if present. This avoids computing overhead just for the sake of validating the document.
Closes #1359