I find myself on this quest at regular intervals throughout the last decade-—seeking to define what the API lifecycle means. However, this time I am determined to ground myself in a vocabulary and set of visualizations that ground me an my storytelling around the API lifecycle, helping me be more coherent and precise when I talk about delivering APIs. Over the last decade I have worked to define what I would consider over a hundred stops along a lifecycle, but in 2021 I am looking to distill that down into the most meaningful, impactful, and wide reaching approach to describing what the API lifecycle is. To help me stabilizing my storytelling I’ve established this baseline API lifecycle definition.
Publisher Lifecycle
The first part of the API lifecycle definition is all about the publisher, something I have historically called deployment, but I think publisher provides a cleaner representation of what is happening-defined in a way that makes it inclusive to non-developers, helping make the API lifecycle more accessible to business groups.
- Design - A diverse API toolbox and full lifecycle approach to API design.
- Mock - Utilizing a mock representation of a service to drive an API-first approacht to brginning the lifecycle.
- Document - Ensuring there is always up to date, meaningful, and living documentation present for APIs.
- Test - Providing 100% test coverage for APIs when it comes to contract, integration, performance, and security.
- Publish - The act of bringing an API to life via using a gateway or artisinally hand turned on a lathe.
- Manage - Managing onboarding, authentication, authorization, rate limiting, logging, reporting, and quantifying value exchange.
- Monitor - Monitoring, automating, and orchestrating acorss API operations on a schedule from many different cloud regions.
- Discover - Ensuring that APIs are discoverable by default, and every API detail is gathered in transit and centralized in real-time.
- Collaborate - Ensuring all stakeholders are part of the process, and a feedback loop is present across all APIs.
This vocabulary is intentionally using words that are common across the API lifecycle. I went for softer, wider reaching, and inclusive terms, but still stuck with the vocabulary you see on the “streets”. Similar to why I chose the word publish, all of these words will resonate with non-developers, making conversations and stories more inclusive. You notice I did not use the word development anywhere in here, and my list also has the important human aspect of collaboration.
Consumer Lifecycle
Next, I wanted to make sure and show the consumer side of the API lifecycle, pushing anyone I am talking to or who is reading my stories to think about the other side of the coin. I am looking for this side of the lifecycle to speak to both publisher and consumer, helping force publishers out of their siloed, and pull back the curtain a little bit when it comes to API consumers relationship with API publishers. Here is what I have outline when it comes to describing the consumer side of the API lifecycle.
- Discover - Ensuring developers can easily find what they are looking for, while regularly being introduced to the latest APIs.
- Onboard - Reducing as much friction as possible when it comes to a develop finding an API, learning about what it does, and being able to integrate with it.
- Integrate - The actual integration of an API into applications and integrations by developers and non-dev\elopers alike.
- Feedback - Offering easy, direct, and in-direct ways for consumers to provide feedback on each API they are putting to use.
- Support - Making sure consumers have the self-service, direct, and even paid support options when it comes to finding the help they need.
I wanted to make sure the feedback loop was present as part of this side of the lifecycle. I think that developers often don’t feel like they have an obligation to engage with API publishers, and I wanted to make sure that they are aware of how critical their feedback is to the lifecycle, and that they are a collaborator on the publisher side of the API lifecycle. And again, I wanted to make sure the consumer side of things was accessible to non-developers, because in a low-code / no-code world, everyone should be an API consumer. For this API lifecycle definition to properly ground the conversations I am having and take things into the future, I need everyone on-board, and that means everyone is part of the conversation.
Next, am going to publish this in a Postman public workspace as a simple static API, and apply a version to this definition. I am looking to be extremely deliberate in how I evolve this definition this round. For this first version I want to start simple, but adequately describe the entire API lifecycle. I will be adding new stops along these lifecycles, and I anticipate some other groups beyond just publisher and consumer. However, I am determined to establish the most meaningful vocabulary as I can for my storytelling and conversations, helping me stablize the ground under my feet a little bit.
