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

reusable pathitems #2111

Closed
qianlong opened this issue Jan 22, 2020 · 3 comments
Closed

reusable pathitems #2111

qianlong opened this issue Jan 22, 2020 · 3 comments
Labels

Comments

@qianlong
Copy link

qianlong commented Jan 22, 2020

Path item object has a $ref field for referencing an existing path item, however there is no place for holding path items in components. I don't know the correct way to use $ref in a path, but it seems like I should referring to a path item defined for another path?
Please feel free to correct me if I'm wrong.

I saw this topic was discussed in TSC Meeting - January 16th 2020, were any decisions made?

@MikeRalphson
Copy link
Member

Because of the lack of a reusable component for pathItems in OAS 3.0 (and 2.0) the $ref property must (to be useful) point to an external resource / document.

See https://github.com/OAI/OpenAPI-Specification/pull/1964/files for an open PR attempting to clarify this distinction.

We ran out of time to discuss the paths object being made optional and reusable pathItems in components last week, but it is likely to come up again for this week.

@adamreisnz
Copy link

adamreisnz commented Jan 28, 2020

Keen to hear what the current recommendations and best practices are for storing paths externally and referencing them, in order to keep the spec in manageable chunks.

@lornajane
Copy link
Contributor

As of OpenAPI 3.1, [PathItems can be defined in the components section](https://spec.openapis.org/oas/latest.html#componentsObject and referred to there. I think this answers the original question.

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

No branches or pull requests

5 participants