Closed augensalat closed 5 years ago
I’m guessing you have a “api.json” file in your public folder.
The latter is a bug I think. I haven’t really bothered to optimize it. The reason why it’s all a huge bundle in one file, is because it’s the only way the plugin can ensure that the spec is valid for a client. The case where it wouldn’t be valid is if you have a $ref to a file that is not available online, like a file on disk.
I’m guessing you have a “api.json” file in your public folder.
Almost, but good guess. As I wrote I'm using the example from the module's POD which is a single-file lite-app, that uses an embeded spec file which is indeed called "api.json". Changing that to some other name fixes the problem. I would suggest to change the example so at least the documentation doesn't cause such kind of confusion in future.
The latter is a bug I think. I haven’t really bothered to optimize it. The reason why it’s all a huge bundle in one file, is because it’s the only way the plugin can ensure that the spec is valid for a client. The case where it wouldn’t be valid is if you have a $ref to a file that is not available online, like a file on disk.
Being in one big file is not the problem, just the duplicate default response.
Also the x-bundled
section is kind of a foreign body that means nothing to consumers. Couldn't it be removed and refs made pointing to /definitions/DefaultResponse
?
Sure. Patches are welcome.
Using the echo example from the main page I get different JSON schemas depending on the path of the request:
My questions:
DefaultResponse
defined twice in the extended Response (in/x-bundled/__definitions_DefaultResponse
and in/definitions/DefaultResponse
)?