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.
In an OpenAPI spec I'm trying to define, I need to be able to
$ref
out to Schemas defined in another OpenAPI contract. I'm trying to reuse some Schema types from another external contract without having to inline them into my contract. According to the OpenAPI spec (as far as I understand it), this is supported, since JSON References are URIs that can be absolute or relative and therefore can be pointed to an external file.Unfortunately,
openapi3
treats References like names to entities defined within the current OpenAPI contract. This is fine if all your entities are defined wholly within your own contract, but if you want to reference things externally, you can't.An example external reference URI is:
https://raw.githubusercontent.com/OAI/OpenAPI-Specification/80c781e479f85ac67001ceb3e7e410e25d2a561b/schemas/v3.0/schema.json#/definitions/Schema
(a reference to the schema of OpenAPI's Schema 😉)This PR is an attempt to solve this by modifying the Reference newtype and changing it into a sum type:
InternalReferences are handled with exactly the same behaviour as the old newtype Reference. ExternalReferences are basically treated opaquely and the URI within them in simply serialized/deserialized to JSON verbatim.
I'm not sure if this is necessarily the right approach to solve the problem, but I thought I'd submit it as food for thought and see what you thought about it. There are a couple of disadvantages: