Skip to content

Commit 267ee0b

Browse files
committed
Improved examples
Including fixing a bug in one of the URIs.
1 parent 47c3194 commit 267ee0b

File tree

1 file changed

+28
-5
lines changed

1 file changed

+28
-5
lines changed

src/oas.md

Lines changed: 28 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4928,19 +4928,36 @@ In the `other` document, the referenced path item has a Security Requirement for
49284928
A base URI within the resource's content (RFC3986 Section 5.1.1) is the highest-precedence source of a base URI.
49294929
For OpenAPI Documents, this source is the OpenAPI Object's `$self` field, while for Schema Objects that contain a `$id`, or are a subschema of a Schema Object containing a `$id`, the source is the `$id` field:
49304930

4931+
Assume the retrieval URI of the following document is `file://home/someone/src/api/openapi.yaml`:
4932+
49314933
```YAML
49324934
openapi: 3.2.0
4933-
$self: https://example.com/openapi
4935+
$self: https://example.com/api/openapi
49344936
info:
49354937
title: Example API
49364938
version: 1.0
4939+
paths:
4940+
/foo:
4941+
get:
4942+
requestBody:
4943+
$ref: "shared#/components/requestBodies/Foo"
4944+
```
4945+
4946+
Assume the retrieval URI for the following document is `https://git.example.com/shared/blob/main/shared/foo.yaml`:
4947+
4948+
```YAML
4949+
openapi: 3.2.0
4950+
$self: https://example.com/api/shared/foo
4951+
info:
4952+
title: Shared components for all APIs
4953+
version: 1.0
49374954
components:
49384955
requestBodies:
49394956
Foo:
49404957
content:
49414958
application/json:
49424959
schema:
4943-
$ref: schemas/foo
4960+
$ref: ../schemas/foo
49444961
schemas:
49454962
Foo:
49464963
$id: https://example.com/api/schemas/foo
@@ -4952,7 +4969,12 @@ components:
49524969
type: string
49534970
```
49544971

4955-
In the example above, the `$ref` in the Request Body Object is resolved using `$self` as the base URI, producing `https://example.com/schemas/foo`.
4972+
In this example, the retrieval URIs are irrelevant because both documents define `$self`.
4973+
4974+
For the relative `$ref` in the first document, it is resolved against `$self` to produce `https://example.com/shared/foo#/components/requestBodies/Foo`.
4975+
The portion of that URI before the '#' matches the `$self` of the second document, so the reference target is resolved to `#/components/requestBodies/Foo` in that second document.
4976+
4977+
In that document, the `$ref` in the Request Body Object is resolved using that document's `$self` as the base URI, producing `https://example.com/schemas/foo`.
49564978
This matches the `$id` at `#/components/schemas/Foo/$id` so it points to that Schema Object.
49574979
That Schema Object has a subschema with `$ref: bar`, which is resolved against the `$id` to produce `https://example.com/schemas/bar`, which matches the `$id` at `#/components/schemas/Bar/$id`.
49584980

@@ -4962,7 +4984,6 @@ Therefore it is RECOMMENDED that OAD authors use `$id` values to reference such
49624984

49634985
Note also that it is impossible for the reference at `#/components/schemas/Foo/properties/bar/$ref` to reference the schema at `#/components/schemas/Bar` using a JSON Pointer, as the JSON Pointer would be resolved relative to `https://example.com/schemas/foo`, not to the OpenAPI Document's base URI from `$self`.
49644986

4965-
49664987
### Base URI From Encapsulating Entity
49674988

49684989
If no base URI can be determined within the content, the next ___location to search is any encapsulating entity (RFC3986 Section 5.1.2).
@@ -4971,6 +4992,8 @@ This is common for Schema Objects encapsulated within an OpenAPI Document.
49714992
An example of an OpenAPI Document itself being encapsulated in another entity would be a `multipart/related` archive ([[?RFC2557]]), such as the following `multipart/related; boundary="boundary-example"; type="application/openapi+yaml"` document.
49724993
Note that this is purely an example, and support for such multipart documents or any other format that could encapsulate an OpenAPI Document is not a requirement of this specification.
49734994

4995+
RFC2557 was written to allow sending hyperlinked sets of documents as email attachments, in which case there would not be a retrieval URI for the multipart attachment (although the format could also be used in HTTP as well).
4996+
49744997
```MULTIPART
49754998
--boundary-example
49764999
Content-Type: application/openapi+yaml
@@ -5018,7 +5041,7 @@ Content-Location: https://example.com/api/docs.html
50185041

50195042
In this example, the URI for each part, which also serves as its base URI, comes from the part's `Content-Location` header as specified by RFC2557.
50205043
Since the Schema Object at `#/components/schemas/Foo` does not contain an `$id`, the reference in its subschema uses the OpenAPI Document's base URI, which is taken from the `Content-Location` header of its part within the `multipart/related` format.
5021-
The resulting reference to `https://example.com/schemas/bar` matches the `Content-Location` header of the second part, which allows the reference target to be located within the multipart archive.
5044+
The resulting reference to `https://example.com/schemas/bar` matches the `Content-Location` header of the second part, which according to RFC2557 allows the reference target to be located within the multipart archive.
50225045

50235046
Similarly, the `url` field of the [External Documentation Object](#external-documentation-object) is resolved against the base URI from `Content-Location`, producing `https://example.com/api/docs.html` which matches the `Content-Location` of the third part.
50245047

0 commit comments

Comments
 (0)