open API 3.0 spec support #128
Comments
|
@whitlockjc I was wondering if there's any plans to start supporting the OpenAPI 3.0 spec. Thanks! |
|
We definitely plan on supporting it but I'm not 100% sure how to do it yet. In Note: OpenAPI 3.0 is NOT GA yet but now that the Implementer's Draft is out, we should start working on this soon. |
|
Any update on this now that it's GA? |
|
We're wrapping up the next sway release, bug/security fixes and enhancements. After that, 3.0 support will be our top priority. Sorry for the delay. |
|
@whitlockjc is there anything you need help with to get 3.0 support out? Happy to contribute. |
|
@whitlockjc - same question here. If it'd help if I join the effort - please contact me. |
|
@whitlockjc - Any plans to move to 3.0 Open API spec? 3.0 is GA now. Folks have been asking for this since last year. I know you are super busy. We really love this library. It would be great if you can provide an approximate timeline on when will this be possible? |
|
Guys, I suppose it's down to us to fork and get on with it. Or maybe start from scratch in pure ES7 porting the good stuff. |
|
I don’t see why threatening to fork is required when a PR, or PRs, would suffice. I’ve been the only active developer in this project from day one and like you, I’ve run into time conflicts lately. I’ve been trying to pick it back up (look at yesterday’s commits) but it’s not going to ever be as quick if I’m the only one doing it. 3.0 support will likely take some time and will likely require changing the architecture a bit but I’m more than happy to be involved. I will just need some help. If you think a fork is the best approach, by all means. |
|
I don't think it was a threat of any kind. All of us love this repo and the work done by you over here. Since you are the main and only author of this repo, people are expecting a response from you on 3.0 support. @osher posted a comment on Jan 30 and I posted one 7 days ago asking for a timeline if any. This gives us the idea about where the project is heading with 3.0. It took slightly strong words from @osher for you to respond. Anyways, I can completely understand the time constraints and you working on this project in extra time. More hands on this project would definitely help. I shall discuss this with my team to see what is the priority for 3.0 support and based on that would love to contribute in keeping this project open api 3.0 compliant. Thank you once again for your response. Have a good day 👍 . |
|
Well, let's make this happen. I'm putting in the time now and I'd love some help. My plan is to release |
|
wow. I missed these mails.
Anyway - no, I did not mean fork as in lets split into a new copy, but as
fork - the first step in working on a PR.
Sorry for the confusion!
…On Tue, Jun 5, 2018 at 7:29 PM, Jeremy Whitlock ***@***.***> wrote:
Well, let's make this happen. I'm putting in the time now and I'd love
some help. My plan is to release 2.0.0 by EOW *(barring any unexpected
conflict)* and then focusing on OAI v3.x support.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#128 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxBHejzigL9ripF9thig36uSBeGVGLQks5t5rHUgaJpZM4LzEVu>
.
|
|
Any news on OAI v3.x support? |
|
Now that |
|
Thank you very much for your immense efforts. I believe, |
|
I honestly have no idea how long it will take. Last I heard, |
|
Excuse my naivety... |
|
They OpenAPI folks are still working on that, but this v3.0 metachema is usable despite being labeled as WIP. OAI/OpenAPI-Specification#1270 It’s being used in a lot of tools like oas-kit: https://github.com/Mermade/oas-kit/tree/master/packages/oas-validator/schemas |
|
Fair enough. I'm on the TSC and I know that it's a WIP but building on top of a WIP worries me a little, although I'm not against it. |
|
Cool! Wasn’t pulling rank there just letting folks know in case they didn’t. 😬
I’ve been using oas-kit extensively at wework to validate all sorts of problems, and if there are edge cases the WIP doesn’t cover then I’ve not found them.
Put it this way: if you build a new version of sway presuming the WIP is close enough, and write everything to support v3, you can have that version as beta until the WIP is final. That’s going to avoid waiting for it to be done before building your new version, and make everything quicker for everyone without really adding an extra work to your plate.
…--
Phil Sturgeon
@philsturgeon
On Jul 25, 2018, at 12:46, Jeremy Whitlock ***@***.***> wrote:
Fair enough. I'm on the TSC and I know that it's a WIP but building on top of a WIP worries me a little, although I'm not against it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Oh, I didn't take it that way. :) I wasn't pulling rank either but I can see how it could be taken that way. |
|
Speaking of...any ideas on how you'd like |
|
Many tools implement an adaptor pattern approach, where a base class covers the most basic common functionality and inheritence covers the rest. You'd probably have distinct v2 and v3 base classes, and v3.1 could extend from v3.0, etc. Or you can use mixins to cherry-pick functionality from a whole bunch of things. This JSON Schema library does something similar: https://github.com/davishmcclurg/json_schemer/tree/master/lib/json_schemer/schema Also, with oas-kit covering a lot of the same functionality as you, but already supporting v3.0 rather well, I'd see if there was any functionality could combine. Even using their resolver and/or walker would help you delete some code. There are quite a few Node modules floating around now, and it would be great to see things combinging so we can all work on building awesome tooling on top of that base layer of components, instead of all competing to build this same components and being stuck on step 1. :) |
|
I'm all for collaboration. Being one of the first on the block for such things ( |
|
Excellent. Well, oas-kit is brand new but based on the logic from swagger2openapi, and of course exists because there are no v3.0-based tools out there. I wasn't suggesting ditching your thing because a new thing came along, but was suggesting you take a look at the multiple components they have to see if any of them can replace 2.0-only code you have there. Another cool approach is to support v3.0 only, and use their swagger2openapi logic to convert in the background. That can really save some effort. :) Either way, good luck with the v3.0-based tooling built on that WIP metaschema. I'm nudging the OpenAPI folks to get that finished up! |
|
I do like that idea. I'll reach out to @MikeRalphson to see what his thoughts are. |
|
I suggest not claiming that master supports v3 as a work in progress. |
|
I fixed the supported version in the README files. And thanks for the feedback. I like that approach too. |
|
Hey @whitlockjc, what is the current progress with this? Do you need any help? |
|
Progress is ongoing but not complete. Doing it alone means slower than ideal delivery. I'll try to get it out sooner. |
|
@whitlockjc - just to give you some kudos. |
|
No worries. I've been dragging my feet due to no official JSON Schema for [email protected] but I'm going to take a different approach starting today. |
|
@whitlockjc hey, is that new approach using the WIP? I don't want to sound like a dog with a bone but you could get a long way using that WIP and it shouldn't mess you up if they release an official metaschema during that time. If you've got a big healthy test suite then it'll aaaaall be fine. Probably. Right? :D |
|
The |
|
I think @philsturgeon meant the WIP json schema(s). |
|
Ah yes. If I continue with the JSON Schema based approach, that's what I'll do. I'll make a decision here shortly. |
|
How's this coming along? Is there any of the tooling we can align on?
I know this tool has been around a long time but with these other tools marching forwards recently I feel like there is an opportunity to offload some maintenance burden to existing tools. |
|
Object model is complete, structural validation is complete. Semantic validation is almost complete. I will then do request/response validation and cut a release. The plan is to remove support for mock/sample generation for now. We can bring it back pretty easily, but the current approach brings in so much bulk that I don't want to stick with it if we don't have to. Thanks for your patience. |
|
I'm glad you pointed me to stoplightio/json-ref-resolver, I didn't know they too were writing their own version of json-refs. I've reached out to better understand, I fear fragmentation for no real reason. |
|
Is there any updates for now? |
|
Sorry for the delay, but it's nearing completion. Structural document validation for 2.x and 3.x is working, semantic validation is almost done. All that's left then are a few APIs and request/response validation. |
|
I am specifically cared if OpenAPI v3.0 will bring feature with |
|
|
|
Any updates on this or is this project dead? |
|
The project isn't dead, I just happen to be a one-man band so things happen much slower now that working on this isn't part of my day job. |
|
Maybe now is a good time to split it into a few smaller tools and see if we can find help from the community, getting folks to take ownership of those smaller tools. I'm starting to get together some resources on https://github.com/openapi-contrib, and having a simple validator over there would be massively useful. It would help a lot of people avoid needing to OAS+AJV for validation, which is a major pain point. |
|
Can't share how much we are in need of this to finish. And I am willing to contribute to my available capacity. It would be nice if you put your time and efforts on planning the tasks for this release, and then community can take up the tasks and help you finish. |
|
@whitlockjc - I agree with the above comments - If you can put together a roadmap, then the community can help. E.g. I could fix #218 (not sure why you closed an actual roadmap issue, tbh). |
|
@wickedest It didn't seem like a roadmap issue because it's not a bug in the 2.x support or a new feature of 3.x, it's just a lack of 3.x that makes your unexpected behavior happen. So to me, completing 3.x support is what is important to track. I could be wrong. As for everyone else, I'm down with this. I have 3.x support working locally where structural validation works and almost all semantic validation is done that was in 2.x. The delta is new semantic validation required for 3.x, and handling the new approach to requests/responses in 3.x that is not backward compatible with 2.x. I can start committing my work to |
|
It would help, yes please!
…
|
|
@whitlockjc do you have any update when you will push your changes to master and we'll be able to start contributing to get the ball rolling on 3.x? |
OpenAPI will release version 3.0 at Feb 28, 2017. https://www.openapis.org/blog/2017/01/24/a-new-year-a-new-specification. It would be useful if this tool can support 3.0 as well.
The text was updated successfully, but these errors were encountered: