Last week, someone sent me a direct message on Twitter asking the following question: Let’s say you have a resource with an activated boolean property, how would you design the operation(s) allowing to activate or deactivate it? As this is a use case I often encounter during API design reviews or API design workshops, I thought it would be interesting to share my usual answer(s) with everyone.

You didn’t knew that API Management was old and you needed a “Full Life Cycle” API management solution to help you achieve your API strategy? Well, I didn’t. To be honest, though the term is quite old, I didn’t realized until recently that “Full Life Cycle API Management” started to replace simple “API Management”, at least in software vendor communications. But what if I tell you that this “Full Life Cycle” version is already dead? What if I tell you that you need 8K API Management?

I was invited by David Brown and Kevin Montalbo for Toro Cloud’s Coding Over Cocktail podcast. We discussed API consistency, how to make your APIs more discoverable, defining and setting the boundaries between an API gateway and API implementation, and choosing the right API architecture and technology for the right problem.

I was invited to Stoplight’s API Intersection podcast hosted by my two good friends Jason Harmon and Adam Duvander. As it was Stoplight’s “Style Guide September”, we discussed one of my favorite topics, covered quickly in my book The Design of Web APIs, and that I practice everyday helping people to create APIs: API design style guides.

I started this project with a simple API Design Guidelines list in mind and ended with a fully analyzed collection of API design guidelines. I created it for others but I use it myself too. When I wonder how to handle some API design matters, I select the related topic and read how others handle it. To be honest, it needs some refresh, it is a real pain to update and maintain and could be more user friendly; that’s on my todo list.

I built the OpenAPI map because I was constantly searching for “how do this with the OpenAPI spec” and also “but where is that thing” in the specification. Having the OpenAPI specification represented as a tree given essential information and quick access to source documentation of each element saved me countless time.