Skip to content

Add $self for self-identifying documents #4389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: v3.2-dev
Choose a base branch
from

Conversation

handrews
Copy link
Member

@handrews handrews commented Feb 28, 2025

See the proposal for background information.

This is a rather minimal approach, as @karenetheridge and I plan to work together on a more thorough revamp of the document parsing / reference resolution sections.

This adds $self as a way for a document to define its own URI for use in reference targets, and as the base URI for relative URI references in the document.

This does not impact the resolution of relative API URLs. [NOTE: I'm not entirely sure about this, but it seems more useful this way to allow multiple deployed locations of an OAD to correspond to multiple deployments of the API.)

Tick one of the following options:

  • schema changes are included in this pull request
  • schema changes are needed for this pull request but not done yet
  • no schema changes are needed for this pull request

@handrews handrews added enhancement re-use: ref/id resolution how $ref, operationId, or anything else is resolved labels Feb 28, 2025
@handrews handrews added this to the v3.2.0 milestone Feb 28, 2025
@handrews handrews requested review from a team as code owners February 28, 2025 15:07
Copy link
Contributor

@lornajane lornajane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty solid, but could we introduce use of $self in one or two examples so people realise it's there?

@ralfhandl
Copy link
Contributor

Looks good. An example would be nice.

@handrews
Copy link
Member Author

handrews commented Mar 6, 2025

@lornajane @ralfhandl I thought I did include one but apparently I did that on an earlier attempt on a different branch. I'll port it over in the morning.

Copy link
Member

@karenetheridge karenetheridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments/questions throughout.

@handrews
Copy link
Member Author

@lornajane @ralfhandl @karenetheridge I ended up reworking this a bit as I added examples.

Copy link
Contributor

@ralfhandl ralfhandl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, after correcting the resolved URLs in the example.

ralfhandl
ralfhandl previously approved these changes Mar 21, 2025
ralfhandl
ralfhandl previously approved these changes Mar 21, 2025
@handrews

This comment was marked as off-topic.

@handrews

This comment was marked as off-topic.

@ralfhandl

This comment was marked as off-topic.

@handrews

This comment was marked as off-topic.

@handrews

This comment was marked as off-topic.

@handrews

This comment was marked as off-topic.

@karenetheridge

This comment was marked as off-topic.

Copy link
Member

@karenetheridge karenetheridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's all my comments for this pass.

They will read a bit confusingly though because the order in which they appear in the document is nearly the reverse of that in which I wrote them -- as I had to get down to your examples before I really understood what you're going for, and then I had to go back and drop in some questions higher up where the concepts are first mentioned! (sorry!)

Actually never mind, it looks like github has changed how it does things since I last had a similar complaint -- and the comments are added here in chronological order, not in the order in which they appear in the file! yay github.

@handrews
Copy link
Member Author

@notEthan and others, after talking with @karenetheridge and the rest of the TDC call today, I am going to split out all of the things about further clarification of Server Object behavior into another discussion or issue, and mark things resolved or (if that is not available) off-topic. This does NOT mean that the comment was off-topic in a bad way, just that there was a request on the TDC call to make this PR easier to read and focus on the remaining issues needed to get this across the finish line.

handrews and others added 11 commits April 10, 2025 10:32
This adds `$self` as a way for a document to define its own URI
for use in reference targets, and as the base URI for relative URI
references in the document.

This does not impact the resolution of relative API URLs.
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
Co-authored by: Karen Etheridge <ether@cpan.org>
Co-authored-by: Karen Etheridge <github@froods.org>
This ties the `$self` behavior more directly to the sections
on API Description URI usage, including examples, and also
expands on the use cases for manually providing a retrieval URI.
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
Also tweak the wording a bit as a result, and ran format-markdown.
Co-authored-by: Ralf Handl <ralf.handl@sap.com>
ralfhandl
ralfhandl previously approved these changes Apr 11, 2025
@ralfhandl ralfhandl requested a review from a team April 11, 2025 09:11
karenetheridge added a commit to karenetheridge/JSON-Schema-Modern that referenced this pull request Apr 11, 2025
This will allow us to implement the separation of retrieval URL from "$self"
in JSON::Schema::Modern::Document::OpenAPI and OpenAPI::Modern (to be added to
the OpenAPI Specification in v3.2).

see OAI/OpenAPI-Specification#4389
karenetheridge added a commit to karenetheridge/OpenAPI-Modern that referenced this pull request Apr 11, 2025
mikekistler
mikekistler previously approved these changes Apr 20, 2025
Copy link
Contributor

@mikekistler mikekistler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. 👍

I left a few minor comments I hope can be addressed in this PR, but do no object to deferring these to a follow-on PR.

1. The base URI used to resolve `$self` is the retrieval URI, resulting in an effective `$self` value of `https://example.com/openapi` (OADs that use HTTP content negotiation to provide both JSON and YAML representations typically do not use a file extension in their self-assigned URI, to avoid needing to change URIs based on the format).
2. The base URI for the `$ref` comes from `$self` (`https://example.com/openapi`), producing a resolved URI of `https://example.com/shared#/components/pathItems/Foo`.

Relative `$self` values are often used for APIs deployed in multiple locations, such as a device management API that is hosted on each device.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to reveal my ignorance here, but this seems like the exact situation where you want to use absolute $self value. I thought the idea of distinguishing URIs -- identifiers -- from URLs -- locators -- is that you could have the same document in multiple locations and would want to make clear that it is the same document -- with a single identifier -- even though it could be retrieved from multiple locations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikekistler I just did $self by analogy with JSON Schema's $id. If folks want to deviate from that (and as you note there are reasons to do so for simplicity) then we can, but let's decide that intentionally. I think @karenetheridge brought up this in some way as well? I admit I've somewhat lost track at this point.

I do not have a use case where you would want the identity to change based on the location, although I'm sure I could construct one where it's somehow beneficial. But maybe not so beneficial as to be worth discarding the simplicity of requiring an absolute URI.

Notably, the newly proposed JSON Schema replacement JSON Structure requires an absolute $id (although they also say it SHOULD be a URL which I need to reply to because that is missing the point of $id entirely in my view and guiding people to the wrong behavior).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have filed issue #4548 to debate the absolute-URI idea, along with several other spin-off issues previously filed. Although perhaps it is worth taking a step back and looking at all of those "spin-off" issues comprehensively. Honestly I'm not sure where to go with this as people keep having fundamental objections that could substantially change the whole thing, and those aren't good questions to resolve in a PR. Those are discussion or issue questions, really.

src/oas.md Outdated
description: The test API on this device
```

For API URLs, the `$self` field, which identifies the OpenAPI Document, is ignored, and the retrieval URL is used instead. This produces a normalized production URL of `https://device1.example.com`, and a normalized test URL of `https://device1.example.com/test`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a nit but here we use "retrieval URL" but above (line 323) we use "retrieval URI". I'm guessing that these are referring to the same thing, and if so I think we should try to use consistent terminology.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah generally a retrieval URI is a URL by definition, but it gets weird when you are passing the retrieval URI explicitly, because in that context it might not be usable as a URL (e.g. you are passing it explicitly so that the tool treats it as if it came from a location that is currently inaccessible due to network conditions or whatever).

src/oas.md Outdated
@@ -342,6 +425,7 @@ This is the root object of the [OpenAPI Description](#openapi-description).
| Field Name | Type | Description |
| ---- | :----: | ---- |
| <a name="oas-version"></a>openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI Document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI Document. This is _not_ related to the API [`info.version`](#info-version) string. |
| <a name="oas-self"></a>$self | `string` | This string MUST be in the form of a URI-reference, MUST NOT be an empty string, and MUST NOT contain a fragment (empty or otherwise). The `$self` field provides the self-assigned URI of this document, which also serves as its base URI in accordance with [[RFC3986]] [Section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986#section-5.1.1). Implementations MUST support identifying the targets of [API description URIs](#relative-references-in-api-description-uris) using the resolved URI defined by this field, as shown under [Examples of Base URI Determination and Reference Resolution](#examples-of-base-uri-determination-and-reference-resolution). |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to explain -- or point to the explanation of -- the expected behavior when this field is not present.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikekistler if that's covered under "Examples of Base URI Detrermination.." is that sufficient?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement re-use: ref/id resolution how $ref, operationId, or anything else is resolved
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OAS3 Tag/template to define external-components URL
6 participants