OpenAPI version 3.0 about spec HOT 34 CLOSED

Any update on OAS3 support? :-)

from spec.

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.

from spec.

Bump :D

from spec.

It has been 10 months now ;-)
Any news or an E.T.A.?

from spec.

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

from spec.

@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

from spec.

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.

from spec.

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.

from spec.

I'm all for it, seems like it started from our go-openapi/spec to begin with

from spec.

yep, we also have a slack team: https://goswagger.slack.com

from spec.

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.

from spec.

Yes, there are plans. OpenAPI spec 3.0 is simply not ready.

from spec.

Cool, I can live with that. Thanks for the quick response!

from spec.

@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

from 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.

from spec.

Anything new on this front? Would love to see Open API 3.0 support

from spec.

@PhyberApex
There is an version https://github.com/morlay/oas which supported v3.

from spec.

Would be great to see OpenAPI 3 support soon! :-)

from spec.

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.

from spec.

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.

from spec.

Maybe https://github.com/getkin/kin-openapi can help some / get merged with https://github.com/go-openapi/spec3 ?

from spec.

Cool! Could someone give me commit rights on the spec3 repo?

from spec.

@fenollp I've sent you an invite
@morlay would you like to move your stuff into go-openapi too?

from spec.

@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.

from spec.

@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

from spec.

@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

from spec.

@casualjim got it.
We could wait for @fenollp and discus how to do the migration.

from spec.

@casualjim

@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

from spec.

@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.

from spec.

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.

from spec.

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?

from spec.

@fenollp very simplified story: go-openapi was created from go-swagger to make components of it reusable outside the go-swagger project.

from spec.

@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.

from spec.

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?

from spec.