The New Postman API Platform: Redefining API Management for the API-First World

Today’s consumers need great software. Consumers demand experiences that span multiple devices, they expect their data to be instantly available, and they expect everything to work around the clock. There are billions of software consumers today and there will be many billions more in the future.

To meet this demand, the world of software development has undergone a radical change in the last decade. Infrastructure is readily available on the cloud without having to buy and provision hardware. Millions of repositories of open source code are available in dozens of languages that can be used to build applications of any nature. The DevOps movement has brought automation to the process of integration of code and deployment of software to the cloud at rapid rates. This is still not enough.

Why? Building software is hard! First, no single company, team, or engineer can build every piece of functionality themselves. And secondly, combining code into a monolithic application architecture does not scale: you can only fit so many bits in a single computer and run and deploy them efficiently. Most monolithic applications very quickly become distributed monoliths where the same application is deployed multiple times with some configuration to manage which state runs where. Not to mention the constant risk the architecture runs into integrating disparate parts and testing them for quality and security.

How can we solve these challenges? Enter APIs.

APIs allow pieces of code to bridge together applications so they can work cohesively together.

APIs can take many shapes, like internal microservices, data APIs, cloud services, integration components, SaaS services, and frontend APIs. APIs can be internal to an organization (private APIs) or external (partner APIs or public APIs). While public APIs are available to all developers, partner APIs are typically available to a subset of them through contractual partnerships. What they all share in common is that they enable compute or data functionality over the network.

APIs are the building blocks of all modern software.

At Postman, our vision is to build The API-First World. What does this mean for API Management?

What is API Management?

API Management arose as a category in the last decade, slightly before the rapid growth of the cloud, in what we call the “code-first world.” In the code-first world, developers are focused on building applications by primarily writing code and optimizing the process from lines of code to bits deployed on a server.

Vendors—most notably Apigee, and later, Mulesoft—understood that many organizations would like to extend their value propositions through public APIs just like Salesforce, Google, or Facebook had done.

Many organizations built monolithic applications with a ton of data sitting around waiting to be harnessed by internal and external developers. To use this data and maybe offer some external services, organizations deployed gateways provided by vendors with developer portals (i.e., websites built on a CMS) to help developers register their APIs. This led to the first wave of public APIs.

The second wave was led by the rise of SaaS applications. The software delivery model itself shifted from delivering application bits in packaged form to delivering software over the cloud through the software-as-a-service model. Now all these applications need APIs to integrate with each other for business-focused workflows.

Public APIs and integration needs have forced organizations to build APIs, but due to the lack of tooling and strategy around APIs, most organizations weren’t able to leverage the full power of APIs.

Gateways did function as a starting point for companies to factor APIs into their software strategy, but those gateways didn’t help them succeed with the true power of APIs.

Partner APIs were often not supported in these offerings, and the explosion of private APIs (e.g., microservices, serverless, internal apps) meant that almost 70-90% of APIs were missing from the API landscape that leaders thought they had.

Finally, end users (developers, testers, product managers, and several other functions) didn’t have any tooling support from API Management vendors. With application development shifting to an API-first mindset, engineering organizations have learned that they need tooling, enablement, and processes to build and deliver great APIs.

API Management vendors don’t treat APIs as the building blocks of modern software.

API-first superpowers

From a central vantage point in the industry, Postman has seen the rise of API-first companies—API-first companies use APIs as the building blocks of their software strategy.

API-first development is a development model in which applications are conceptualized and built as an interconnection of internal and external services through APIs.

API-first companies have superpowers:

• API-first companies choose technologies that are right for their goals. This includes gateways, protocols, languages, and runtimes.
• API-first companies have a place for discovery for their most important digital building block: their APIs.
• API-first companies have a standardized process for building APIs that meet their guidelines and provide a great developer experience for end users.
• API-first companies understand the complete landscape of their private, partner, and public integration points.
• API-first companies have an ecosystem of partners and third-party developers to continuously add more value to their offering.
• API-first companies understand and control their data to meet regulatory challenges.
• API-first companies understand their API perimeter to prevent malicious actors from using APIs in a malicious way.

Becoming API-first requires an evolution of your software development pipeline all the way to production and your interactions with consumers.

