Individual API Life Cycle Stops And Operational Life Cycle Stops

One difficulty I have telling stories across the API lifecycle involves the separation of stops along the API life cycle that are about each individual API, and those that are about serving the entire operation--all APIs. There is a relationship between the two, but there are many different ways in which you can help educate developers, and provide instruction depending on whether it is just about a single API, or something that supports all APIs. One key aspect of standardizing how APIs are brought to life is to make sure you are always thinking about the big picture, while also ensuring each individual API has what it needs.

It is common for API developers to think about their immediate needs when designing, developing, delivering, ad supporting an API. It takes a lot more work to make sure that the things which can be reused and replicated across APIs are identified. It usually takes someone paying attention to the bigger picture, helping connect the dots, and lending a hand in helping developers work together and follow standards that have been set to help insure quality, consistency, along the way. Helping identify common patterns in use, documenting them, and then working to educate, disseminate, and incentivize their usage and adoption. Turning healthy practices into well-defined stops along the API life cycle, and minimizing the unique special snowflake status of each individual API we deliver.

Letting API developers operate in isolation is how we end up with many different kinds of APIs, across different teams and groups. If you have ever used a large public API provider like Google, Amazon, or Azure, you’ve noticed that not all the APIs are designed the same. While there may be similarities across them, there are often little difference that can cause friction all along the way, resulting in challenges for developers when building their applications. I’m always looking for ways to help developers see the big picture beyond what they are working on, which is why I like my storytelling to properly straddle both dimensions of the API life cycle, while also helping my readers expand their view of landscape, and how sharing and reuse of API patterns can help them be more efficient now, and in the future.

This post is just a gentle reminder for me to thinking about this duality in the world of APIs as I write blog posts, crafting white papers, and produce webinars, tutorials, workshops, and talks. I want to invest in helping API developers be more successful in what they are doing, while also contributing to the bigger picture. The trick is helping them understand that this isn’t just about giving them more work, and it is about helping them make things as painless as possible for their consumers, while also being more efficient at delivering kick-ass APIs. I’d say that 75% of API development should be about reusing existing patterns, and about 20% uniqueness, with maybe around 5% giving back with new patterns that should be considered for wider adoption. Developers should be heavily focused on learning and reusing patterns over creating anything new or special—I am interested in making sure my storytelling reflects this reality.