API series - Postman: 7-habits of effective API-first orgs
This is a guest post for the Computer Weekly Developer Network written by Kin Lane in his role as chief evangelist at Postman, an API platform used by more than 20 million developers and 500,000 organisations for building and using APIs.
Lane writes as follows…
Airbnb. PayPal. Stripe. Uber. Amazon Web Services, Google Cloud and Microsoft Azure.
These are just a sample of the groundbreaking technology companies that would not exist without Application Programming Interfaces (APIs). These brands have built their businesses on the ubiquitous digital interfaces that enable different software applications to interact with one another.
But while APIs already have been powering much of the world around us, more and more large enterprises of all types are realising they can’t really be digital without an API-first philosophy.
What is an API-first company? It understands that delivering applications through a mix of internal and external services using APIs is critical to digital transformation – and it adopts a strategy and set of processes that treat APIs as the fundamental business assets they are.
The reasons for becoming an API-first company aren’t just technical, so interest in API-first among business leaders is soaring. This explains why not only developers but also product managers, security engineers, and customer support teams, among others, are now working with APIs.
Yet, despite all that interest and awareness, the topic is sometimes misunderstood. API-first can mean different things to different people. This can generate anxiety and confusion as organisations consider what qualifies as an API-first approach and how to proceed.
The question today isn’t so much whether companies are ‘doing’ APIs – they almost certainly are – but whether they’re doing them well.
So, what makes a successful API-first organisation? It boils down to possessing these seven essential traits.
#1 A comprehensive strategy
More companies across almost every business sector are recognising not just the value of connecting internal, partner and public APIs but the need to have a solid strategy for how contributors, consumers, and other stakeholders can interact with an API at different stages of its lifecycle, including planning, design, test, deployment, and versioning.
Each one of us makes thousands of API calls a day in the course of our personal and professional lives. But despite this, many organisations still lack a formal strategy for defining how APIs will be designed, developed, delivered and operated – and that is just for the APIs that the companies build – there are hundreds of other partner and third-party APIs they depend on that lack a strategy as well.
Amazing, right? Fact is, there is no way to remain competitive unless companies have a formal strategy for how APIs work across the organisation. That is the first step toward being API-first.
#2 A holistic view
For the past two decades, organisations have raced to stitch together a dizzying array of applications and systems for their operations, and now they’re increasingly developing their own web, mobile, and device applications on top of it all. All of these new applications rely on APIs, and that often leads to a redundant and chaotic mix of APIs.
Being API-first means prioritising all of the APIs behind applications and considering them as a whole, accounting for how they will be used across all applications, rather than just scrambling to deliver a single application that often leaves vulnerable and redundant APIs in their shadows.
#3 Attention to discovery & visibility
In a perfect world, every organisation publishes their APIs to an internal, partner, or public catalogue. In the real world, very few enterprise organisations even know where all of their APIs are.
Being API-first means that all APIs are prioritised and discoverable by default. This saves time and resources by eliminating redundancy and waste across companies’ vast expanse of APIs.
Without being API-first, companies simply won’t have the visibility across their operations to understand where consistency exists or doesn’t in the design of an API as well as the supporting documentation, testing, security, and monitoring of APIs.
#4 Commitment to quality
Postman’s Lane: 7-pointers for API appointment.
Lack of quality across its API ecosystem affects a company’s bottom line in two ways – through loss of business and through time spent troubleshooting, fixing, and responding to preventable incidents.
Being API-first raises the bar on the need for API quality. Teams must be equipped with the training and tooling they need to develop and apply modular testing across every API they produce or consume.
#5 Focus on strong security
Being API-first means that every API and microservices has security protection that is centrally defined by security experts and then also applied by developers as part of the regular API development lifecycle.
Even the simplest of APIs are put through the minimum security scanning and evaluation as they are being deployed or changed with each new version. Security is consistently applied across all APIs used by teams, no matter what the application is or how long the API will be used by consumers.
Companies need those practices if they are to feel confident in opening up access to their digital resources to partners and third-party developers.
#6 Strong internal processes
An API-first approach means establishing familiar and easily accessed workspaces where API work is centralised. They should contain artifacts, documentation, mock servers, environments, tests, monitors, history, and everything else new and existing team members need.
Repeatable processes are established in order to optimise the design, development, deployment, and operation of APIs and microservices. Rough edges of the API lifecycle are smoothed out across teams, which are equipped with the knowledge and tooling they need to consistently deliver and iterate upon APIs.
In an API-first organisation, these kinds of processes matter. They foster the teamwork needed to innovate.
7 – Reliance on open standards
Complex and non-standardised APIs require more resources to onboard and integrate with, resulting in friction throughout the life of an API. But use of common standards reduces the cognitive load needed to understand what an API does, and they increase the likelihood that there will be common open source libraries and tooling available when producing or consuming APIs.
Using standards as part of an API-first approach makes good business sense: It increases productivity, quality, and velocity across any API, catering to the widest possible number of consumers in each industry.
By modeling themselves after these seven characteristics, companies can make sure they’re on an API-first journey that drives the business forward, saves time and money, and, ultimately, spells the difference between remaining competitive or falling behind.
In today’s digital landscape, every organisation should seek to be API-first so they don’t end up API-last.