What is Your API Lifecycle?

I like asking questions on Twitter then leaving and coming back to see the great answers people leave. Sometimes I get crickets, but depending on how I phrase the question, and how people interpret my question, I might get a stream of interesting views of the world of APIs. I recently asked a simple question. What is your API lifecycle? This is one of the ubiquitous phrases that we use in the API space that has no concrete definition and means many different things to many different people. I was sitting on a call listening to a conversation, and figured I'd tweet and ask folks what their perspective was.

I really like Mike's view of the API lifecycle, but more importantly how he "codifies" his lifecycle. It isn't just about a linear set of stops along a lifecycle, and more about a healthy loop you can use to bring APIs to life.

Then Mike v2.0 chimes in with his honest and precise view of the landscape and how all of this truly works, introducing one of the most important stops along a modern API lifecycle--regret.

Then Mike v3.0 jumps in with a design heavy view of the lifecycle that occurs between human beings. Mike makes it more like having a conversation about what is needed, then quickly deprecating and deleting.

Then Frank demonstrates that emojis are an essential tool in all of our API toolbox. He also brings the wine/dine to the API lifecycle which I vote we make a required part of every API lifecycle.

Next Marc contributes very sobering test-driven view of the API lifecycle, acknowledging that there will be bugs and tears. I really like his contribution of the challenge stop along the API lifecycle, which should also be required for all APIs.

No API lifecycle conversation is complete without Mr. Reinbold being at the table, bring the letter D center stage. Helping provide an easy to remember and say approach to defining the API lifecycle, which has the potential to be stickier in people's minds.

Then Mike v1.0 tapped Mehdi on the shoulder, who jumped in with a nice separation based upon the maturitiy of the the process and APIs, providing us with another set of stops to consider as part of our API lifecycles.

Then Miqui chimed in to say that they were also using the same lifecycle as me.

Then there was this guy, who I worry is stuck in his iPhone, reminding us that we shouldn't version and that once you put forth a an API contract you will need to support until the day you die!!

Then Toby provides what feels like an extremely common pattern for what I am seeing across the enterprise, and reflects a very practical approach to doing APis.

Then Migo gets straight to the point, with what feels a little oversimplistic, but very inspirational view of how you do APIs.

Then King James steps up and shares a extremely balanced look at how and why we are doing APIs. Making it simple to understand, while also providing a book to help you understand how to do all of this.

Then Allen reveals a critical illness in how we describe stops along the API lifecycle as sweeping generalizations, which is one of the reasons it can be so hard for us to get on the same page about the API lifecycle.

Then Yonderwire reminds us to always do our homework and make sure our APIs are well planned and not just something we throw out into the universe.

Tom gets straight to the point, and adds another dimension to the every popular anxiety stop along the API lifecycle by introducing hair loss into the mix!

Then Jason concludes the thread with a pretty simpele but effective approach to describing the API lifecycle, while also reminding us to evangelize, while acknowledging it probably will also be the first thing to go as we find ourselves overworked.

A lot of personalities here. Some very interesting takes on what the API lifecycle can be. It gets me thinking about how diverse we play this API game. If I take the words used across all of these contributors I ended up with this tag cloud, showing what the top stops along the API lifecycle are for these folks.

I would really like to do more work to define what the API lifecycle is, or at least help establish a consistent way of defining different stops along an API lifecycle, and as a couple folks did as part of this thread, organize these stops into a coherent set of flows that are meaningful on the factory floor of enterprise organizations. I am really tired of saying API lifecycle and not really being on the same page with folks I am talking to about how to do APIs. It feels like we can significantly stablize how we do things if we can establish a common vocabulary for how we describe the API lifecycle similar to how we've found ways to describe our individual APIs using OpenAPI, AsyncAPI, and JSON Schema.