OpenAPI version 3.0
sdcoffey opened this issue · 34 comments
Are there any plans to support the 3rd version of the OpenAPI spec?
Yes, there are plans. OpenAPI spec 3.0 is simply not ready.
Cool, I can live with that. Thanks for the quick response!
By the end of the month open api 3.0 will be finalized as a specification, then we can start implementing it. So it will be a little bit before we really have support for this. realistically it takes about 6-8 months for most tooling to start supporting open api 3.0. At least it took almost 12 months for tooling to catch up to the 2.0 version of the spec last time.
going to leave this open because I expect this question to start coming up more often.
Things I would like to see different from the current object model:
- No more go maps but sorted maps instead, so we have identical json generation
- custom serializers based on mailru/easyjson that preserve line number and perhaps character position.
It has been 10 months now ;-)
Any news or an E.T.A.?
@wboevink @easonlin404
I have create one for openapi-spec@v3 https://github.com/morlay/oas
Could you like to test it?
@casualjim I don't understand the third dependencies, so I restart to create this, instead of forking from https://github.com/go-openapi/spec3
easyjson you mean?
the main thing is the use of golang maps is anoying because of their random order, there are people who use other tools who want a stable ordering. So I implemented an ordered map.
the easy json is so that it's easier and faster to serialize and deserialize specs, doing that with golang json is memory hungry. kubernetes etc have a 40k+ lines spec.
@casualjim Thanks.
Got it. I will try to merge my works to spec3.
easyjson generate lots of codes, need time to learn how it works.
Anything new on this front? Would love to see Open API 3.0 support
@PhyberApex
There is an version https://github.com/morlay/oas which supported v3.
Any chance on getting it in here? Because I actually want it to be enabled here: https://github.com/DapperDox/dapperdox which uses this repo
~Cheers
Would be great to see OpenAPI 3 support soon! :-)
Is this still on the radar?
We would like to use OpenAPI 3 with https://github.com/DapperDox/dapperdox which has a dependency on this package.
if somebody continues to implement, I'm happy to shepherd this under this org. But personally I don't have time to spend on openapi 3.0 implementation which is significantly more complex than openapi 2.0.
Maybe https://github.com/getkin/kin-openapi can help some / get merged with https://github.com/go-openapi/spec3 ?
I'm all for it, seems like it started from our go-openapi/spec to begin with
Cool! Could someone give me commit rights on the spec3 repo?
@casualjim cool
I'm glad to move it.
Now it is in https://github.com/go-courier/oas (with vgo)
Btw I'm failed to make it work with easyjson, so just keep it with encoding/json.
@morlay I've sent you an invite
One quick win could be to switch out encoding/json with jsoniter, it's api compatible but there are minor differences in behavior
@PhyberApex dapperdox looks great! I wonder if it would be possible to embed it instead of the redoc integration we have now.
Or at the very least make it an option in swagger serve
@casualjim got it.
We could wait for @fenollp and discus how to do the migration.
yep, we also have a slack team: https://goswagger.slack.com
@PhyberApex dapperdox looks great! I wonder if it would be possible to embed it instead of >the redoc integration we have now.
Or at the very least make it an option in swagger serve
I currently have a dev branch with much more UI options for swagger serve to customize UI.
Would be glad to integrate this, or at least try to do so.
Only it should be an opt-in. This topic is unrelated to OAS3
@morlay I'm all for any json lib. I like how it's done in kin-openapi (the jsoninfo package) as it let me add YAML support very easily. I have not looked at text parsing time though.
Hey folks! It's amazing to see everyone working together to make this happen. If the chat moved to slack, what was the outcome? It'd be great to get everyones efforts focused on the same project, and mark the others as deprecated so there's no further split efforts.
Bump :D
Hi, we could really use this in order to get DapperDox to support our OpenAPI 3 docs. What's the status of this, and is there anything I can contribute to move it along? No one seems to know what the outcome of the Slack chat was.
BTW there's a very similar discussion over at go-swagger/go-swagger#1122 (comment), not sure how the two organisations are related but they share contributors.
So, what needs to be done first & how do we split work? I don't have much time but I do want to move this forward. I don't know the codebase much yet.
@casualjim @morlay As I understand it work should start/concentrate around go-openapi/spec3? I'm guessing the parser would be a first step?
@morlay Are you still down to work on this?
@fenollp very simplified story: go-openapi was created from go-swagger to make components of it reusable outside the go-swagger project.
@fenollp
Here just my version https://github.com/go-courier/oas.
I don't really know how to start the migration from my version to go-openapi/spec.
We wrote package for different purpose. And it not easy to extract as a common one without fully communication.
And recently, I am lots of busy with my work.
If you have any idea to start the migration, I'm glad about be base on my codes.
Any update on OAS3 support? :-)
@fenollp @morlay @casualjim
I'd like to help with the integration of OAS v3.0 as I'm planning on using it with DapperDox/dapperdox#63, any pointers on how I should go about integrating it? Looks like https://github.com/getkin/kin-openapi already has support for OAS 3.0
Hey all.. seems the last update on this thread about what was going on, which direction OAS 3 was headed.. was a year ago. Can anyone put a close on this and let us know.. is OAS3 being supported in this project, go-swagger, or the kin-openapi project, which seems to have active development from just a few days ago and from what my go noob eyes can tell is more complete than other implementations? Which project should every go developer and project that intends to support OAS3 depend upon? More importantly.. is there a reason it hasn't been moved in to openapi codegen so that the one location most people turn to has the most active up to date implementation and documentation?
The close is: don't look here. I think openapi generator has come a long way since I started this project.
The spec3 repo has an up to date list of missing items in the readme.