You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposing to add support for "$templatedRef" to Reference Objects supporting templated references, allowing referencing dynamic schemas that could be retrieved by substituting the template variables by the selected value for earlier path parameters
so that later path parameters can be defined differently based on earlier path parameters.
The {collectionId} template would be replaced by a selected value like collection1.
(e.g. in this example, this "$templatedRef" is used to define the valid values for {styleId} in a path /collections/{collectionId}/styles/{styleId}).
The {collectionId} would have previously been validated against another potentially dynamic list like "$ref" : "./api/collections".
The context being that available/compatibles styles depend on the selected collection.
Such a capability would allow to define much more interoperable APIs, where the specifics of a particular instance / deployment would be left to the templated references. In turn this would allow to automatically generate clients from an API definition that will work with multiple instances of the same templatable API, therefore extending the usability of clients automatically generated from OpenAPI definitions beyond on-the-fly client generation, more suitable for compiled programming languages.
The text was updated successfully, but these errors were encountered:
Proposing to add support for "$templatedRef" to Reference Objects supporting templated references, allowing referencing dynamic schemas that could be retrieved by substituting the template variables by the selected value for earlier path parameters
so that later path parameters can be defined differently based on earlier path parameters.
Example:
As it was initially suggested that this would require to first extend JSON schema, an initial discussion took place in json-schema-org/json-schema-vocabularies#36 . However reading on https://swagger.io/specification/ that the Reference Object is defined by the JSON Reference, rather than by JSON Schema, it seems that this could rather simply be extended with
$templatedRef
, following https://tools.ietf.org/html/rfc6570 (or a simpler subset of it).The
{collectionId}
template would be replaced by a selected value likecollection1
.(e.g. in this example, this "$templatedRef" is used to define the valid values for
{styleId}
in a path/collections/{collectionId}/styles/{styleId}
).The
{collectionId}
would have previously been validated against another potentially dynamic list like"$ref" : "./api/collections"
../api/collections
would return something like:and
./api/collection-styles/collection1
would return something likewhile
./api/collection-styles/collection2
would return something likeThe context being that available/compatibles styles depend on the selected collection.
Such a capability would allow to define much more interoperable APIs, where the specifics of a particular instance / deployment would be left to the templated references. In turn this would allow to automatically generate clients from an API definition that will work with multiple instances of the same templatable API, therefore extending the usability of clients automatically generated from OpenAPI definitions beyond on-the-fly client generation, more suitable for compiled programming languages.
The text was updated successfully, but these errors were encountered: