-
Notifications
You must be signed in to change notification settings - Fork 90
External $ref in paths doesn't follow a relative URI #53
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
Comments
I just verified the spec didn't have this part of description. (See Paths Object) The only field could exist under "paths" is a map from relative urls to Path Item Object. And the $ref can be placed under Path-Item Object, but not Paths Object. And it seems that relative issues raised againt the SPEC team, but nothing is confirmed to change yet.
Therefore, even swagger-ui supports this, I might choose not to support this behavior. The spec-compliant way to do this is to place the '$ref' under Path-Item Object. Thanks for reporting issues, very appreciated. note: a bug has been found that relative reference in this case doesn't work well. I'll fix this part later. |
Oops, I made my example wrong. I did indeed have it under the Path-Item Object. Thank you for the fix! |
I'm having problems with $ref in other places, but I might be doing it all wrong. I'm currently trying to work out a good test case for what I'm doing. Once I have something easily reproducible I'll post back here. |
No problem, raise any question if needed. :) |
This should be a good example:
And the error I get:
|
You are correct, the fix I proposed only applied to PathItem Object, and according to spec, all Reference Object should support relative files reference. I'll fix it and sorry for bothering you again. :( |
No problem! It's a pleasure working with you! |
note: In older version of 2.0 spec, this schema is valid: {
"definitions":{
"User": {},
"AuthorizedUser":{
"$ref": "User"
}
}
} The AuthorizedUser would automatically reference to "#definitions/User". It's not clear for Swagger 2.0 to support this behaviour or not. If I fix relative file reference rooted with Schema Object, this behaviour is no longer supported. |
The second example here doesn't seem to work: https://github.com/OAI/OpenAPI-Specification/blob/master/guidelines/REUSE.md#guidelines-for-referencing It looks like it's expecting whatever file it loads there to be of the Schema type, though the schema could be nested anywhere in the yaml/json that gets loaded. Also, to get that far I had to do the following:
I'm testing it now by just having each definition in its own file and it seems to be working. |
At the time when Swagger 2.0 just came out, the only 'external referencible' object is Path Item. And I didn't follow the later discussion. I'm a python guy so I prefer explicit to implicit. I would definitely complained about this kind of design if I joined those discussion. It's still possible to make this work, let me investigate it for a while. Big thanks for your efforts on trying these scenario! It's actually much more complicated than I expect, refer to this discussion
My head gets hurt now....... Asking question here, await replies. Discussion kept going... It seems clear now, will proceed to redesign the resolving procedure. The implementation of pyswagger about "external $ref" is not correct according to REUSE Guide. In short, pyswagger requires the root object externally referenced be either PathItem, Schema, Parameter, Response, or Swagger object, but the spec suggests that the root object can be any valid structure, as long as the object pointed by $ref is either PathItem, Schema, Parameter, Response, or Swagger. |
Those fixes should be included in 0.8.17, reopen this issue if you find anything broken. :) |
- relative reference of Path Item Object - pyopenapi/pyswagger#53
- deprecate implicit dereference - support relative file reference - pyopenapi/pyswagger#53
Example (another_file.yaml is hosted alongside the parent yaml file, and works with swagger-ui):
The text was updated successfully, but these errors were encountered: