Basic support for third-party JSON:API extensions #1623
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds basic support for developing your own JSON:API extensions.
IJsonApiOptions
has a newExtensions
property, andJsonApiOptions
has a newIncludeExtensions
method, to indicate which extensions are enabled API-wide.IJsonApiContentNegotiator
with implementationJsonApiContentNegotiator
, which provides a virtualGetPossibleMediaTypes
method to indicate which combinations of extensions are allowed for the current request.IJsonApiRequest.Extensions
contains the active extensions for the current request.While JSON:API doesn't specify it as a requirement, JsonApiDotNetCore assumes that an extension always applies to both the request body and the response body, for simplicity. An error is returned when the
Content-Type
header is incompatible with theAccept
header.The properties on
HeaderConstants
have been obsoleted, in favor of the newJsonApiMediaType
andJsonApiExtension
types.Now that the basic building blocks are in place (which we need for supporting OpenAPI with resource inheritance), the next step (no promises) would be to enable extending the JSON:API request/response body data structure (
Document
class) with extension-prefixed members. I suspect we'd need that at the top level, in resource objects, and relationship objects. Please open an issue to express your ideas and/or requirements. Right now, obtaining the request body requires some service container magic (see tests inCustomExtensions
subdirectory).Bugfix: Always require clients to send an
Accept
HTTP header when an extension is used; this is required by JSON:API. This currently affects the usage of atomic:operations.This PR optimizes test execution by reducing redundant parsing of the JSON:API media type.
Aside from the text above, no documentation page is provided yet, because we don't have a solid end-to-end use case for developing a custom JSON:API extension at the moment. Feedback welcome!
QUALITY CHECKLIST