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 Open API spec 3.0 #1122

Open
ifraixedes opened this Issue Aug 4, 2017 · 15 comments

Comments

Projects
None yet
@ifraixedes
Contributor

ifraixedes commented Aug 4, 2017

Only to bear in mind, is there any plan to release and update to support Open API spec 3.0 https://swagger.io/announcing-openapi-3-0/

Thanks!

@seifer

This comment has been minimized.

seifer commented Aug 15, 2017

Very interesting!!

@casualjim

This comment has been minimized.

Member

casualjim commented Aug 17, 2017

for definitions 2.0 and 3.0 aren't very different because I wanted a full json schema implementation to work instead of the subset that swagger (openapi) 2.0 prescribed
in 3.0 they expanded it to properties that are already supported in our validator
most of the changes in 3.0 pertain to how operations are described with their parameters and responses
that has a big impact on the code generator but if I'm guessing nothing in there is a combinatorial nightmare unlike json schema is
I'll start to work on a new spec implementation in go-openapi/spec3 because I do want to correct some thngs like not using golang's map as a map but rather use sorted maps

@casualjim

This comment has been minimized.

Member

casualjim commented Aug 21, 2017

spec will be here: https://github.com/go-openapi/spec3

@tamalsaha

This comment has been minimized.

tamalsaha commented Nov 26, 2017

@casualjim, is there any update on openapi 3 support?

@JunliWang

This comment has been minimized.

JunliWang commented Dec 22, 2017

@casualjim, check-in again, is there a timeline for openapi 3 support? Or early adoption on another branch?

@fredbi

This comment has been minimized.

Contributor

fredbi commented Dec 22, 2017

@JunliWang hello.
We were just discussing that yesterday. It's really a ton of work to lift it to v3.
I am not sure there a many volunteers out there to produce such an effort.

Personnally, I would concentrate my efforts on getting the product stable with full V2 support and more than good enough. It is already good enough for most use cases, and probably at or close to top of this class of products.

@SandyWalsh

This comment has been minimized.

SandyWalsh commented Jan 8, 2018

@fredbi the problem is, as long as the spec reads swagger: '2.0' we will have issues using the spec for other tools, doc generators, etc.

@casualjim

This comment has been minimized.

Member

casualjim commented Jan 8, 2018

there are a lot more issues with 3.0. it has expressions, a vastly different syntax and so on.
Somebody else is more than welcome to step up but I don't have time to implement and mantain such a large specification as main contributor.

@fredbi

This comment has been minimized.

Contributor

fredbi commented Jan 8, 2018

@casualjim Me neither. A "Swagger 2.1" fixing some inconsistencies in 2.0 would be fair enough for me.
@SandyWalsh : we are basically saying the same thing .It would be rather easy to be more tolerant with the version announced by the spec, while continuing to check it against 2.0.

@SandyWalsh

This comment has been minimized.

SandyWalsh commented Jan 8, 2018

Thanks @casualjim @fredbi ... totally understand. Perhaps if I can get some cycles I'll try to contribute. I think I have some tricks I can do to keep on 2.0. Keep up the great work!

@theherk

This comment has been minimized.

theherk commented Apr 26, 2018

I'm curious the status of this. validate still fails, but serve seems to work just fine.

For anybody else curious, I still maintain the v3 definition, I just use api-spec-converter to autogen the swagger v2 definition.

@msolimans

This comment has been minimized.

msolimans commented May 18, 2018

Same here, it fails when I tried to validate, serve works but not perfectly when using oneOf in the response it gave me no response examples.

Any updates!

@casualjim

This comment has been minimized.

Member

casualjim commented May 18, 2018

I don't have time to work on an openapi 3.0 specification.

@fenollp

This comment has been minimized.

fenollp commented May 18, 2018

For validation, Google’s gnostic generates/maintains a schema and some tooling. Hopefully this helps :)

@kappj

This comment has been minimized.

kappj commented Nov 6, 2018

I wanna bump this as all the other tooling I use with my OAS supports V3 now, and this project is the only thing that's keeping me from migrating to OAS 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment