consider support for implementation-specific members

[jelhan]

The JSON:API specification forbids implementation-specific members unless they are explicitly allowed:

Unless otherwise noted, objects defined by this specification or any applied extensions MUST NOT contain any additional members. Client and server implementations MUST ignore non-compliant members.

@lode proposed relaxing this statement to allow implementation-specific members of links object. Similar to implementation-specific query parameters we could allow implementation-specific members.

I feel we should discuss this not only with perspective on links object. Similar arguments could be made for implementation-specific members of relationship object, an error object, or even the document itself. I think we should discuss if we want to allow it in general.

Extensions allow adding extension-specific members:

An extension MAY define new members within the document structure defined by this specification.

All use cases for implementation-specific members are already covered by extension. Not requiring content negotiation would be the only advantage of implementation-specific members over members defined by extensions.

I feel requiring extensions and explicit content negotiation is more future proof. Especially as implementation-specific members could cause conflicts if implementations at client- and server-side are not compatible. Content negotiation for extensions prevents these.

On the other hand the same argument could be made regarding query parameters. And we decided to support implementation-specific query parameters.

Opening up this issue to gather feedback both from implementers as well as other editors of the spec.

[lode]

Nice to discuss this @jelhan!

I'm not sure about opening up this to everywhere in the document, although I understand your reasoning.

My request for the links object also came from my thought (I admit, my confusion) that the links object had the same free rules as attributes, relationships and meta.

Also, to me it is logical that the links object contains user data (conceptually, not currently in the spec). Where as in the rest of the document I feel that need less, there the document describes structure / meaning.

[lindyhopchris]

yeah agree, I think opening it up for the links object is ok, but relaxing it across the whole document feels potentially dangerous.