Felicity

Felicity copied to clipboard

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 https://github.com/json-api/json-api/issues/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 https://github.com/json-api/json-api/issues/1675#issuecomment-1293335269
• [ ] Additional link object (see also error links) and jsonapi object members (wait for valid use-cases to inform the API design?)

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.