Postman Joins the OpenAPI Initiative
We’re proud to announce that Postman has joined the OpenAPI Initiative (OAI) to participate in the education, marketing, and evolution of the OpenAPI Specification (OAS). As a member alongside 35 other tech companies, we are excited to help provide a common vocabulary for defining what is possible with each API behind the applications the world depends on.
Postman believes in the value that the OAS has brought to the industry, and we want to help push the specification forward, making sure it provides as much value to the API community as possible. As an OAI member, we can now be more active in our support for the OAI, the OpenAPI Specification, and the community at large.
Why the OpenAPI Specification matters to the API industry
The OpenAPI Specification empowers the API community with a common, machine-readable way of defining the surface area of any API that uses the HTTP 1.1 protocol as a transport. It provides a common set of objects for defining the technical details of each request and response of the APIs we develop. API developers can now better describe what is possible with their APIs in a format that allows them to easily share and collaborate with others, and import into other tools and services, by leveraging a common definition to move each API forward along its individual lifecycle.
The specification gives API providers a shared language to use when developing APIs across teams. This shared language can also be used to engage with API consumers, while also standardizing how services and tooling are put to work across the API lifecycle. OAS has become central to how enterprise organizations are delivering the critical infrastructure they are using behind the applications that move businesses forward.
Postman sees OAS as a contract for the API lifecycle
Since the release of Postman’s API Builder earlier this year, developers have been able to define the central truth of their API using OAS in the Postman desktop and web applications, as well as via the Postman API. Since then, Postman has been working hard to add new features that empower API developers to leverage the OpenAPI spec when publishing documentation, deploying mock API servers, and testing API contracts, integrations, performance, security, and other common stops along a modern API lifecycle.
Within API Builder, developers can generate Postman Collections from an OAS contract. They can designate each collection’s purpose along a consistent lifecycle, and then validate and maintain the integrity of their collections behind docs, mocks, and tests—reconciling any differences that exist between the central truth of each API (the OpenAPI spec) and the specific stops along the API lifecycle being served.
Moving the community from Swagger 2.0 to OAS 3.0
Since we launched API Builder, we’ve noticed that many of our customers are still utilizing Swagger 2.0 as the central truth for their API, which means they’re missing out on the full benefits that OpenAPI Specification 3.0 brings to the process. So we want to help advance the conversation around the specification within the API community, and make it easier for Postman customers to shift from Swagger 2.0 to OAS 3.0. We also want to help strengthen the services and tooling that have emerged around OAS 3.0.
The more API providers and consumers move from Swagger 2.0 to OAS 3.0, the more benefits there are for everyone and their APIs that are being designed using the format. To successfully make this move on a community-wide scale, there’s one element that is absolutely crucial: proper tooling.
Investing in the open source tooling built around OAS
The OpenAPI Specification is only as strong as the service and tooling that are built upon it. The success of Swagger 2.0 was largely defined by the open source tooling that was available to publish docs and mocks, and service other stops along the API lifecycle. The same is proving true when it comes to the utility and value of OAS 3.0, and Postman believes that this value is defined not only by commercial services developed using the OAS, but also by the open source tooling that uses OAS as an API specification format. That’s why Postman maintains an open source converter for turning OAS into Postman Collections, as well as other open source tools.
We recognize that a diverse assortment of open source tools is necessary to provide many of the capabilities the community needs, and that it’s essential for us to empower Postman partners. We can do this by helping to ensure we all use a common vocabulary to define our APIs, and that everyone has access to open source tooling that services stops along the API lifecycle that Postman doesn’t serve. Our joining of the OAI is not just about the specification; it’s also about supporting the variety of open source tool developers who have emerged as part of the community.
Helping define what the future of OAS looks like together
Postman just attended our first quarterly OAI meeting, learning about the new 3.1 release—and what is being planned for 3.2. We’re already diving in to help spread the word about the upcoming API Specifications Conference (ASC) in September, supporting education efforts around the specification, and learning more about how we can amplify the OpenAPI Specification story and discussions.
We have a lot of ideas to share when it comes to the future of APIs, and we look forward to using our platform to help make more developers aware of the benefits of using the much-anticipated OAS 3.2. But first, we want to make sure we spend time listening and understanding more about the hard work that has already been occurring within the OAI organization. Then we will also work to nurture future discussions—making sure the OpenAPI Specification continues to meet the needs of our 11 million customers, as well as the rest of the API community and the increasingly influential API economy.
Exciting to hear that Postman has joined OAI to futher influence the “evolution” of OAS!