Choosing to be API-first approach can dramatically increase the productivity of your development team, ensuring high levels of quality across all of the APIs produced and building your operations on a solid API platform. When you shift towards an API-first approach in your business, you will be able to better handle the stability and reliability of your API ecosystem, increasing awareness through greater observability across what is happening in real time.
But the reasons for becoming an API-first company aren’t just technical. Find below the main trends of the industry and the challenges that the API-first approach can help addressing.
- Multi-cloud and hybrid architecture – Multiple clouds along with private clouds help companies get cost structures right and optimize their workloads for the right needs.
- APIs as product – 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.
- Explosion of API gateways and service meshes-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.
- 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.
- Shifting left on security – API security has emerged as a hot new trend. 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.
- Business and organizational alignment – For internal APIs, most 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.
- Centralized API docs continue to be a challenge – As APIs become artifacts that need to have a good experience, developers need to maintain up-to-date docs and guides. 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.
- 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.
- API-design skills gap – While companies had entire teams staffed for public APIs, internal APIs were left on their own.
- Too many microservices – 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.
- Developers onboarding, hiring and attrition – 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. 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.
