Jun 16

OpenAPI Initiative Welcomes RapidAPI

By OpenAPI Initiative Announcement, Blog

RapidAPI is joining the OpenAPI Initiative! RapidAPI helps developers find, manage, and test APIs. They provide an API Marketplace for developers to discover and connect to thousands of public APIs. The company’s services can be tailored to a company’s brand, to build private marketplaces for internal and external APIs. Notable enterprise clients include SAP, Cisco, Tata, and Hyatt.

To learn more about RapidAPI Marketplace, sign up for a free account here.

To better understand how RapidAPI provides a next-generation infrastructure for APIs and what a collaboration with the OpenAPI Initiative would mean for them, we asked Iddo Gino, CEO and Founder.

Why did RapidAPI join the OpenAPI Initiative, and why now?

APIs are the heart and soul of RapidAPI. With acquisitions like the Paw Client and unique developer tools such as RapidAPI Testing — we care deeply about the developer experience of writing, publishing, and ultimately maintaining APIs. OpenAPI plays a significant role in all of this.

Our goal in joining the OpenAPI Initiative is to give back to the community. As we build the next-generation of API Developer Tooling, it’s more important than ever to be part of the API builders’ community conversations. OAI is where API builders and API consumers go beyond the original spec to collaborate on exciting things such as JSON Schema and Asynchronous APIs and beyond. RapidAPI wants to help advance the specification through participation in the community.

Additionally, we’re committed to making our platform easily interface with 3rd party tools. Therefore, it’s important for us to continually support the OpenAPI Specification format, allow interconnectivity of all tools, and avoid customer lock-in.

The RapidAPI team has a history of participation in development communities. Our Head of DevRel Ahmad Awais is an active voting member of the Node.js Community Committee and WordPress Foundation Core Contributor before that. Our Head of Marketing, Suzanne Panoplos, has been active in the Open Container Initiative and CNCF. As you can see, joining the OpenAPI Initiative and becoming a member of the Linux Foundation couldn’t be a more natural transition for RapidAPI.

What goes into making an API marketplace? What makes one better than the other?

A robust API marketplace enables developers to find, connect and manage APIs from a single place and support a variety of APIs including REST, SOAP, GraphQL or Asynchronous APIs. For each API you should be able to see performance metrics like average latency, uptime, and popularity and be able to test the API from the browser.

Additionally, a marketplace should enable you to:

Gather information about each API using the endpoints page to view a list of endpoints, documentation, and a code snippet to help you implement the code into your app.
Subscribe to API plans to start using it. Manage all your API subscriptions and payments through a single source.
Utilize a single key for all your APIs.
Manage applications and API keys using a single dashboard. Using this dashboard, you should be able to:
- Monitor API performance by visualizing how many requests are made to different APIs, tracking the number of requests that return an error, and viewing latency data for each API.
- Debug faster by inspecting the logs for all requested data.
- View usage and billing information for a breakdown of API spending, including the monthly recurring and overage charges.
- Manage subscriptions from one place including quota usage and time remaining until the quota limit resets.

How has COVID affected the use of APIs in the past year?

With the pandemic, digitalization has gone from being a “nice to have” to an imperative to survival. Take Starbucks as an example. Before the pandemic, 7% of Starbucks revenue came from mobile ordering. During the pandemic, 100% of their revenue came from mobile ordering as most stores were closed to in-person ordering.

To react to the changing environment during the pandemic, companies had to adjust their application development process and accelerate their delivery to address changing market conditions. To do so, companies have to rely on APIs in their software development.

This trend is true across almost all industries during the pandemic. Still, there has been an explosion of API usage in healthcare settings, where services, appointments, and scheduling have taken place online to the homebound consumption of services such as food ordering, retail, etc.

This trend was highlighted in RapidAPI’s 2020 Developer Survey, released earlier this year. The survey indicated that developer reliance on APIs accelerated during the pandemic and will continue to increase in 2021.The data revealed that 61% of developers used more APIs in 2020 than in 2019, and 71% plan to use even more during the upcoming year.

What’s your vision for API marketplaces 1-3 years out?

As API proliferation continues to increase across all organizations, enterprises will find it to be a necessity for finding, connecting to and managing their APIs. Marketplaces will need to provide:

An Open Platform – With organizations using disparate API gateways, marketplaces will offer a platform for integrating with multiple different gateways and clouds.
Developer Experience – Marketplaces will need to be continually developer-first, providing the key features needed to deliver API use and reuse such as deep search and tagging API analytics for providers or consumers, and advanced usage controls for developers.
Out of the box experience – Marketplaces will need to have everything developers need to succeed including advanced features such deep search, end user analytics, and developer registration workflows.
Many-to-Many Model – Marketplaces will need to support multiple teams of API providers offering APIs to internal consumers as well as partners and customers.
Support for All API Types – Marketplaces should support all of the last APIs including SOAP, REST, GraphQL, Async APIs like Kafka, and more.
Scalability – Marketplaces should scale to support hundreds of APIs with room for future growth.
Governance – Marketplaces will unify visibility and governance across all APIs in the organization, regardless of which clouds or API gateways are in use.

We are excited to welcome RapidAPI to our list of growing members and look forward to working closely together!

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

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.

Jun 03

Love0

BetterCloud Joins OpenAPI Initiative

By OpenAPI Initiative Announcement

BetterCloud is joining the OpenAPI Initiative! BetterCloud is a SaaS management platform (SMP) that provides IT professionals with a solution to discover, manage and secure the growing stack of SaaS applications in their digital workplace. The driving force behind BetterCloud is to ensure organizations get the transformative value and benefits of adopting SaaS applications, while ensuring IT has complete control over their environment and can serve as an enabler for the business.

BetterCloud helps manage SaaS data and creates custom, automated workflows, you can monitor and operate with a centralized admin console. To request a demo, click here.

We talked with BetterCloud to understand how SaaSOps works, its future and what becoming a member of the OpenAPI Initiative would mean for them.

What is SaaSOps and what size companies should evaluate SaaSOps?

Response from Jamie Tischart, CTO

SaaSOps is a practice referring to how software-as-a-service (SaaS) applications are discovered, managed, and secured through centralized and automated operations (Ops), resulting in reduced friction, improved collaboration, and better employee experience.

SaaSOps can be divided into three categories. The starting point is SaaS discovery, which involves understanding what applications exist within your SaaS environment. Next is SaaS Management, which addresses what IT needs to ensure proper onboarding / offboarding procedure, access management, spend management and more. The third category is SaaS Security, which focuses on data protection; specifically incident response, file security, identity and access, and regulatory compliance.

SaaSOps can be implemented by any company, regardless of size. Mid- to large-size companies tend to have more complex SaaS stacks, and therefore are more likely to embrace SaaSOps in order to manage and protect their SaaS environments.

Where will SaaSOps be in 2-3 years?

From Jamie Tischart, CTO

We are going to see explosive growth in the coming years as companies embrace more and more best-in-breed SaaS applications. The larger and more complex a company’s stack, the more IT needs robust practices in place to discover, manage and secure those applications. We’ve already seen a surge in demand for SaaSOps professionals since the start of the pandemic, and we expect that to continue growing.

Why is BetterCloud joining the OpenAPI Initiative and why now?

Response from Brian Miller, Senior Staff Engineer

Given we hadn’t known an insider until now—thank you Lorinda Brandon—it never dawned on us to explore joining as a possibility. We are delighted to help and grow the community and make the OpenAPI community more of a de facto standard within the SaaSOps world.

Response from Lomesh Patel, Software Architect

In addition to Brian’s response above, we’re interested in defining an API standard for integrating with a SaaSOps platform and we’re looking at OpenAPI as a foundation for that.

Have you implemented OpenAPI Specification 3.1.0? What advice do you have for companies evaluating it?

From Brian Miller, Senior Staff Engineer

Implementation is a loaded word. Are we going to implement it for documenting internal and external apis? Yes! We have already done that at a certain level, but more importantly we are using OAS as a foundation to expand and define what it means to manage your SaaSOps integration.

From Lomesh Patel, Software Architect

Our advice for companies evaluating Specification 3.1.0 would be to standardize all of their API (both internal and external) definitions and documentation using OpenAPI and to develop all their product features with API-first approach.

Welcome BetterCloud! Very pleased to have you as part of the OpenAPI Initiative!

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

About Linux Foundation

Apr 27

Love0

Checkly, API Monitoring and Automation, Joins OpenAPI Initiative

By OpenAPI Initiative Announcement, Blog

Customer base already heavily utilizing OpenAPI Specification, Checkly “doubling down” on open source with increased contributions to projects like Headless Recorder and monitoring-as-code

SAN FRANCISCO – April 27, 2021 – 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 Checkly has joined as a new member.

Checkly provides a monitoring and testing platform for developers and modern DevOps teams. The Berlin-based company’s cloud platform allows developers to monitor their API endpoints and web apps. Customers can configure fully-fledged HTTP requests with flexible assertions and setup/teardown scripts. To monitor web apps, Checkly runs JavaScript and open-source powered browser checks.The company has also developed the open source Headless Recorder for creating end-to-end testing scripts through a Chrome extension. As a critical initiative, Checkly’s focus is on monitoring-as-code enabled through its public API.

“We are very excited to join the OpenAPI Initiative. Our customers and we are benefitting from standardized APIs. OpenAPI enables our customers to get their API monitoring setup started easily and therefore provides immense benefits in flexibility and openness,” said Hannes Lenke, CEO at Checkly. “We see the opportunity to contribute to the initiative through our day-to-day experiences and want to connect with key players in the field to discuss ideas and network. In 2021 we want to double down on OSS and as part of the initiative joined OpenAPI as we see as a great and natural fit.”

“With the growth of DevOps and microservices, API usage has skyrocketed. Monitoring and testing is key in modern production environments, and OpenAPI documents can really help with the authoring process,” said Marsh Gardiner, Product Manager, Google, and Technical Steering Committee, OpenAPI Initiative. “We look forward to Checkly’s support of the OpenAPI Specification moving forward.”

Checkly raised a $2.25 million seed round led by Accel. Angel investors Instana CEO Mirko Novakovic, Zeit CEO Guillermo Rauch and former Twilio CTO Ott Kaukver, also participated in early funding. For more information, please visit https://www.checklyhq.com/. To learn how to learn how to simplify API monitoring with OpenAPI specs and Checkly visit: https://www.checklyhq.com/guides/openapi-swagger/

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

Apr 13

Love0

Leveraging the OpenAPI Specification in Financial Services – The Story of Plaid’s OpenAPI Journey

By OpenAPI Initiative Blog

Written by Kin Lane, Chief Evangelist, Postman

The complexity of providing financial services to businesses and consumers in today’s business climate is hard to overstate. APIs are a critical component in providing products and services.

Plaid, whose mission is to democratize financial services through technology, is a company that provides APIs for developers building applications in the fintech space. Plaid’s platform allows applications to connect with users’ accounts at banks and other financial institutions. Consumers and businesses can take advantage of a wide array of Plaid-powered apps to quickly and easily transfer funds, analyze their spending, apply for loans, and more.

Based on the new OpenAPI Specification 3.1.0, Plaid built an API document which allows them to easily release updates to their client libraries (they support five: Ruby, Node, Python, Java, Go). And, they have released an OpenAPI file for auto-generating your own client libraries in your preferred programming language, making it simple for you to auto-generate your own client libraries in over 40 different languages–so you can easily build with Plaid no matter the language you use.

The Journey to OpenAPI

The OpenAPI journey at Plaid did not begin with a single person or team, but was something that grew out of multiple teams with different motivations for why they needed a single machine readable truth to exist for their banking APIs. I recently spoke with Alex Hoffer of the developer relations team at Plaid to learn more about the motivations behind why Plaid chose to use the OpenAPI Specification, but also understand a little about how they arrived where they are at.

Plaid had recently published their OpenAPI to a GitHub repository , and I thought it was a great opportunity to reach out and talk about their adoption of the OpenAPI Specification and see if they were willing to share their story with us. They were! So thank you to the Plaid team for talking with us, and sharing the details behind how OpenAPI is being applied across API operations at the banking API platform.

Creating Better Documentation More Quickly

Like most API providers, the number one reason Plaid adopted the OpenAPI Specification (OAS) was to deliver documentation for their public API. Plaid’s documentation had been in use for quite some time now, and needed a refresh, so the developer relations team embarked on a complete rewrite, and they wanted to make sure they were able to future proof their documentation so that they could evolve it alongside their API. After researching the situation it was clear that the OpenAPI Specification (OAS) was the most effective way for describing Plaid APIs in a way that would be extensible and allow it to power the current and future state of their banking API documentation. The Plaid team moved forward with a complete reworking of their documentation, and as they were working on delivering a complete OpenAPI for the Plaid API documentation other teams were also putting OpenAPI to work powering their own corner of the Plaid platform.

Delivering Client Libraries

As the developer relations team was working on the Plaid OpenAPI document, their developer experience team was also working understanding how it could also be used to deliver client libraries for the API across multiple programming languages. The developer experience team at Plaid pushes the release of multiple SDKs for the API every two weeks, which is a manual process that takes a significant amount of work and is prone to errors, while also requiring significant expertise in each language required to deliver the best possible SDK. With all this work the developer experience team was very keen on being able to automate as much of the process as possible, but as they got to work on generating SDKs from the OpenAPI they realized that the process would demand a much more robust and complete OpenAPI to deliver all of the details needed for each of the language libraries. Ultimately it took the team five months to deliver a beta set of SDKs that met the team’s expectations, but now they have a much more streamlined approach to delivering SDKs across multiple languages, while also ensuring that the SDK release process is always in alignment with the evolution of API documentation, since they both are driven from the same machine readable truth—the Plaid OpenAPI contract.

JSON Schema Now Available

Beyond developer relations and experience at Plaid, the core services team also caught wind of the OpenAPI that was being used to power documentation and generate client SDKs. The team was interested in the centralization of a machine readable truth for the Plaid API, but were particularly interested in the JSON schema now available to describe the request and response payload for each API. There was anxiety from internal developers when it came to introducing changes to the schema that was used to power the platform, and with limited visibility into what might be a breaking change with any release, developers were left with a lot of questions. With the existence of a central set of JSON Schema definitions now available as part of the OpenAPI, internal developers could now use them to validate as part of pipelines and middleware across the Plaid platform, ensuring that ongoing changes did not update or remove any properties that might introduce errors into the APIs and downstream applications of integrations. Leveraging the central OpenAPI to help make releases more reliable and less stressful for internal developers who were moving the API platform forward with new features and capabilities—reducing friction for the Plaid platform.

Defining Extensions

With the introduction of OpenAPI into the documentation, validation, and delivery of SDKs for the Plaid APIs, there were numerous immediate benefits that the teams were able to take advantage of. However, all three teams quickly began bumping against the limitations of what the OpenAPI Specification was capable of defining. Some of these needs were unique to the way Plaid does things, but other needs resemble many of the common needs you see across other API providers. This didn’t slow the Plaid teams down, and they quickly got to work defining extensions for OpenAPI that would help them define what they needed for documentation but also the very demanding needs of generating SDKs in multiple programming languages. Most notably, they also established an x-plaid- extension that would be used to describe internal schema and capabilities that would be stripped from the OpenAPI anytime the definition would be made available to the Plaid community. This work really helped Plaid realize that the OpenAPI specification really shines when you extend and push the specification to do exactly what you need, allowing the machine readable truth for their API to effectively deliver multiple essential stops along the API lifecycle like documentation, SDK generation, and validation.

Customers Request OpenAPI Specification

The Plaid OpenAPI journey reflects what many OpenAPI adopters have experienced, or are currently experiencing. While there are many motivations for why API providers adopt OpenAPI, the need to power always up to date API documentation and SDKs in a variety of programming languages are the top two. It is a journey that usually begins with the need for providing better documentation, but then as teams realize the same OpenAPI can be used to power other stops along the API lifecycle, they really see the potential of the API specification as a single source of truth or APIs. It is great to hear the story behind why Plaid is using OpenAPI, and hopefully this story provides a look into the “known knowns” of what OpenAPI can do within Plaid, but as I was finishing my conversation with Alex Hoffer, I asked her why they had published their OpenAPI to GitHub—which ultimately was the catalyst for this conversation. She simply said that an OpenAPI was a common request from their customers so they could generate their own libraries for languages they didn’t support, but also after speaking with other leading API Providers in the space, they had mentioned they were surprised by the unique things that their community was doing with their OpenAPI, innovating beyond what internal teams could deliver. Which really gets at the most powerful reasons for providing an OpenAPI for your API community, in that it will enable entirely new approaches to putting your APIs to work, which is really why we are all doing APIs in the first place. OpenAPI is just amplifying this effect and taking things to entirely new levels.

Mar 11

Love0

OpenAPI Initiative Welcomes Level 250 as Newest Member

By OpenAPI Initiative Announcement, Blog

Level 250 is joining the OpenAPI Initiative! Level 250 is a consulting organization that helps companies large and small improve their Product Strategies around SaaS, APIs and Developer-focused Tools: https://www.level250.com

Level 250 is run by Emmanuel Paraskakis, who has over 20 years of far-reaching experience in Product Management in organizations ranging from early-stage startups to Fortune 500 companies. Paraskakis was VP of Product Management for two of the most important API products in the world: Apiary with API Blueprint (acquired by Oracle) and SwaggerHub (and the Swagger Open Source toolset) which uses OpenAPI.

With that extensive API and product background, we asked Paraskakis about Level 250, implementing the new OpenAPI Specification 3.1.0, and where APIs are headed. We found out about how the requirements of API builders and API consumers are converging, about major improvements in reuse that will help managing scale, helping non-humans (yes), and a lot more!

— Why did Level 250 join OpenAPI Initiative and Why Now?

I have always been involved in OpenAPI, with two previous member companies, Apiary and SmartBear and so it’s part of my background. APIs and OpenAPI are at the center of everything we do at Level 250, so I want to continue to support OpenAPI in any way I can.

What makes this even more relevant today is that OpenAPI is becoming so much more that just one Spec: it’s the place where thinking and collaboration around APIs happens, whether it’s about the original OpenAPI spec, or adjacent specs such as JSON Schema and AsyncAPI, and beyond. I think OAI is becoming a focal point where the requirements of API builders and API consumers are converging. Exciting times!

— What’s the biggest issue with implementing the OpenAPI Specification?

I think the Spec is a wonderful interchange format, a Lingua Franca that most API Tools speak, so you can for example take a document that was meant as a design and reuse it to configure your API Management or your Security tests.

But because it’s become complex, encompassing many use cases, I think it’s difficult to learn and I also think it’s hard to write, for the Design-first use case for example. There are tools that make the process easier, with syntax suggestions or even UI editors, but the underlying complexity remains.

I’d love to see a simpler language that could be written by hand, perhaps leveraging examples, during the ideation and design process, and that could then translate directly into the current Spec for interoperability.

Beyond that, I think we could work more on making modularity and composition easier and also the handling of metadata, discovery and runtime configuration of API Gateways.

— Who should use the OpenAPI Specification 3.1.0?

I think the most exciting news is the full JSON Schema compatibility and support of the latest 2020-12 draft! This allows anyone to describe data structures in more detail and enhances compatibility with external tooling.

Another huge win will be for folks that need to describe Webhooks and they’ve been requesting this for some time.

One of the changes that doesn’t seem to get talked about much is the fact that you don’t _need_ to have a top-level `paths` element, you can just describe `components` and that’s still a valid OpenAPI document. That’s a huge step forward for reuse. So anyone who has lots of OpenAPI documents and is experiencing the pain of repeating information with all the problems that attracts, should be making the jump to 3.1.

— What’s your vision for the future API stack 1-3 years out?

The main problems being encountered today on the API provider side are those of managing scale and decreasing time to market, so I think Specs and various description formats play a huge role by acting as a source of truth for how our services work. I hope to see tooling that uses declarative documents to inform the entire API-building lifecycle, from ideation and design, to building tests, creating deployments on multiple environments and setting up monitoring/analytics tools – all based on the same source of truth!

On the API consumer side, we are still sending developers to documentation that can vary in quality and completeness. Humans are great at dealing with ambiguity and hopefully they’ll reach out when they have a support question. But increasingly services are consumed and discovered by machines, so I hope to see tooling that helps non-humans discover and understand the capabilities of APIs.

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

Feb 18

Love0

OpenAPI Specification 3.1.0 Released

By OpenAPI Initiative Announcement, Blog

OpenAPI developer community and JSON Schema community work together to build upgrade that supports 100% compatibility with the latest draft of JSON Schema

SAN FRANCISCO – February 18, 2021 – 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 HTTP (including RESTful) APIs, announced today that the OpenAPI Specification 3.1.0 has been released. This new version now supports 100% compatibility with the latest draft (2020-12) of JSON Schema.

Along with this release, the OpenAPI Initiative has sponsored the creation of new documentation to make it easier to understand the structure of the specification and its benefits. It is available here: https://oai.github.io/Documentation/

The OpenAPI Specification is a broadly adopted industry standard for describing modern APIs. It defines a standard, programming language-agnostic interface description for HTTP APIs which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic.

The OpenAPI Specification (OAS) is used by organizations worldwide including Atlassian, Bloomberg, eBay, Google, IBM, Microsoft, Oracle, Postman, SAP, SmartBear, Vonage, and many more.

“The benefits of using the OpenAPI Specification are broadly applicable, ranging from API lifecycle management, to documentation, to security, to microservices development and much, much more,” said Marsh Gardiner, Product Manager, Google, and Technical Steering Committee, OpenAPI Initiative. “Great care was taken in evolving to version 3.1.0 to ensure it is an incremental upgrade for existing users, while also making it an excellent candidate for immediate evaluation and adoption in corporate environments. We extend our heartfelt gratitude to the diverse group of contributors for all their exceptional skills and effort on our latest achievement.”

“The mismatch between OpenAPI JSON Schema-like structures and JSON Schema itself has long been a problem for users and implementers. Full alignment of OpenAPI 3.1.0 with JSON Schema draft 2020-12 will not only save users much pain, but also ushers in a new standardised approach to schema extensions,” said Ben Hutton, JSON Schema project lead. “We’ve spent the last few years (and release) making sure we can clearly hear and understand issues the community faces. With our time limited volunteer based effort, not only have we fixed many pain points and added new features, but JSON Schema vocabularies allows for standards to be defined which cater for use cases beyond validation, such as the generation of code, UI, and documentation.

On Day One of JSON Schema draft 2020-12 being released, two implementations were ready. It’s humbling to work with such an experienced and skilled team.”

While JSON Schema is still technically a “draft” specification, draft 2020-12 sets a new stable foundation on which 3rd parties can build standardised extensions. The JSON Schema team do not foresee any major changes to the approach of the extension system, like dialects and vocabularies. However, the utility may be improved as feedback is received.

JSON Schema website: https://json-schema.org

JSON Schema Open Collective: https://opencollective.com/json-schema

JSON Schema Twitter: https://twitter.com/jsonschema

Major Changes in OpenAPI Specification 3.1.0

JSON Schema vocabularies alignment
New top-level element for describing Webhooks that are registered and managed out of band
Support for identifying API licenses using the standard SPDX identifier
PathItems object is now optional to make it simpler to create reusable libraries of components. Reusable PathItems can be described in the components object. There is also support for describing APIs secured using client certificates.

Full OpenAPI Specification 3.1.0 release notes are available here: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.1.0

A Note on Semantic Versioning

The OpenAPI Initiative had adopted semantic versioning to communicate the significance of changes in software upgrades. Semantic versioning is a popular numbering methodology where minor version updates indicate changes to software are backward compatible, whereas major updates are not. Technically, using semantic versioning with the new full alignment with JSON Schema would require this change to be denoted as 4.0.0. However, this update to OpenAPI important improvements, specifically the alignment with JSON Schema, but to force it into a major release numbering would have created a mismatch of expectations.

Special Thanks

A special callout to Henry Andrews, Phil Sturgeon, and Ben Hutton for all their work, support and patient explanations they have provided to better align JSON Schema and the OpenAPI Specification. Many thanks to Lorna Mitchell for driving the Webhooks effort, using our new proposal process. And thanks to the many, many open source developers involved worldwide.

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

About Linux Foundation

Feb 16

Love0

Migrating from OpenAPI 3.0 to 3.1.0

By OpenAPI Initiative Blog

This post is authored by Phil Sturgeon, product manager, Stoplight, and Chairperson, Protect Earth. If you’d like to donate to Phil’s charity of choice, please see Protect Earth which is reforesting the U.K. one field at a time.

OpenAPI v3.1 brings a lot of great new functionality and improvements, and at some point in the near future you might find yourself wanting to upgrade. If you’re ready to give it a try, let’s take a look at the changes you may, or may not, need to make in order to get onto OpenAPI v3.1.

First things first, let’s change that version number! Open up your OpenAPI JSON or YAML file, and look for this line:

openapi: 3.0.3

Change that to.

openapi: 3.1.0

If instead of `openapi: 3.0.3` you see `swagger: 2.0` then see if swagger2openapi can help you upgrade to v3.0 before continuing.

In a perfect world this would be all you need to do, but despite the minor version number, v3.1 does have some small breaking changes. This decision was not made lightly. Thankfully the scope of the breaking changes is incredibly small, limited to the Schema Object, and achieves a much greater goal: full compatibility with modern JSON Schema.

OpenAPI Schema is now valid JSON Schema

Everything inside the `schema` keyword in OpenAPI is defined by the Schema Object. This has always been loosely based on JSON Schema, and referred to as a “subset superset” because it adds some things, and removes some other things from JSON Schema. This has caused confusion for some folks in the OpenAPI community. To resolve the subset superset problem, contributors from both communities came together, and got these two specifications aligned.

OpenAPI v3.0 was based on JSON Schema Draft 05, and JSON Schema has gone through a few drafts since then: Draft 06, Draft 07, and Draft 2019-09. Now thanks to feedback gathered from users and tooling maintainers during the v3.1.0 release candidates, one more small draft was released: Draft 2020-12. This should be the last one for a while and no major changes are planned by the JSON Schema crew, so if all goes well a final release is on the horizon, to avoid any further discrepancies.

Supporting modern JSON Schema brings lots of handy new functionality, including being able to use items arrays for tuples, or the if/then/else keywords as an alternative to awkward nested allOf > oneOf chains some folks were using for more dynamic payloads. We don’t need to learn every new thing JSON Schema can do right now, but if we’re going to upgrade we will need to know what to change in our OpenAPI documents.

Schema Object Changes

Swap nullable for type arrays

In line with JSON Schema, the `type` keyword can now define multiple types for a schema with an array. This is useful new functionality, but has also made nullable redundant. In order to achieve the goal of letting JSON Schema tools understand OpenAPI, it was decided to remove nullable entirely instead of deprecate it.

# OpenAPI v3.0
type: string
nullable: true


# OpenAPI v3.1
type:
- "string"
- "null"

This follows the keyword independence concept, where keywords should only add constraints, but adding one more keyword should not remove a constraint. Find and replace should solve this one rather quickly.

Tweak exclusiveMinimum and exclusiveMaximum

These two keywords used to take a boolean value, which would modify the meaning of the `minimum` and `maximum` properties. In OpenAPI v3.1 they are distinct values.

# OpenAPI v3.0
minimum: 7
exclusiveMinimum: true

# OpenAPI v3.1
exclusiveMinimum: 7

Again this one can be solved with some find and replace, and I’d wager many of you don’t even use this keyword for anything.

Use examples not example

OpenAPI has a lot of places that can have an example, or multiple examples. OpenAPI v3.0 can have `example` or `examples` at the Media Type level (requests, responses, callbacks, and webooks) but it can also have a very different type of `example` inside the Schema Object. This schema object singular example was an OpenAPI-specific keyword which is no longer necessary now as JSON Schema has `examples`.

This might need an visualisation, which I will defer to Lorna Mitchell because she made some excellent slides for her talk at APIDays Paris.

# OpenAPI v3.0
type: string
example: fedora

# OpenAPI v3.1
type: string
examples: 
 - fedora

Basically switching any `example` inside a `schema` to `examples` and adding a hyphen at the start (which is a YAML array).

This is more typing if you’re writing YAML entirely by hand instead of using a visual editor, but it’s also a feature: adding multiple examples is now a lot easier. In the past to get multiple examples for a property or schema you would have to switch the type of example being used, from a property example to a media type example, which felt like overkill. Now you can do this:

type: string
examples: 
 - fedora
 - ubuntu

Describing File Upload Payloads

In OpenAPI v3.0, describing file uploads was signalled with a type: string and the format set to byte, binary, or base64. JSON Schema helps make this far more clear with its contentEncoding and contentMediaType keywords, which are designed for exactly this sort of use.

Uploading a binary file in a POST request? No need to even use a schema now.

# OpenAPI v3.0
requestBody:
  content:
    application/octet-stream:
      schema:
        type: string
        format: binary

# OpenAPI v3.1

# OpenAPI v3.1
requestBody:
  content:
    application/octet-stream: {}

Uploading an image with base64 encoding?

# OpenAPI v3.0
requestBody:
  content:
    image/png:
      schema:
        type: string
        format: base64

# OpenAPI v3.1
requestBody:
  content:
    image/png:
      schema:
        type: string
        contentEncoding: base64

Multipart file uploads with a binary file?

# OpenAPI v3.0
requestBody:
  content:
    multipart/form-data:
  	schema:
       type: object
       properties:
        orderId:
          type: integer
        fileName:
          type: string
          format: binary

# OpenAPI v3.1
requestBody:
  content:
    multipart/form-data:
  	schema:
       type: object
       properties:
        orderId:
          type: integer
        fileName:
          type: string
          contentMediaType: application/octet-stream

This keyword supports all encodings defined in RFC4648, including “base64” and “base64url”, as well as “quoted-printable” from RFC2045.

Declaring $schema Dialects to protect against change

That’s it for things you’ll need to change, and there’s lots of other functionality I could talk about, but one thing which will help avoid change in the future is the ability to define a $schema in your schemas.

$schema now allowed

The $schema keyword is optional but a useful way to define exactly what JSON Schema dialect a model is written in, which could be different drafts or even custom dialects. Tools which support multiple dialects can process the files slightly differently, meaning you don’t always need to make changes to all your models when upgrading OpenAPI versions in the future.

OpenAPI is entirely compatible with JSON Schema because it is now a JSON Schema dialect, so by default any schema is using `$schema. “https://spec.openapis.org/oas/3.1/dialect/base”` dialect. If you split your schemas into other JSON/YAML files and use $ref to point to them, they could contain a different $schema and override this default.

{
   $schema: "http://json-schema.org/draft-07/schema#",
}

This makes things a lot easier for tooling maintainers, because they no longer need to try and guess what draft a schema is by looking at where it is referenced from. In the past this created impossible situations where a single schema was referenced by OAS2 and OAS3 at the same time, and might have worked for a while, until a OAS3 specific keyword was added, now everything is broken for the OAS2 usage.

Now all models can declare their own dialect and if an OpenAPI document references a dialect that the tools do not understand how to parse, it will be immediately clear, instead of breaking after several months of usage and confusing everyone.

Feb 16

Love0

OpenAPI Initiative Welcomes Ambassador Labs as Newest Member

By OpenAPI Initiative Announcement, Blog

Ambassador Labs enables application developers to ship software faster on Kubernetes. The company’s Kubernetes-native API gateway offers an open source development kit to develop, manage, and monitor microservice architectures, enabling developers to adopt a cloud-native development workflow for Kubernetes services.

“We are heavily committed to improving support for OAS in our products, so joining the OAI is a natural move for us as we align closer with the OpenAPI community,” says Richard Li, CEO of Ambassador Labs. “In the cloud-native world, standardized API definitions create a natural point of integration across independent, fast-moving teams without strong central coordination.”

“We are excited to welcome Ambassador Labs to the OpenAPI Initiative. APIs and microservices reinforce one another, and that synergy is a key reason why it is so important to standardize how we describe APIs,” said Marsh Gardiner, Product Manager, Google Cloud, and Technical Steering Committee, OpenAPI Initiative. “We look forward to working with Ambassador Labs to evolve and promote API standards like the OpenAPI Specification.”

From Ambassador Labs:

Ambassador Labs, makers of Edge Stack, the most popular Kubernetes-native API Gateway, is proud to join the OpenAPI initiative and work with OAI to establish and evangelize the standardization on OAS for API development. Ambassador Labs is at the forefront of focusing on the cloud-native developer experience, both through dedicated developer tooling and by providing an integrated API Developer Portal.

Ambassador Labs takes a comprehensive view of the ways in which they support developers, which is rooted in their belief that while Kubernetes represents a significant shift in technology, it really represents an opportunity to change the way developers do work. The successful shift to “cloud-native” requires multiple factors to fall into place, including the standardization on APIs, which is key to delivering an optimal developer experience.

Learn more about open-source Ambassador API Gateway and how Ambassador empowers cloud-native developers to create flexibility and reduce complexity at www.getambassador.io.

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 Ambassador Labs

Ambassador Labs enables developers to ship without fear. Makers of the popular open source projects for Kubernetes Ambassador Edge Stack and Telepresence, Ambassador Labs is beloved by tens of thousands of developers worldwide. Used by companies such as Microsoft, PTC, NVidia, and Ticketmaster, Ambassador Labs has teams around the world. Join our community at https://www.getambassador.io.

About the OpenAPI Initiative

About Linux Foundation

Feb 11

Love0

OpenAPI Welcomes New Member High School Technology Services

By OpenAPI Initiative Announcement, Blog

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 High School Technology Services (HSTS) has joined as a new member.

Why did HSTS join the OpenAPI Initiative? From HSTS:

Matt Zand is the president of HSTS that provides high school students and adults with coding and technology training. He also is running 3 community Meetup groups (Coding and Technology Classes, JavaScript DC and Coding Bootcamps) with 4,400 members in Washington DC metro areas. Through our live events and training services, we teach students how to build and manage API applications such as RESTful APIs and along the way we promote best practices for API design, development and maintenance.

HSTS also collaborates with its Coding Bootcamps to offer more self-paced training related to API tools and frameworks. Likewise, HSTS has partnered with DC Web Makers in building and implementing API solutions especially related to blockchain applications. Specifically, majority of blockchain data are stored off-the-chain where a secure and scalable open API is used for connecting and exchange data from on-the-chain network to the off-the-chain database. In short, in production of a blockchain application, developers need to design and develop several APIs, most of which fall under OpenAPIs projects.

Through training and hands-on implementations of APIs, HSTS is planning to work on API specifications to design, prototype, and document the API lifecycle.

One of key barriers for API adoption is the lack of proper training as many small companies lack skilled professionals in planning, designing and developing their API applications. Likewise, API economy needs skilled people from all parts of the organization to collaborate. We believe with the advent of emerging technologies like blockchain and Artificial Intelligence, the well-made standardized – truly Open APIs will play a vital role in the IT operation and management of companies. Indeed, the more companies pursue automation best practices, the more they value the importance of API. As such, to achieve this, companies need to provide their IT team with latest training on design and development methods, and standards intended for APIs. This is how great APIs are built! In our journey of providing community with API training and best practices, we write and publish many hands-on guides (articles and tutorials) on our sites. To learn more about our training services, visit https://myhsts.org/

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

Feb 09

Love0

Vonage Joins OpenAPI Initiative

By OpenAPI Initiative Announcement, Blog

Press release from Vonage

Vonage, a global leader in cloud communications helping businesses accelerate their digital transformation, announced today that it has joined the OpenAPI Initiative, a consortium of forward-looking industry experts focused on creating, evolving and promoting the OpenAPI Specification (OAS).

OAS is a vendor-neutral and open description format for RESTful API, allowing both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

OpenAPI is an important standard for the wider API community and is adopted by most of the API service providers that help drive the sector. As a part of its OpenAPI membership, Vonage representatives will also join the Open API Business Governance Board and Technical Steering Committee to represent the Company in the meetings that decide both the direction and the detail of the OpenAPI standard.

“At Vonage, we share OpenAPI’s philosophy that technology should be easy to use and open for all,” said Roland Selmer SVP Product Management for Vonage. “We are thrilled to join OpenAPI, a community that is critical to our developer network and that will be a tremendous resource to us as we focus on the future of our API roadmap and our commitment to accelerating the world’s ability to connect.”

With an ever-growing network of more than one million registered developers, the Vonage API Platform is fully programmable, allowing businesses to integrate Video, Voice, Chat, Messaging and Verification into their existing products, workflows and systems – with just a few lines of code and no need for onsite developers or expertise. The Vonage developer community tears down the barriers to entry so that any developer can reach a global audience from day one.

“Standards are critical for helping industries scale. The OpenAPI Specification has emerged as a useful tool for describing modern APIs. Having Vonage join the OpenAPI Initiative will help our diverse membership evolve this important standard,” said Marsh Gardiner, Marketing Group Chair at the OpenAPI Initiative and Product Manager at Google Cloud.

Built using Vonage APIs, the Vonage Communications Platform provides next generation communications that are more flexible, intelligent and personal, empowering businesses to do what is next and stay ahead.

About Vonage

Vonage, (Nasdaq:VG) a global cloud communications leader, helps businesses accelerate their digital transformation. Vonage’s Communications Platform is fully programmable and allows for the integration of Video, Voice, Chat, Messaging and Verification into existing products, workflows and systems. Vonage’s fully programmable unified communications and contact center applications are built from the Vonage platform and enable companies to transform how they communicate and operate from the office or anywhere, providing enormous flexibility and ensuring business continuity.

Vonage Holdings Corp. is headquartered in New Jersey, with offices throughout the United States, Europe, Israel, Australia and Asia. To follow Vonage on Twitter, please visit twitter.com/vonage. To become a fan on Facebook, go to facebook.com/vonage. To subscribe on YouTube, visit youtube.com/vonage.

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.