Clarify processing rules for malformed ext and profile members of JSON:API object (#1607)

jelhan · dgeb · web-flow · commit f1a2fcde71c7 · 2022-06-10T08:00:21.000-04:00
* Clarify processing rules for malformed `ext` and `profile` members of 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.

* Update _format/1.1/index.md

Co-authored-by: Jeldrik Hanschke &lt;jelhan@users.noreply.github.com&gt;

* Update _format/1.1/index.md

Co-authored-by: Dan Gebhardt &lt;dan@cerebris.com&gt;
diff --git a/_format/1.1/index.md b/_format/1.1/index.md
@@ -831,6 +831,10 @@ The jsonapi object **MAY** contain any of the following members:
 * `profile` - an array of URIs for all applied [profiles].
 * `meta` - a [meta] object that contains non-standard meta-information.
 
+Clients and servers **MUST NOT** use an `ext` or `profile` member for content
+negotiation. Content negotiation **MUST** only happen based on media type
+parameters in `Content-Type` header.
+
 A simple example appears below:
 
 ```json
