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

OpenAPI 3.0 support? #207

Closed
willdady opened this issue Feb 16, 2017 · 11 comments
Closed

OpenAPI 3.0 support? #207

willdady opened this issue Feb 16, 2017 · 11 comments

Comments

@willdady
Copy link

Are there any plans to add support for OpenAPI 3.0? It looks like the spec is settling with the first implementer draft dropping at the end of February.

https://www.openapis.org/blog/2017/01/24/a-new-year-a-new-specification

@RomanHotsiy
Copy link
Member

@willdady,
yes, there are plans to support it.
But I am not sure about timeframe. There are a lot of changes in the version + a few things I am not sure how to implement at the moment (oneOf, anyOf, not, etc)

@eitan101
Copy link

eitan101 commented Feb 24, 2017

+1 for the "oneOf".
I currently use json-editor to present read-only form and it supports "oneOf", but for documentation purposes ReDoc is much nicer.

@LakshmananVignesh
Copy link

@RomanGotsiy Hi its very nice to use ReDoc any update on OpenApi 3.0 support

@RomanHotsiy
Copy link
Member

RomanHotsiy commented May 18, 2017

@LakshmananVignesh it's definitely on the roadmap but I'm quite busy at the moment with other huge feature for ReDoc so can't give you any ETA.
Once I finish with that, will let you know.

@avkonst
Copy link

avkonst commented May 22, 2017

Duplicating comment, but will post it here too:

Discriminator from v2 of the spec does not make things simple and will be conflicting with the anyOf, oneOf, allOff features, once implemented. And it would be easier to get rid of the discriminator. I have removed it from my APIs and use standard JSON-schema xxxOf features. Redoc may render a nested section per each xxxOf declaration with a headline indicating type of xxx constraint and with "carousel-like" (horizontal) scroller to slide through subtype definitions from inside of the xxxOf. This would be simpler, because it would not require any schema introspection to determine discriminator-like field, would not require "select" based field and reactive response to it. The ReDoc view of sections would map one to one definitions in the JSON-schema, what would be easier to understand for API consumers. I would love to have such a behavior of ReDoc. What do you think?

@RomanHotsiy
Copy link
Member

@avkonst thanks for the idea 🙌
It sounds very reasonable.

I am about to start huge refactoring toghether with implementing OpenAPI 3.0 support so I will consider you idea!

@avkonst
Copy link

avkonst commented May 25, 2017

Great! Thank you for the great work! I think simplicity matters. My users know about JSON-schema - it is the first thing they are dealing with when define their data model for the API. So having the documentation mapped one to one with JSON-schema is very clear and very understood. OpenAPI spec was needed as an intermediate step to the rendered browsable documentation. I have chosen ReDoc as a documentation tool 6 months ago because I believed it has got the potential to go in the right direction. I can help you with testing and trying your refactored version and run it with my users to gather feedback, if it helps. Let me know.

@jmauerhan
Copy link

I would also really like support for Open Api 3. If there's anything I can do to help out, IE tickets that could be worked - I would be more than happy to do so.

@andrehagemeier
Copy link

any news on 3.0 support?

@RomanHotsiy
Copy link
Member

RomanHotsiy commented Sep 8, 2017

@jmauerhan OAS 3.0 support will come together with #327. Maybe some feature will be missing at the beginning

@andrehagemeier thanks! There will definitely be some work after #327. If you are still willing to help out I will create tickets as soon as I finish React rewrite.

@RomanHotsiy
Copy link
Member

Just noticed there are two issues about OpenAPI 3 support.
Closing this in favor of #312

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

7 participants