Skip to content
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

Write ADR for identity vs location #92

Open
handrews opened this issue Mar 19, 2024 · 2 comments
Open

Write ADR for identity vs location #92

handrews opened this issue Mar 19, 2024 · 2 comments
Assignees

Comments

@handrews
Copy link
Member

As part of the larger discussion on referencing and imports (#72, #73), @darrelmiller suggested deciding on using IRIs as identifiers rather than locators as a first step. Part of the context is his discussions with his team around the impact of using $ref URLs as strict locators that must be read separately each time, plus the complexity of how to write changes back to such a separately-loaded reference that may be loaded in many different (possibly somehow conflicting) places within the OAD.

@handrews handrews self-assigned this Mar 19, 2024
@handrews
Copy link
Member Author

This is related to the OASComply reports and I might start by adding a supplementary report there as it has impacts on Moonwalk, OAS 3.x, and OASComply. Then I'll link from an ADR that addresses the Moonwalk-specific concerns.

@handrews
Copy link
Member Author

handrews commented Jun 4, 2024

After much research, I determined that OAS 3.1 already separated identity and location, but did so in an unclear manner. Specifically, the OAS 3.1 Schema Object requires that separation, which de-facto requires it for all URI-based connections within a multi-document OpenAPI Description. This is reflected in calling those URIs "URIs" and discussing them separately from API "URLs", including when it comes to base URIs.

The following PRs clarify this area in 3.1, with the last one in the list proposing a self field for 3.2 to complete the separation and enable bundling, a.k.a. a consumer-optimized format:

Assuming the 3.2.0 PR for self goes through, there will be no need for this ADR as we will just be continuing what 3.x does, and we can move on to the mechanism of how it works in Moonwalk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant