The 2022 API Platform Landscape: Trends and Challenges

Abhinav Asthana

June 16, 2022· 8 mins

Last year, I published our view of how API management needs to evolve beyond its roots. This change is necessitated by APIs moving from being connective glue to being the primary building blocks of modern software. We also defined the key components of the new age of API platforms in our API platform landscape. Our intent was to describe how the many different pieces of technology and tooling fit together to help organizations deliver on the API-first model of software development.

Soon after I hit publish, we had feedback streaming in. Many vendors pinged us about what we missed out on (we updated the landscape immediately!). We also saw several hundred comments and thousands of likes and re-shares. We then saw customers using the landscape to map out their own API strategy.

Of course, the API platform landscape continues to change rapidly. We have been conducting hundreds of conversations with developers in high-growth organizations, enterprise architects driving change in the large Fortune 500s, leaders driving the API-first vision in their companies, and CTOs and CIOs who are eventually responsible for driving value for their organizations through technology.

Through these conversations, we continue to learn a lot. Today, I want to share some of these key learnings with you, along with a 2022 update on the API platform landscape.

Industry-wide trends

1. Companies are moving towards API-first. Almost every customer we talk to expresses enthusiasm about API-first and a realization that moving towards building better APIs is an organizational need. However, there are a lot of differences in what API-first means from company to company and between leaders and developers. Some leaders think that they have public APIs and hence they are API-first. Some developers think API-first is just ensuring that a specification file exists. Despite these gaps, most companies understand what APIs are and how they are critical to their organization’s future success.
2. Multi-cloud and hybrid architectures. Most companies have adopted the cloud. In fact, depending on the size of the company, they might have multiple cloud vendors servicing their needs, and the largest companies are moving towards abstracting their existing infrastructure through APIs—just like the way AWS was born out of Amazon. Multiple clouds along with private clouds help companies get cost structures right and optimize their workloads for the right needs.
3. APIs as products. APIs are not one-shot projects. Companies are recognizing that APIs are key building blocks that need to be maintained and improved. As a result, they are building teams to support this new mindset. Kroger is a great example of a company that has successfully embraced this and has opened up multiple APIs as products. As we see this change happening across the industry, we also noticed several failed initiatives around external APIs where the API product was realized primarily by putting a gateway in front of a data source without any focus on developer experience. Putting a gateway to build an API product is like building a hotel by focusing primarily on the entrance. Can you imagine going into a hotel where the bed is creaky and it takes hours to reach room service? Unfortunately, most older API products look like this, but we are glad to see this changing quickly.
4. Explosion of API gateways and service meshes. As I mentioned in the last post, gateways—the old lens through which architects look at APIs—will have to change. There are many different kinds of APIs, and they have different infrastructure needs. We’ve seen an explosion in the open source world and among gateway vendors to adapt to this reality. Not only are there more options for developers to choose from, but gateways are also becoming programmable through APIs like the rest of cloud infrastructure. Envoy, Tyk, and Solo have all launched new offerings.
5. More protocols and more choices for developers. We see gRPC and GraphQL emerging as complementary standards to REST. While REST and HTTP-based services continue to dominate, we are witnessing the rise of gRPC for internal microservices and GraphQL for stitching together disparate data sources. For asynchronous communication, we see WebSockets continuing to gain traction. Postman recently launched support for gRPC, GraphQL, and WebSockets.
6. Shifting left on security. API security has emerged as a hot new trend. I believe that vendors overhype security fears, and that the current state is a reflection of the “catch-up” that companies have to do now that they realize that the one public API they believed they had to protect is not the only API they need to think about. We believe a shift-left approach on security is the more impactful, developer-aligned approach that companies should be investing in for their APIs. It should be coupled with an investment in runtime infrastructure like gateways and firewalls—but just having controls at the infrastructure layer is not enough.

Challenges that companies are facing

1. Business and organizational alignment. For internal APIs, we see companies early in their API-first journey struggle with clear alignment and spend a lot of time getting developers to align. For partner and public APIs, the road is clearer. However, businesses and technology leaders are learning to speak to each other.
2. Centralized API docs continue to be a challenge. There is a wide gulf between the expectations of developers as consumers and their time investment as producers of APIs. As APIs become artifacts that need to have a good experience, developers need to maintain up-to-date docs and guides. In our State of the API Report, this was often cited as the most important need. However, engineering leaders and developers themselves don’t invest the time necessary, and they instead rely on tribal knowledge within the company when they are building software.
3. Poorly maintained service or API catalogs. Tied to the previous issue, service catalogs are often out of date. Most homegrown systems for these catalogs are not integrated with the developer lifecycle or sometimes even with any other engineering systems. These are literally static pages or wikis or even spreadsheets.
4. API-design skills gap. While the best-of-breed companies race ahead and have started winning developer mindshare, most companies are struggling with getting API design right. Having everyone read through hundreds or thousands of lines of code is a rite of passage at most development organizations. However, development teams used to operating in this mode aren’t considering the user experience needs of API consumers. Also, we were surprised to see the API-design skills gap also existing in companies with decent public APIs. While companies had entire teams staffed for public APIs, internal APIs were left on their own. The good news is that both leaders and engineers are aware of this. We are doing our part through our Open Technologies program, content produced by our developer advocates, and through our Student Programs. Arnaud Lauret, who joined us at Postman as our OpenAPI technical lead, recently published a book on API design that I highly recommend reading!
5. Too many microservices. Didn’t we just start with microservices? Well, we see engineering leaders struggle with too many of them now. Lack of discipline in API design has led to a proliferation of hundreds of services in small teams. Some teams have 2:1 or 3:1 services per developer! This means there is no reusability and often developer resources are spread too thin towards maintenance of services that should be wrapped up in APIs and shared among others.
6. Developer onboarding, hiring, and attrition. In a tight labor market, companies are already struggling with hiring and retention. When developers move from one job to another in a hot job market, they leave with valuable domain knowledge. The lack of an API platform leaves engineering teams having to re-discover their own competencies that they spent significant effort and investment in building. Developers leave companies when they feel they are unproductive. Companies like PayPal and Amadeus that prioritize the time to first call and look at developer experience as a whole will be able to hire and retain talent much better than others. We see more than half a million organizations on the planet, and demand for developers is not slowing down any time soon. Hiring developers, onboarding them to become productive, and retaining them continues to be a challenge for organizations lagging in their API-first journey.

Emerging organizational roles and their mandates

As we move towards an API-first world, we’re seeing new roles emerging inside organizations while existing roles are changing to meet organizational needs.

• CIO (Chief Information Officer): CIOs are now tasked with quality and reliability engineering on top of IT needs for always-on, 24/7 services. CIOs are also modernizing IT practices in their own functions using APIs.
• CISO (Chief Information Security Officer/Head of Security): CISOs have always cared a lot about APIs, but now they have to ensure that APIs are tracked actively and are not being used in ways they are not designed to be used. APIs are critical to the business, which means there is more potential for security and business risk. CISOs have to adapt to the new ways in which APIs are developed and operated. Along with tracking APIs, CISOs are looking at ways to modernize their own security stack using APIs.
• Head of API Platform: We see a new role emerging. A head of API platform manages the API landscape for a company. We see this more prominent in the partner and public API world, but it is expanding to internal APIs too.
• Head of Developer Experience: Another important role that is emerging in organizations that care about developers, a head of developer experience manages the end-to-end developer experience from onboarding to retention. They ensure that the right tools and the right workflows are present for developers.
• API Product Manager: A new role of the API product manager has emerged. API product managers bring together a technical skillset, business acumen, and product design. An API product manager handles user requirements, translates them into a roadmap, builds API prototypes, and ensures that the APIs they are managing achieve success. Sometimes this responsibility is handed over to engineering managers or technical leads, especially for private APIs.

The 2022 updated API platform landscape

Along with all of the new trends and roles, we’re also seeing new vendors entering the landscape. Here is an updated version of today’s API platform landscape:

Download the 2022 API Platform Landscape diagram here 

I am excited to see the continued evolution of the landscape, and, of course, we will keep improving the Postman API Platform with new updates every month. There are so many more exciting things on the horizon as we learn from more than 20 million people who use Postman around the world today.