Remove profile aliasing from 1.1-rc2 #1412
Conversation
|
@gabesullice thanks for breaking out this change as a separate PR. LGTM. |
|
IIRC I also found aliasing one of the more confusing things to wrap my head around. I wanted to read it again on the website to try to remember what exactly I found confusing, but now there's only https://jsonapi.org/format/1.1/, the 1.1-RC1 release is gone. Is this intentional or accidental? |
|
@wimleers Sorry for the confusion. We have reverted 1.1 to be a working draft as per this discussion: #1403 (comment) I'm working with @gabesullice to stabilize a modified vision for 1.1 ASAP. |
|
I know! But I think that for posterity sake and for full transparency, it'd be good to keep old RCs around. "Cool URIs don't change" :) But I just noticed that the old URL was indeed also Ignore my request :) |
|
Well I totally agree about URIs not changing. And I'm open to publishing each RC to its own URL and leaving it available in perpetuity. |
This PR is derived from #1410 which included this same alias removal. Per @dgeb' s request, I've broken this out into its own PR. I agree that this will make this change easier to review and consider.
This PR supersedes #1362.
Motivation
Aliasing anticipates a problem that I'm not yet convinced we'll encounter. That is, it attempts to make it possible for a server to support profiles with conflicting keywords.
Unfortunately, aliasing is not a trivial thing to implement on the client or the server. A global dictionary must be computed for every HTTP message by either the client or the server. There is no guarantee that two implementations will use the same aliases, nor that they will even use the same aliases between requests. In systems that have hierarchical (de)serialization components, that global dictionary must be shared between them and that can be a cumbersome process. Even after deserialization, every processor must also know about the aliases too, since processors will be looking for specific keywords.
I propose we remove aliasing from v1.1 of the spec. If they really does become necessary, it shouldn't be too difficult to add them to a subsequent version of the spec.