-
-
Notifications
You must be signed in to change notification settings - Fork 170
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
support for OpenAPI v3 extensions #16
Comments
Hi @newgene thanks for reaching out - have you seen the SEMOASA proposal for a machine-readable format for OpenAPI specification extensions? As an example, if you create a SEMOASA document (format is still in flux) you would be able to render documentation such as this. Enabling intelligent support for OpenAPI extensions in definition editors is one of the stated use-cases. What I am thinking of currently is that the OpenAPI definition might include an extension pointing at an array of SEMOASA documents which define the extensions which are expected to be encountered. But there is no reason why you could not preload these and instantiate effectively a SmartAPI-gui. At the moment the templates and field logic in OpenAPI-gui are fixed, but I think creating dynamic elements based on a schema-to-html translation should be possible. Pinging @tedepstein, @RomanGotsiy, @brendo, @brylie, @EricWittmann for their thoughts. |
Although apicurio isn't mature enough yet to worry too much about how to render OAI extensions, in principle I think SEMOASA sounds like a great idea. Anything that can give editors (and documentation generators) more information about what a property might mean would be super helpful. |
@newgene and @MikeRalphson , Yes, this is exactly the kind of use case I had in mind for SEMOASA. We'd like to provide a rich editing experience for OpenAPI extensions in our own API editors. And we'd like to promote SEMOASA as an open standard so that extensions can be supported in any compliant editing tool. Tool providers have a lot of flexibility as to how they want to expose this functionality. For example:
|
Great! Thank you all for pointing us to SEMOASA. It's exactly the piece I thought missing in the OpenAPI ecosystem. Glad you guys have stepped up and created one already. We will definitely look into it. And we are particularly interested to see a web-based API metadata editor, like openapi-gui, with the SEMOASA support. |
Form-generation from a schema-like definition in vue.js: https://jsfiddle.net/Herteby/ybqp8j0b/ Dynamic binding issue: |
@newgene Just to let you know some progress is being made on this issue. Any help you can give towards a Semoasa document for your OAS extensions would be gratefully received. |
@MikeRalphson thanks, we will give it a try. |
@newgene sorry - that's just a teaser- the dynamically generated forms are working well, but I still need to do some work on the persistence layer behind it before it is released. |
@MikeRalphson got it. We will continue watching this thread then :-) |
Hi, Is there any progress on this one? #16 (comment) looked very promising |
Hi @moon0326 - unfortunately not as yet, There's not really much to do (the persistence mechanism, and the importing of extension metadata) but the Semoasa spec (and usage of it) seems to have stalled somewhat and that kind of took the wind out of the sails of this feature. I will update here if I get time to get back to it. If you know vue.js and something about dynamic binding then help would be very much appreciated! |
@MikeRalphson Thank you for such a fast response. It's my fist time seeing this package. I will take a look! |
Thanks @moon0326 the existing code is on the |
As you may know, we currently host a copy of openapi-gui on our SmartAPI project: http://smart-api.info/openapi-gui/. Thanks for making it available.
SmartAPI defines a set of OpenAPI extensions to support biomedical-field APIs, so we are wondering how much work is needed in order to add the extra "x-" extension fields into the openapi-gui web forms.
Ideally, it would be nice to allow us to define extra schemas in a separate file like "extensions.js" (under openapi-gui/data folder), then it can be merged into "jsonSchemaDraft4" defined in "static.js". Depending on how the rendering code works, those extra extension fields can then be rendered in the web forms.
The text was updated successfully, but these errors were encountered: