Apr 14

OpenAPI Initiative Welcomes Bloomberg as Newest Member

By OpenAPI Initiative Announcement, Blog

OpenAPI Initiative continues fast pace of membership growth; Bloomberg joins 38 current members that include Atlassian, eBay, Google, Microsoft, Red Hat, SmartBear, and many more

SAN FRANCISCO – April 14, 2020 – The OpenAPI Initiative, the consortium of forward-looking industry experts focused on creating, evolving and promoting the OpenAPI Specification (OAS), a vendor-neutral, open description format for RESTful APIs, is announcing today that Bloomberg has joined as a new member.

As a global leader in business and financial information, data, news and analytics, Bloomberg believes that standardizing Web APIs throughout the financial industry will provide consistency and value across the global capital markets ecosystem. Bloomberg sees the advantages of implementing the OpenAPI Specification to improve time to market, shorten development lifecycles, and reduce implementation costs.

“Bloomberg is excited to join the OpenAPI Initiative, where we’ll have the opportunity to help shape the OpenAPI Specification and its role in the global financial industry,” said Richard Norton, Head, Data License Engineering Group at Bloomberg. “As our enterprise customers are increasingly looking to access our data feeds to power their in-house analytics and trading applications, we are confident that the OpenAPI Specification will enable them to seamlessly manage their Bloomberg data. Plus, the entire industry will benefit from our involvement in the standard’s governance process as we’ll be able to take their learnings and contribute back to future iterations of the de facto standard for describing Web APIs.”

“We are excited to welcome Bloomberg to the OpenAPI Initiative. Major corporations are taking advantage of the OpenAPI Spec for a simple reason: developer productivity. Instead of producing SDKs, organizations can produce OpenAPI specs, and then generate their SDKs in any language they’d like to use, immediately benefitting their customers,” said Marsh Gardiner, Product Manager, Google, and Technical Steering Committee, OpenAPI Initiative. “We see firsthand business and technical productivity wins when organizations use the OpenAPI Spec. Bloomberg has embraced open source, and the benefits for their enterprise customers managing Bloomberg data is immense.”

Hundreds of software engineers across Bloomberg’s global engineering workforce have provided code, documentation, tests, or other improvements to open source projects. In areas relevant to Bloomberg’s infrastructure needs, Bloomberg engineers have become project leaders and committers. To find out more about Bloomberg’s open source activities: https://www.TechAtBloomberg.com

OpenAPI Resources

To learn more about participate in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

● Become a Member

● OpenAPI Specification Twitter

● OpenAPI Specification GitHub – Get started immediately!

● Share your OpenAPI Spec v3 Implementations

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Feb 26

Love0

Liferay Joins OpenAPI Initiative

By OpenAPI Initiative Blog

OpenAPI welcomes Liferay as our newest OpenAPI member!

Having a robust API infrastructure is critical to meeting diverse customer requirements for a Digital Experience Platform (DXP) product like Liferay DXP. DXP is an emerging category of enterprise software that provides an architecture for companies to digitize business operations, deliver connected customer experiences, and gather actionable customer insight.

For example, customers may wish to build a mobile app that leverages rich personalized content provided by Liferay DXP or bring product information from a product catalog into a store-front powered by Liferay Commerce. Because integrations frequently involve different teams and departments using different tools, standardizing on the OpenAPI Specification is key to accelerating development and minimizing potential hurdles in the development process.

“Liferay is proud to join the OpenAPI Initiative,” said Michael Han, Chief Technology Officer at Liferay, Inc. “Open source and open ecosystems are a core part of who we are, and we appreciate the opportunity to work with the community to drive API standardization and adoption. Adopting the OpenAPI Specification also helps Liferay customers get to business value faster by allowing their developers to use an industry standard structure to access Liferay headless services.”

Liferay has placed special emphasis on delivering powerful APIs based on the OpenAPI specification as a way to better address their customers’ specific needs and be able to better provide tools to customers to build their own APIs.

“We’re pleased to welcome Liferay to OpenAPI and to see expansion of an even broader range of enterprise applications,” said Marsh Gardiner, Product Manager, Google Cloud, and Technical Steering Committee member, OpenAPI Initiative. “It’s great to see companies that build their business around integration fully embrace the OpenAPI Specification.”

Liferay has recently completed the first phase of mapping all of their APIs to the OpenAPI Specification.

Liferay Resources

OpenAPI Resources

To learn more about how to participate in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

About Linux Foundation

# # #

Jan 29

Love0

Interzoid Joins the OpenAPI Initiative to Help Build Frictionless Data Future

By OpenAPI Initiative Announcement, Blog

OpenAPI welcomes Interzoid as a new OpenAPI member!

“We are excited to be a part of accelerating the adoption of a standard that we believe will play a central role in the upward march of the API Economy. The fast and easy movement of valuable data around the Web, combined with our data asset improvement API offerings, is greatly enhanced by leveraging the OpenAPI Specification,” said Robert Brauer, Interzoid, CEO. “As someone who has been working with APIs for nearly two decades, I think the OpenAPI Specification is one of the more attractive and useful innovations yet.”

Interzoid was founded in 2019 and has built their software stack on open source technology, including Linux, Angular, the Go programming language, and PostgreSQL. Interzoid provides 20+ APIs that provide services like generated similarity keys to match disparate data sets using their City Match API, Full Name Match API, Company Match API, and more. Interzoid is looking to build future open source projects that support the company strategy of frictionless data.

“We are excited to welcome Interzoid as a new member of the OpenAPI Initiative,” said Marsh Gardiner, Product Manager, Google Cloud, and Technical Steering Committee member, OpenAPI Initiative. “Interzoid has used the OpenAPI 3.0 Specification format to formally describe all of their APIs. The specification is a great way to help developers quickly evaluate and understand the details of the services they’re providing.”

List of Interzoid APIs Available: https://www.interzoid.com/services

OpenAPI Resources

To learn more about participate in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

About Linux Foundation

# # #

Oct 31

Love0

Photos from ASC 2019

By OpenAPI Initiative Blog, Events

ASC 2019 was a fantastic event! Thank you to everyone who came and participated. Great speakers, great interactions between sessions, and, wow, nice location! Vancouver is beautiful.

Here are some of the lasting images of the information-packed 3 days!

Oct 08

Love0

Enterprise Software Pioneer IFS Joins the OpenAPI Initiative

By OpenAPI Initiative Blog

OpenAPI Initiative is pleased to welcome IFS as a new OpenAPI member! IFS develops and delivers enterprise software for customers around the world who manufacture and distribute goods, build and maintain assets, and manage service-focused operations. This includes service management, Enterprise Resource Planning (ERP), and Enterprise Asset Management (EAM). The company’s flagship product is IFS Applications which it develops, supplies, and implements both directly and through a global ecosystem of over 400 partners. Founded in 1983, IFS employs over 3,700 people supporting more than 10,000 customers around the world and has projected revenues to be over $700 million in 2019.

“IFS is pleased to join the OpenAPI Initiative. Supporting open source development and governance of the OpenAPI Spec, a vendor neutral description format, will benefit IFS customers by making it easier for them to integrate our software into their business and IT landscape, and enabling them to extend the solution on the ‘outside’ as an alternative to using more intrusive customizations,” said Dan Matthews, IFS Chief Technology Officer. “Come ask our development and support teams how working with the OpenAPI Specification can help your IFS implementation.”

IFS and OpenAPI

IFS supports the OpenAPI Spec (OAS) v3 and has been working with OAS and its predecessor the Swagger Spec for some time. IFS Applications is fully API enabled, with more than 10,000 native RESTFul OData APIs covering the full breadth of functionality. OpenAPI Specs are available for all APIs.

Connect with IFS

Learn more about how IFS enterprise software solutions can help your business today at ifs.com.

Follow IFS on Twitter: @ifs

Visit the IFS Blog on technology, innovation and creativity: https://blog.ifs.com/

More OpenAPI Resources

Become a Member
Join the OpenAPI Initiative Mailing List
How to Contribute to the OAS
Twitter (@OpenAPISepc)
Twitter (@APISpecs)
LinkedIn

Sep 04

Love0

From Bitmovin: Our OpenAPI journey with Standardizing SDKs

By OpenAPI Initiative Blog

This blog post was originally written by Sebastian Burgstaller for the Bitmovin blog. Bitmovin is a member of the OpenAPI Initiative.

Don’t miss on out the most comprehensive API event of the year, ASC 2019, coming up Oct 15-17 in Vancouver, BC. Information and registration details here.

As with most technical products, documentation is a critical factor to customer success, that sentiment is made even more true for API driven products, but good documentation is only part of the story. Sure we provide a beautiful dashboard, where it is definitely possible to start an encoding, but we still find that the bulk of encodings processed in our system are started via API calls. Even then, the best API documentation will only get you so far – without an API SDK, you would need to implement all the calls yourself before you would be able to enjoy your first encoded content. That’s why the Bitmovin team always provides detailed documentation in several different programming languages for each API SDK, so any developer can jump-start their first encode in a matter of minutes.

It’s no trivial endeavor to keep documentation and SDKs in sync, especially when new features are added on a weekly basis. We needed a better way to connect the parts, and our search led us to the OpenAPI 3.0 specification.

Long story short: over the course of the last year, we migrated our existing API Blueprint documentation to the OpenAPI format. This migration details more than 800 endpoints, so a considerable amount of work was necessary, but because of it we are not only able to provide stunning and detailed documentation, we can also generate our API SDKs, so they stay in sync with our full feature set.

Let’s jump into the details of our journey and showcase the other great things we accomplished along the way.

What is OpenAPI?

The OpenAPI specification, formerly known as Swagger specification, defines how to describe and document RESTful web services in a machine-readable way. For us, this is critical, as we want to provide beautiful and easily discoverable documentation to our customers. Over time different specification formats, like RAML or API Blueprint were invented, but the industry converged more and more toward OpenAPI. In 2015 the OpenAPI Initiative was created, which brought the efforts of various companies like Google, Microsoft, IBM and others under one umbrella. This sent a strong signal to the industry that this documentation format was on its way to becoming the de facto standard and could be used with a high degree of confidence. Since then a lot of great tooling has been contributed by different companies and by the community.

A technical background on OpenAPI

An OpenAPI document is either written in JSON or YAML syntax and is structured into the following blocks:

The most important blocks for us are components, which contain all of our models used in HTTP bodies of requests and/or responses, and paths, which contain the list of all endpoints and actions our API provides. A simple example of an OpenAPI document can be found here.

So why migrate to OpenAPI?

Better documentation helps engineering teams scale easily and keep up with demanding projects. Here are some of the main reasons Bitmovin decided to migrate to OpenAPI:

1. Simplified and searchable online documentation

With our new API definition, we were able to explore the documentation-oriented tooling of the OpenAPI ecosystem. This led us to the swagger-ui project which now serves as the basis for our online API reference. Now, our documentation not only lists each endpoint of our products, but it also describes them down to the last detail, including sample requests and sample responses.

We find that most technically minded individuals prefer to learn about new features through testing, that’s why we enable logged in users to send off requests directly from the endpoint documentation. To see how this works, just click on the “Try it out” button and fill in the request details – no need to enter your API key, we already have it configured for you. Don’t have a Bitmovin account? Register today for a free 30 day trial.

When creating documentation it is not only important to provide meaningful, complete and up-to-date information, it is important that all this can be easily discovered and accessed. That’s why we built a powerful full-text search functionality around our API documentation. For example, want to find which endpoints to use to create thumbnails for your encoding? Just search for “thumbnails” in the top search bar and all the resources are listed within the blink of an eye.

2. Multi-Language SDK Code generation

To make it as easy and fun as possible for our customers to work with our products, we are providing API SDKs in seven different languages: Java, JavaScript, Python, Go, PHP, Ruby and C#. Those SDKs are actively supported, but it was always a challenge for us to keep up with the speed of product development. Every new feature added means that it also had to be implemented in those SDK code bases. As this is a time consuming (and error-prone) process, we decided to explore the possibilities of SDK code generation.

The OpenAPI generator is an open source project written in Java that can generate API SDKs for a number of different languages. This is done via a combination of language specific code and a couple of Mustache templates. The generator code defines which keywords are reserved in a specific language or defines the casing of variables and methods. The templates are basically code snippets with placeholders which, combined together with our API definition, will form the API SDK code needed to communicate with the API.

We evaluated the existing generator and found it great for small to medium-sized APIs, but for our use case, it was ultimately too limiting. Let’s take a look at an example: to get the details for a specific AWS S3 input that was created in the API, this endpoint needs to be called:

GET https://api.bitmovin.com/v1/encoding/inputs/s3/{input_id}

After generating the Java SDK with the default generator we would be able to call this endpoint in the following way:

S3Input s3Input = client.getEncodingInputsS3ByInputId(inputId);

As you can see the method gets generated as part of a client object. In fact, this single client object will contain all of our API methods – our whole API surface.

One key aspect of our philosophy is that our customers need to be able to configure every detail of their encoding jobs. This power and freedom we provide naturally leads to a larger API surface. Instead of having all these methods in one single API client object, we wanted our SDKs to be structured as similar to our API as possible. They should be easily explorable and make it clear to understand which endpoint would be called at any time:

S3Input s3Input = client.encoding.inputs.s3.get(inputId);

Because of this, we decided to write our own generator logic and templates on top of the generator project. Each slash (/) of the endpoints URL should also be a separator in our SDKs, which means that each resource’s methods are generated in their own small sub-API client object. This ensures that the users of our SDKs won’t get overwhelmed by the number of methods they need to choose from at any given time. It enables the exploratory approach of working with our API we aim for.

When we started out writing our own generator code and templates, we estimated that it would be a relatively trivial task – after all, we just wanted to restructure the code that was already being generated. However, it turned out that the current design of the generator was not encouraging extensions the way we planned them. We still managed to use the generator project as a basis and we were grateful to have it, but we had to invest much more time than expected. After all this work, we felt that a dynamically typed language like JavaScript might be a better fit for an API SDK generator, as it provides natural customization possibilities. Another point we might have underestimated was the effort needed to design the API SDKs as idiomatic as possible for their respective language. Using the SDKs should be fun and feel natural for our customers but at the same time the code needed to be future proof, encouraging additions without breaking changes.

3. Continuous Integration and delivery

Now that we were able to generate the API SDKs, the next step was to automate this process. We were now at a point where we could prototype new API endpoints in our documentation and have an auto-generated and tested SDK ready for use within minutes. During this process, the documentation gets also automatically sanity-checked and a slew of semantic validations is executed.

To be 100% sure that every SDK version is fully functional, we created a suite of dozens of stub HTTP calls that each SDK has to issue and validate in integration tests. If an SDK does not execute a request of the suite or fails to process a response correctly, we immediately stop the delivery process and alert our engineers of the problem. We use Wiremock as a mock server as it turned out to be the perfect tool to integrate into our automated build process.

The Impact of Adopting OpenAPI for the Engineering Team

At Bitmovin, the discussions about the design of new endpoints now focus on documentation or generated code. We can even write – not yet functional but compiling – example workflows that show how a new feature will be used in the context of other features. As soon as we are happy with the documentation, we can begin to implement the necessary changes in our backend services. Finally, we are dogfooding our generated SDK by writing end-to-end tests that start (a lot of) real encodings on a nightly basis. All these steps make sure that everything was implemented correctly in the backend services and matches what we defined in our API documentation, a safety we never had before with our old API documentation alone.

What’s Next for Bitmovin’s OpenAPI Journey

We already released 5 out of 7 planned API SDKs to the public. The first one (Java) is available as a stable release and won’t experience any breaking changes from now on. The other SDKs will follow in the near future and we are happy to take ideas and suggestions from you, so we can deliver the best SDKs possible. Every SDK will be released with a set of examples, so you can quickly see how the new SDK can be used.

We are really happy we switched to OpenAPI for our API documentation, as this will save us a lot of time in the future, which we can now invest in feature development. The benefits of guaranteed correct and super fast SDK updates, beautiful and searchable online documentation and rich tooling, and more that we haven’t tapped into yet, all add up to a huge improvement in quality for our customers and us. We are eager to see what we can do next with OpenAPI.

OpenAPI specific links:

SDK repositories:

May 08

Love0

Introducing ASC, the API Specifications Conference

By OpenAPI Initiative Blog

October 15-17th, 2019, Vancouver, Canada

Two years ago, the OpenAPI Initiative took over the reins of APIStrat, the API Strategy Conference that the 3Scale team ran the previous seven years. We hosted APIStrat in Portland in 2017 and Nashville the next year, and attendees of both events raved about what they learned, the conversations they had, and the connections they made in the delightfully friendly API community.

Over the years, APIStrat has delivered a huge amount of value to the API community. However, like all great APIs, conferences also need to evolve to ensure longevity. That’s why today we’re announcing ASC (the API Specifications Conference) — a new event that embodies our vision for that evolution.

There is a growing trend for technical conferences to focus more on specific technologies or techniques, giving conference attendees a wealth of content on their particular area of interest. In recent years, the focus of the API community has gravitated towards the tools and technologies defining, describing, and managing API boundaries. Many of the challenges we face are related to that interface between the API provider and the API consumer. Using some kind of contract has become the norm, but developing and managing those contracts presents its own unique set of problems and opportunities to explore.

ASC is dedicated to bringing the community together to present and discuss solutions focused on the entire lifecycle of the interface aspect of APIs. We chose the conference name explicitly to convey that this event is not focused exclusively on using OpenAPI descriptions.

The OpenAPI Initiative has never seen OpenAPI as a one-size-fits-all solution. That’s why ASC welcomes participation and content from the communities working on AsyncAPI, gRPC, GraphQL, OData, etc. as well as HTTP APIs. This event is designed to allow attendees to share and understand the options that are most suited to the applications they are trying to build.

Be sure to save the date for ASC’19, hosted by the OpenAPI Initiative from October 15-17 in Vancouver, Canada. We hope to see you there!

To be entered in a random drawing to receive a free registration to ASC, please provide us with your email address to keep you apprised of the latest information about the conference. You must complete the form by May 24. Drawing will be held on May 28.

Feb 08

Love0

Ably Realtime joins OpenAPI Initiative to share streaming data expertise

By OpenAPI Initiative Blog

Ably Realtime, the creators of the cloud-based real time streaming data platform, recently announced its membership of the OpenAPI Initiative (OAI). Ably’s membership in OIA will help users of Ably’s platform participate more easily in the real time data supply chain, while enabling the wider OAI community to benefit from Ably’s expertise and lessons learned from its broad customer base, which spans technology, logistics, sport and more.

Embracing the OpenAPI specification will enable Ably customers to define their data more quickly and make it easier to discover, thanks to the data definitions being machine-readable.

OAI principles augment Ably’s work in three main directions:

1) Simplifying real time data distribution

OpenAPI membership represents the latest step in Ably’s mission to simplify the distribution of streaming data by taking care of everything under the hood, including business-to-business exchange of data and “last mile” delivery to end consumers. This frees organisations to focus on sharing and monetizing their information.

Matthew O’Riordan, CEO at Ably, said: “Joining the OpenAPI Initiative sits perfectly with our ethos of using open protocols and standards. This will make it easier for our customers to define how people consume their data using well-understood specifications, which will ultimately make it more discoverable, usable and valuable to them.”

2) Benefiting the wider developer community

Four years (and 50,000 hours) in the making, Ably’s product was designed with developers in mind. According to Ably’s CEO:

“We want to help people liberate their data by tackling the common challenges they face when trying to distribute it. Our platform already looks after the infrastructure and protocol interoperability, so working with the OAI and incorporating these specifications into our services additionally takes care of the data definition and discovery.”

O’Riordan also revealed the broader significance of Ably’s OAI involvement:

“As our customers use the OpenAPI specifications to define their data, we’ll help them address any issues they encounter, and feed these learnings back into the specs, so the whole community benefits.

“Equally, our in-house team is excited about learning best practices from the OAI community, which we can, in turn, pass on to the community of developers who use Ably.”

Ole Lensmar, chairman of the OAI, added: “The OAI is super-excited to have Ably on board – real-time data delivery is key to providing competitive user experiences to end users and Ably’s recognized leadership and expertise in this area will be of great benefit to both the technical evolution of the OpenAPI Spec and the adoption of the spec for describing real-time APIs across all verticals.”

3) Promoting open innovation in the real time space

Ably’s membership of the OAI dovetails with the launch of the Ably Open Data Streaming Program (ODSP), and the Ably Hub, a central source for data streams. Under the ODSP, anyone producing streams of data can use the Ably Data Stream Exchange (DSX) platform to host and distribute it for free, provided they make it freely available for others to use. These open streams of data will be available via the newly launched Ably Hub, an app-store-like portal where developers can browse and subscribe to real time data feeds.

More information about the Open Data Streaming Program is available on the Ably website at https://go.ably.io/open-data-streaming-program.

To find out more about Ably Realtime, the Data Stream Exchange (DSX) and the Ably Hub, go to https://www.ably.io/dsx.

###

Ably Realtime is a cloud-based realtime data platform. This allows internet-enabled devices — like computers, phones, servers or Internet of Things sensors — to stream data to each other in milliseconds. Uniquely, Ably Realtime’s Data Stream Exchange (DSX) brings enterprise-scale realtime APIs for businesses that need to share data in real time, and for developers building realtime services. This is offered with unrivaled 100% service availability, message delivery guarantees and low latencies globally. Find out more at https://www.ably.io/dsx.

Aug 14

Love0

eBay Provides OpenAPI Specification (OAS) for All its RESTful Public APIs

By OpenAPI Initiative Blog

Today, eBay announced that they are leveraging the OpenAPI Specification (OAS) for all of its RESTful public APIs. With OpenAPI, developers can download an eBay OpenAPI contract, generate code and successfully call an eBay API in minutes. APIs play a critical role in eBay’s Developer Ecosystem helping the company build and deliver the best experiences to its buyers and sellers.

“The move to using the OpenAPI Specification was an unanimous choice given our needs and knowledge of the incredible ecosystem of developers that surround OpenAPI,” said Gail Frederick, GM of eBay Portland and VP Developer Ecosystem at eBay. “The OpenAPI Specification is the de facto standard for describing APIs and plays a critical role in the new microservices-based architecture at eBay.”

As a member and chairperson of the of the OpenAPI Initiative, I see more and more companies moving to distributed and microservice-based architectures as the need to build quality experiences for users and ship products or services to market faster is a linchpin to any business’ success. Technologies and tools created to support this transition are largely built from open collaboration, spanning application development technologies like Node.js to container orchestration like Kubernetes. Since APIs are the “glue” between distributed components, the OAS standard plays a central part in this transition.

This was definitely the case with eBay. As eBay transitioned from a monolithic and centralized architecture to a distributed microservice architecture, the company needed to evolve the way service contracts were explored, tested, published, and integrated with API specifications.

The company had a set of needs for this transition:

API contracts would need to meet the needs of seamless exploration and integration across a diverse technology stack, be industry standard, and be feature rich to complement our Technical Standards and governance models necessitated the exploration for a new specification.

The primary criteria was a specification that was both human and machine readable, language agnostic, vendor-neutral, and open source.

Shekhar Banerjee, Senior MTS Architect, eBay

OAS became the unanimous choice due to its tooling support, fully customizable stack, code-first and contract-first approaches to API development, and most importantly because OpenAPI continues to evolve as a standard led by open collaboration from the OpenAPI Initiative. The move to OAS furthers eBay’s mission to its Developer Ecosystem to promote developer efficiency and productivity with no more SDKs and no more hours spent writing API client code.

eBay has been a member of the OpenAPI Initiative since August 2017 and one of the first in the industry to publish contracts based on OpenAPI 3.0 specification. We are very excited to see eBay’s continued support of our consortium, as well as other open collaboration projects, including the Cloud Native Computing Foundation (CNCF). We look forward to sharing more around eBay’s success with OAS as well as the many users and members that make up our ecosystem during API Strategy & Practice Conference happening September 24 – 26 in Nashville, Tennessee. Learn more about this conference here, and keep up-to-date with news coming out of the OpenAPI Initiative here.

Jul 26

Love0

The OAI Announces the OpenAPI Specification 3.0.0

By OpenAPI Initiative Blog

The Open API Initiative (OAI), a Linux Foundation project created to advance API technology, announced the 3.0.0 release of the OpenAPI Specification. The OAI provides a foundation for developing interoperability of APIs and other technologies.

The OpenAPI Specification (OAS) v3 release is the culmination of nearly two years of collaboration among senior API developers and architects from across multiple industries, such as payment and banking, cloud computing, the Internet of Things, and vendors building API solutions. Under the auspices of the OAI, this collaboration provides a common way to unify how an industry defines and describes APIs—the services fundamental to how applications talk to each other in today’s connected world. The OpenAPI Specification defines the interfaces for RESTful APIs, describing resources and operations in a format that is easily discoverable and understandable by both machines and humans.

“The release of this third-generation format is a significant milestone for our community,” said Ole Lensmar, CTO, SmartBear Software and Chair of the OAI Board. “The updates made are entirely user and usage driven and that plays a huge role in the success of the specification. One of the most powerful things about this release is its ability to drive the full API lifecycle.”

Major improvements in the new version 3 release include support for describing callbacks, links to express relationships between operations, webhooks, enhanced examples, improved parameter descriptions, and better multipart document handling. Additional features add support for templated server URLs and semantic versioning. A detailed list is available here: OpenAPI Specification v3

“We’re excited to see growth in adoption and validation for a common OAI Specification, with nearly 4X growth in member companies over the past 18 months alone and increasing interest from governments and the healthcare and fintech sectors,” said Linux Foundation Executive Director Jim Zemlin. “Such growth validates the community’s vision to deliver an open way to share data with APIs.”

APIs have been elevated from a development technique to a driver of business, necessary for technology innovation and modernization. According to ProgrammableWeb, nearly 18,000 public APIs have been published since 2005, up nearly 1,000 in the past quarter of 2017 alone. Founded in 2015, the Open API Initiative has swelled to 27 members in the last 18 months and continues to accelerate beyond API vendors to include leaders in banking, healthcare, and governments worldwide.

Industry Support for OAI

42Crunch
“42Crunch is honoured to be part of the Open API Initiative,” said Philippe Leothaud, Chief Innovation Officer at 42Crunch. “The OpenAPI Specification is open source, platform-agnostic, vendor-agnostic and extensible. Leveraging this de-facto standard will accelerate API adoption across all industry verticals and, in particular, help the automatic consumption of APIs from applications and devices.”

Hart
“Healthcare is going through a data revolution right now with APIs at the top of the agenda,” said Mohamed Alkady, President at Hart. “By agreeing on a common API structure that allows anyone to quickly help build this future without having to re-learn a new nomenclature every time. With the release of OAS3 we are getting closer to a more well defined structure that can be more universally usable and deployable. We believe the Open API Initiative and joint technologies will lead to next-generation changes in API development and we’re excited to push this initiative forward in the healthcare space.”

IBM
“The OAI has progressed this specification relatively quickly, and the IBM Cognitive Cloud and API Economy teams are set to embrace this new, open specification”, said Todd Moore, VP of Open Technology, Digital Business Group at IBM. “By helping to establish the OAI, IBM joined with other companies who understand that robust, scalable, and secure APIs for enterprise systems form the basis of modern digital ecosystems. In addition, today’s software developers want open tooling to help them quickly and consistently create APIs to accelerate business transformation. Our clients trust IBM to help them manage their entire API management life-cycle.”

Kong (Mashape)
“Kong is the world’s most popular open source API gateway, and we’ve seen incredible growth of OpenAPI Specification usage,” said Marco Palladino, CTO and Co-founder, Kong (Mashape). “API specifications are a critical part of modern API development, publishing, and consumption workflows – and the Open API Initiative has been tirelessly advancing the industry-leading OpenAPI Specification format to its milestone 3.0.0 release. We are excited to keep contributing to the tooling ecosystem around OAS.”

Microsoft
“Microsoft congratulates the Open API Initiative and its developers on the release of version three of the OpenAPI Specification,” said Kamaljit Bath, Principal PM Manager, Azure Developer Experience. “We use OpenAPI across the company including: for description of Azure APIs and generating client libraries using the AutoRest tool, for describing over 150 services integrated with Azure LogicApps / Microsoft Flow, for customers to describe APIs they’re bringing to the Azure API Management service, and for description of APIs for which we generate documentation hosted on https://docs.microsoft.com/ and https://apidocs.microsoft.com/. We look forward to the latest release and the improvements it brings for ease of authoring, maintaining, and consuming OpenAPI descriptions.”

MuleSoft
“This new version of the OpenAPI Specification (OAS) incorporates important advances in describing APIs more fully, ” says Uri Sarid, CTO, MuleSoft. “API specifications are central to enabling robust, productive, and rapidly growing marketplaces of business capabilities. These marketplaces, in turn, are at the heart of digital transformations in enterprises, in governments, and across entire industries. OAS version 3 provides a broad format for describing APIs, RAML provides a powerful format for modeling APIs, and the API Modeling Framework leverages both to provide reusability and consistency and a universal SDK for building API tooling. We look forward to continuing to invest in these and in advancing OAI standards to create value for the API ecosystem.”

Red Hat
“Red Hat is a strong believer in Open Standards and Open Source,” said Steven Willmott, Senior Director and Head of API Management, Red Hat Inc. “The progress of the Open API Initiative and this release show what the power of community can do and we are pleased to see the industry coalescing around a strong common standard.”

SmartBear
“SmartBear is a strong supporter of open source communities, having donated the original Swagger Specification to the OAI in 2015. The evolution of the spec shows the power of bringing together collaborators across industries, to evolve the specification to meet the needs of API developers and consumers across the world in an open and transparent manner,” said Ron Ratovsky, Swagger Developer Evangelist, SmartBear. “SmartBear is committed to supporting the OAS 3.0 with our open source Swagger tools and our integrated platform, SwaggerHub.”

Tyk Technologies
“An increasing number of our customers are adopting the OpenAPI Specification as the de-facto API description format,” said Martin Buhr, CEO and Founder of Tyk Technologies. “As a leading Open Source API Management platform, Tyk is committed to open source and open standards, and we’re excited to be part of the OAS v3.0 specification launch.”

Current members of the OAI include: 42Crunch, Adobe Systems, Inc., API Evangelist, Atlassian, CA Incorporated, Capital One, Cloud Elements, Finxact, LLC, Google, Inc., Hart, IBM, Intento, Inc., ISA Research Group, Mashape Inc., Microsoft Corporation, MuleSoft, Oracle Apiary, Red Hat, RepreZen, Restlet, Inc., Salesforce, Samsung ARTIK Cloud, SmartBear Software, Software AG, StopLight, and Tyk.

OpenAPI is an evolution of the Swagger specification, which was donated by SmartBear to The Linux Foundation in 2015. To get more information about the OpenAPI Specification and learn about membership and contributions, please visit: https://www.openapis.org/

Resources:

The OpenAPI Specification v3
Follow OAI on Twitter @OpenApiSpec or join the conversation on GitHub

About the Open API Initiative
The Open API Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how REST APIs are described. As an open governance structure under The Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor-neutral description format. Visit https://www.openapis.org/ for more information.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.