Support JSON:API 1.1

[cmeeren]

Required to implement:

• Support ext and profile media type parameters (5.4)
  • Content-Type (6.3):
    • Return 415 if it contains parameters other than ext and profile
    • Return 415 if it contains an ext parameter with an unsupported extension URI
  • Accept (6.3):
    • Ignore instances with parameters other than ext and profile (and q)
    • Return 406 if all instances are modified with parameters other than ext and profile (and q)
    • Return 406 if all instances have at least one unsupported ext URI
  • Specify the Vary header with Accept as one of its values (6.3)
• Possible changes in member name validation
  • Including inside [] in query parameter families, see 1.1 spec disallows e.g. filter[author.name] json-api/json-api#1689
• Add header error source

Optional:

• Find candidate profiles and extensions to support
  • Specify ext and/or profile in the Content-Type header if any extensions/profiles are applied (6.1)
• lid for creating self-referential resources? Is this mandatory? See How is 'lid' actually used? The 1.1 spec says nothing about this json-api/json-api#1675 (comment)
• Additional link object (see also error links) and jsonapi object members (wait for valid use-cases to inform the API design?)

[cmeeren]

Just mentioning for the record that I have started working with GraphQL (using HotChocolate) and currently find that a much more compelling and flexible way to design APIs than JSON:API. I may therefore never get around to this task.

Felicity is still used in a lot of our current APIs, but I imagine we will use GraphQL for new APIs, so there may not come much in terms of new new features for Felicity.