Apr 27

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

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.

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

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.

Dec 14

Love0

Band Protocol Becomes First Blockchain Firm To Join OpenAPI Initiative

By Open API Initiative Announcement, Blog

Press Release from Band Protocol:

Bangkok – 14 Dec 2020: Sequoia-backed cross-chain data oracle Band Protocol, has joined the OpenAPI Initiative as the first blockchain firm alongside Google, eBay and Microsoft, to connect blockchain applications to common Application Programming Interfaces (API) and streamline the exchange of data between smart contracts and off-chain data sources.

“Our mission is to define a common API standard for blockchain applications by collaborating with prestigious partners to bridge the gap between centralized data, APIs and smart contracts on the blockchain,” said Soravis Srinawakoon, CEO and Co-Founder of Band Protocol.

An API is a software intermediary that makes it possible for two applications to share information easily and efficiently to enhance accessibility and user experience.

By creating a common API standard, Band Protocol will allow blockchain applications to easily leverage off-chain APIs and data to better engage with centralized data sources and the wider technology community, enabling expansive use cases of smart contracts.

This is an important step towards creating decentralized applications and smart contracts that are able to reliably and securely interact with traditional centralized technology and APIs and with each other.

“The OpenAPI Initiative standardizes how the industry describes and documents APIs. We are thrilled to welcome Band Protocol as the first blockchain-based member to join the initiative,” said Marsh Gardiner, Marketing Group Chair at the OpenAPI Initiative and Product Manager at Google Cloud.

The OpenAPI Initiative is a non profit foundation hosted at the Linux Foundation whose members include prominent organizations such as Google, IBM, Bloomberg, Microsoft, SAP and Oracle, among others.

The initiative works to define common standard APIs to be used across different industries with Band Protocol becoming the first blockchain company to contribute to the initiative’s collaborative specifications.

For more information on Band Protocol, please visit: https://bandprotocol.com/

About Band Protocol

Band Protocol is a cross-chain data oracle platform that aggregates and connects real-world data and APIs to smart contracts. Backed by Sequoia Capital and the leading cryptocurrency exchange, Binance, Band Protocol enables smart contract applications such as DeFi, prediction markets, and games to be built on-chain without relying on the single point of failure of a centralized oracle. For more information, please visit: www.bandprotocol.com

About 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. For more information, please visit: www.openapis.org

Oct 21

Love0

OpenAPI Welcomes New Member Osaango

By OpenAPI Initiative Announcement, Blog

Why did Osaango join the OpenAPI Initiative?

Marjukka Niinioja is the founding partner at Osaango, with over 10 years of experience with APIs. She and her team also organize apidays Helsinki and APIOps community. She explains: “We see OpenAPI specification as being both the problem and the solution. For many people, the design of API using the specification is just a technical task with the least effort put into it. For many more, the specification just doesn’t exist on their radar.”

“Of course, there are also issues like tooling support that stop people from using it. Yet, we feel that the biggest issue is lack of knowledge, especially about the productization of APIs as well as API management. Both are interlinked and both benefit from using the specification,” she adds.

“Skilled people + Good method = Great APIs”

Osaango has promoted open standards from its beginning. Marjukka Niinioja is the “mother” of APIOps Cycles method. The method is the only openly licensed, Lean, and business-oriented method for developing APIs, and the full lifecycle. The method both promotes and depends on using API specifications to design, prototype, and document the API as part of the lifecycle. It promotes “APIOps,” the automated and transparent culture of building APIs. At its core APIops is like DevOps. The APIOps Cycles method extends APIOps. It includes also elements from product management, business design, and developer experience.

The method has been adopted in organizations around the world, from Finland to Argentina. As one user from Argentina put it: “We’re starting to build an API product, and discovering APIOps Cycles was fantastic because it helped us translate Lean Startup’s ideas into our world!”

Together with partners and active community members, Osaango drives the open APIOps community with meetups and other activities to promote best practices. Osaango’s vision is to help make the API economy as known as a business model as the Software-as-a-Service, SaaS. But great APIs and great API Economy doesn’t happen by accident. For Osaango, API stands for “All People are Important,” not only application programming interface. API economy needs skilled people from all parts of the organization to collaborate. They need to understand the business benefits of having APIs. Not just any APIs but good, well-made standardized – truly Open APIs. This in turn requires design and development methods, and standards intended for APIs. This is how great APIs are built!

Osaango is committed as an OpenAPI Initiative member to help lower the barriers of using the OpenAPI specification. Some of the first tasks for Osaango to take part in has been to:

Tackle the usability and accessibility of the OpenAPI documentation created by the initiative
Collect questions from the community about the various API specifications to be answered and documented to promote awareness and learning.

Learn more about the openly licensed method for API Development: https://www.apiopscycles.com

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

Aug 18

Love0

OpenAPI Welcomes New Member APImetrics!

By OpenAPI Initiative Announcement, Blog

Welcome!

APImetrics provides an enterprise focused API monitoring solution that interfaces with REST and SOAP API protocols. Monitoring is supported by analytics and customizable downtime alerts and provides data to enterprises to meet service level agreements (SLAs) and customer expectations.

“The economy has increasingly become a digital economy and the digital economy has been increasingly becoming an API economy over the past decade,” said said Dr. Paul Cray, Head of Machine Learning and Standards at APImetrics. “The COVID-19 crisis has only accelerated that trend. Global quality standards that are meaningful, quantifiable and measurable are essential to maximizing the value that API creators and users provide across many industries. That’s why the OpenAPI Initiative and APImetrics are such a perfect fit, and I am looking forward to working with OAI on these standards.”

APImetrics is particularly interested in working with OAI around standards that can help with the definition and measurement of Service Level Objectives as well as issues around certification, compliance, conformance and continuous testing and monitoring of APIs.

“APImetrics is a welcome addition to the OpenAPI Initiative,” said Marsh Gardiner, Product Manager, Google Cloud, and Technical Steering Committee member, OpenAPI Initiative. “When the industry works together to address common API description challenges, such as describing SLOs and SLAs, everybody wins.”

OpenAPI Resources

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

Join us for ASC 2020

About the OpenAPI Initiative

About Linux Foundation

Jul 23

Love0

Postman Joins the OAI to Support the OpenAPI Specification

By kinlane Announcement, Blog

This blog post was contributed by Kin Lane, Chief Evangelist, Postman

When Postman launched its API builder last year, we were amazed to see how popular OpenAPI was with our users, when it came to designing and developing APIs. Our usage stats helped us realize just how important the OpenAPI Specification is to how our customers design and build their APIs. Today Postman is joining the OpenAPI Initiative in order to work with the 35 other OAI members to steer the specification forward. Together we will hope to continue to support open source tooling that builds on the specification and to grow a stronger OpenAPI community so as to ensure the future of this important industry standard.

Historically, Postman collections were how API providers defined their APIs on the platform. With the introduction of the API builder, more API providers began using OpenAPI as the central definition of each API being developed. Over the years, Postman collections have evolved to allow developers to test, mock, document, and automate parts of the API lifecycle. Along with this evolution, each collection can be generated from an OpenAPI, pushing us to deliver a growing number of specific capabilities that help our customers leverage OpenAPI as the API contract for use across their API operations:

Import – You can import an OpenAPI document into the Postman and maintain it as the central contract for each individual API, which is used to validate and notify developers when documentation, collections, or tests are out of sync with the OpenAPI contract.
Generate – You can generate Postman collections from your OpenAPI definition, establishing derivatives of your API contracts for use in documenting, mocking, and testing your APIs in an ongoing fashion across regions.
Validate – Every collection generated from an OpenAPI specification can be validated across the OpenAPI contract, helping keep documentation, mock servers, and testing infrastructure in alignment across operations.
GitHub sync – When you are managing your OpenAPI document in Postman using the API Builder, you can sync it to GitHub, allowing it to be used in other systems, allowing changes to occur in Postman or via other tools.

OpenAPI has become part of the API factory floor for Postman customers. Beyond what a spec describes, Postman makes it easier to work with APIs by allowing you to store tokens or keys for multiple profiles or lifecycle stages and to augment with specific values for running tests or for monitoring. The OpenAPI Specification provides a way to define what is possible with HTTP APIs, with Postman collections emerging as a way to define, execute, and automate each stop along that APIs lifecycle. A stronger relationship between OpenAPI and Postman has helped our customers, and we’re thrilled to be joining the conversation about what the OpenAPI roadmap might be, and to help realize the full benefits of using OpenAPI across the API lifecycle.