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.
IJsonApiOptionshas a newExtensionsproperty, andJsonApiOptionshas a newIncludeExtensionsmethod, to indicate which extensions are enabled API-wide.IJsonApiContentNegotiatorwith implementationJsonApiContentNegotiator, which provides a virtualGetPossibleMediaTypesmethod to indicate which combinations of extensions are allowed for the current request.IJsonApiRequest.Extensionscontains 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-Typeheader is incompatible with theAcceptheader.The properties on
HeaderConstantshave been obsoleted, in favor of the newJsonApiMediaTypeandJsonApiExtensiontypes.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 (
Documentclass) 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 inCustomExtensionssubdirectory).Bugfix: Always require clients to send an
AcceptHTTP 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