Check out the deck from the 3/9 APICraft SF Meetup
OAS 3.0! Everything you wanted to know about what made it into the new version of the spec (and maybe what not). Ron Ratovsky (@webron) gives an overview of the different features and changes of the spec.
In this video, hear what’s new with the Open API Specification (OAS) — the vendor-neutral, portable, and open specification for providing technical metadata for REST APIs as well as latest trends in API design including topics such as Hypermedia and how the evolving OAI spec influences common patterns. Not just trends – this video is filled with real world examples.
About a month ago, we committed to pushing out the first Implementer’s Draft of OpenAPI Specification (OAS), and now it’s arrived! Following our official versioning scheme, this version is known as 3.0.0-rc0. This is a major step toward releasing a final version of the spec.
Until the final version is released, further development of the spec will continue in the OpenAPI.next branch. The 3.0.0-rc0 release has been tagged as a fixed reference.
Since our last blog post we’ve resolved the remaining remaining structural changes to the spec, and we have clarified a few issues and concerns and improved the documentation. Some notable changes since then are:
At this point, the specification is “feature-complete”, meaning, we will not actively discuss adding support for existing tickets. In the next few weeks, we will close tickets that have been handled or mark them for future versions.
The Implementer’s Draft marks an inflection point in the push to the third generation of the specification. As we observed with version 2.0, the spec means nothing without tooling and the tooling means nothing without the spec. This draft means that all major changes have been made, and that tooling authors are encouraged to build against it, knowing that only small changes can be expected from this point forward. And just like with version 2, this is a great opportunity to be early and bring attention to your project. It is also a meaningful way to get involved with the OpenAPI community and to help drive the spec to its released state..
This means the ball is in your court. Here is how you can help:
The top contributors will be given a token of appreciation from the Open API Initiative.
As before, we may end up asking for contributions or feedback on specific tickets — those would be marked as ‘help wanted‘. Keep an eye on those, and don’t be afraid to jump into the discussion.
Thank you to everyone who has contributed to this substantial step forward and onward to a final OpenAPI Specification version 3.0.0 release.
[tmm name=”technical-developer-community”]
It has been an exciting journey, and we’re happy to announce that the OpenAPI Specification version 3.0 is coming into view!
Image from the most recent Meeting of the Open API Initiative Technical Developer Community Meeting
Over the past year, the Technical Developer Community (TDC) has sifted through hundreds of tickets and thousands of comments — all with the goal of synthesizing community members’ requirements and improving the 2.0 specification to serve them. We have listened, debated, agreed, and disagreed, all the while keeping the spec simple and pragmatic yet still powerful. This next major milestone will be the first Implementer Draft, and it will be released on February 28, 2017.
Over the last few months, we’ve made announcements of the upcoming changes in the spec via a series of blog posts, talks, and of course, changes to the spec itself. Here is a brief recap of some of the more notable changes:
To help tool developers, we have also committed to semantic versioning of the spec. This means that any changes to it will trigger a version update, making it easier to manage and control.
After so much work that has gone into the specification, it is time for developers to begin to prove its use in real-world scenarios. As such, this Implementer Draft is an important step toward a final version. As this wider audience provides feedback and any resulting issues are closed, it will bring us to final release. This, today, is a call for you to start working with the specification and to help us ensure its accomplished its goals at the highest quality.
This also means major changes to the specification should no longer be introduced. This does not mean that the specification is fully-ready, but we have begun focusing on cleaning up the documentation to help make the new spec more approachable.
So over the next few weeks, the TDC will concentrate on closing resolved tickets and marking tickets for future versions. We will also validate that the spec has all the information needed, including clarifications and examples where appropriate.
As a community member (yes, you!) please look for any tickets marked ‘help wanted’, which indicate that assistance is needed to help resolve an open issue. As always, do not hesitate to submit additional tickets and PRs, regardless of the release status.
As we begin to roll out the latest version of the OpenAPI Specification, stay up to date on developments, Meetups, events and job opportunities on the OpenAPI Spec LinkedIn Group.
Participation is open to anyone interested in learning more about the OpenAPI Specification and the Open API Initiative.
Arnaud Lauret (aka the API Handyman) of AXA Banque
This talk, OpenAPI Trek, aims to explain what is the OpenAPI specification and how it can be extensively used throughout the API lifecycle. Post includes video and slides.
View Presentation: http://apihandyman.io/openapi-trek-api-days-london-2016/
The Open API Initiative is pleased to welcome Cloud Elements, a unified platform for API integration and management out of Denver Colorado as the latest company to join the OAI. Here is what our newest members had to say about the benefits of joining the OAI and why they contribute to the OpenAPI Specification.
Mark Greene, CEO of Cloud Elements
Mark Geene, CEO and co-founder shares “We are thrilled to be the newest members of OAI, to join in the forces to create, evolve and promote the vendor neutral API spec. Since our early days, Cloud Elements has recognized the importance of open, machine-readable API docs and have always been committed to Swagger.”
The Cloud Elements Summer Hike Days at Matthew Winters near Red Rocks.
Joining OAI is an integral decision to our product development strategy here at Cloud Elements, which we believe will further enhance the simplicity of our API Integration platform, and continue to reduce the burden on our customers to combine Cloud Elements with other API Management Platforms and API Gateways. Ultimately we believe that the Open API Initiative not only saves a significant amount of time for our own developers, but our customers’ developers, as well.
Building APIs to a specification is a major key to success. Rocky Madden, our Senior Platform Engineer, chimes in, “Not only has the Open API Initiative taken on the Swagger Specification, but it is stepping up it’s game with v3.0, improving how APIs can be discovered and understood by humans and machines alike. Interoperability is what OAI Is all about. It’s extremely powerful when tools and services are able to be built around the same common spec, allowing us to create robust integrations, improve how we interop with other APIs, reduce time to delivery, and so on.”
Rocky Madden,
Senior Software and DevOps Engineer, Cloud Elements
Madden continues, “For us specifically, the OpenAPI Specification has improved our own platform and helps us quickly add new Elements (endpoints) to our integration catalog. The standardization has also made it possible for us to tap into other cloud services that are also built on OAI. Our partnerships with companies like Amazon AWS will allow developers to create REST APIs which can be published into such marketplaces easily, made possible, in part, by collaborating with the Open API Initiative.”
There are a lot of companies, including ourselves, joining the movement to support the Open API Initiative. We couldn’t be more thrilled to be a part of OAI and continue to create and evolve the API Description format.
