As @wimleers pointed out in his original review of #1268, we don't currently say what happens when a different list of profiles is specified in the document (in links.profile) than in the Content-Type header.

I've been thinking about a bunch of options and have concluded that the solution I offered in my original response to Wim's comment — i.e., making any mismatch trigger a 400 — is the wrong way to go. One issue with that solution is that it only covers documents sent to the server; i.e., it doesn't cover how the client should process documents sent from the server that have the same mismatch. (We could say that the client must entirely discard such responses... but I'm not sure clients would actually do that.) Another problem with the 400 approach — and actually any approach that requires the recipient to read both lists of profiles — is that it introduces a preprocessing step (e.g., to check that the lists match), and we have to pay the cost of that preprocessing step on every request, even though a mismatch should be a very rare event. That seems like a bad idea.

So, my preferred approach at this point, which is embodied in this PR, is simply to treat links.profile as the definitive list of applied profiles in the event of any mismatch. By treating one list as definitive, recipients can simply ignore the other (no comparison step required), but we can keep both in the spec, which is nice because both bring something of value. (Specifically, if we removed the parameter on Content-Type, profile negotiation would look pretty asymmetrical; i.e., the client would use the profile parameter in Accept, but not get it back in the response. Meanwhile, links.profile is offering an elegant place to list profile aliases, which have to go in the document somewhere.)

I chose to treat links.profile as the definitive source because recipients have to look there anyway before processing the document (to check for aliases), so making that the only place they have to look to determine the applied profiles seemed to make the most sense.

Note: one small issue with making links.profile definitive is that the "missing a server-required profile error" from #1354 would probably have to be a 400 rather than a 415, because the required profile actually could be listed in Content-Type but still be "missing" if its not listed in links.profile. I think that's fine, but it means #1354 will have to be tweaked after this PR is merged.

Note 2: Wim also pointed out that we don't say what should happen when the client lists a profile in the profile query parameter that isn't in its Accept header. But I think that case is already covered implicitly, and the answer is that the server should pay attention to the query parameter. That's because JSON:API says that the profile query parameter lists required profiles -- while both HTTP and JSON:API say that a profile can be applied to a response document even if it isn't in the Accept header.