Introducing the next-generation API Platforms

At Postman, we believe that the transition from code-first to API-first is a significant technology shift happening in every company today. Companies that don’t make this transition will be relegated to being niche players in their businesses, and new kinds of businesses will emerge in this decade to take their place. To succeed in the API-first world, engineering organizations need a new category of solutions: API Platforms.

API Platforms are software systems with integrated tools and processes that allow producers and consumers to effectively build, manage, publish, and consume APIs.

These platforms have the following components:

#1: Tools for the entire API lifecycle

1. API client: A developer tool to send API calls during debugging or API consumption.
2. API designing and mocking: API design and mocking capabilities help developers and architects define and test the expected behavior of an API before investing time in coding.
3. API testing and automation: Testing of the API through a variety of ways—including manual, automated, functional/behavioral, contract, performance, security, and others—to ensure that the API behaves as per requirements after the coding phase. Testing can be done manually or it can be automated as part of a regular build process.
4. API documentation: Reference guides, how-to documentation, recipes, and other means of communication about how an API works.
5. API monitoring: Operational monitoring of an API to ensure that it is behaving as desired and alerting when things go wrong.

#2: Collaboration capabilities for producers and consumers

1. API workspaces: Collaboration on API-related workflows during development, testing, documentation, operations, support, and sales-related workflows. API collaboration tools notify stakeholders about changes and help multiple participants to work together. API collaboration can be between producers, between consumers, or between producers and consumers.
2. API catalog: A central place for APIs for private, partner, and public APIs. The catalog contains up-to-date information about the API and related artifacts so producers and consumers can find the right APIs.

#3 Governance capabilities for operations, architecture, and security teams

1. API security: Preventing unauthorized and malicious access and use of APIs through checks during development time, testing, and production. Discovery of previously undocumented APIs through scanning applications, infrastructure, or any other artifact.
2. API observability: Measurement of API traffic through sampling or aggregating data for use by developers, ops, or product managers.

#4 Integrations with the SDLC

These capabilities need to be integrated with the key components that an organization has:

1. Source code management
2. CI/CD
3. Cloud/on-prem infrastructure (this is where gateways fit in today)
4. Application performance management

An API platform helps organizations manage the entire API lifecycle from design to production while also bringing the most critical constituents—the API consumers—into the API landscape. Not only does the platform help with a single API but it helps govern the entire API landscape. An API platform in this form is a core system that an organization should deploy to ensure success with APIs.

The Postman API Platform launch

We are excited about today’s platform launch. We believe that it is the best version of Postman so far in an integrated way that is loved by millions around the world. Ankit, Postman’s co-founder and CTO, talks about the new platform capabilities in his blog post here. While we don’t do everything in the API Platforms category yet, we believe we have the best-in-class integrated experience that scales from individual developers to organizations with thousands of people working together.

Postman is already deployed at scale at organizations like Kroger, PayPal, Cvent, and many other API-first organizations, and we’re excited about bringing the API-first mindset to many more.

What’s next for API Platforms

We see that a lot of organizations (outside of the ones who have adopted Postman) are building homegrown solutions through expensive developer resources.

Along with homegrown solutions, there are many different vendors in a dynamically evolving landscape. Lately, we have seen API security vendors like Salt.security and Noname get funded and new companies like Akita and Moesif emerge. Some vendors like Stoplight and Apollo are focusing only on one specification. We have also seen API catalogs and the emergence of open source solutions like Backstage.

So, what happens to gateways? Gateways were a core component of the last decade of the API Management category. We believe gateways are an important infrastructure piece and we will see the emergence of new kinds of gateways. The last few years have already seen new models on the backs of containers led by Kubernetes, serverless functions, and service meshes—almost all of it open source. The challenge with gateway vendors when they do service other parts of the API-first workflow like API catalogs or API clients is this: they only integrate with that specific gateway. Unfortunately, organizations deploy many kinds of gateways depending on the use case each gateway fulfills best.

Here is our view of the landscape today:

Download the API Platform Landscape diagram here (updated October 21, 2021)

We are excited about leading the conversation around APIs. If you have any thoughts, comments, or questions, feel free to leave them below or write to us at [email protected] or tweet to us at @getpostman or @a85.