OpenAPI is an excellent tool for defining an API, yet its often treated as just a documentation tool. In this post I’ll explore how an OpenAPI spec can drive many parts of your API lifecycle.
And so we reach the end of another coding-year, and while many of us are plotting our holiday hacks and offline AR (actual reality) adventures, there are a few folks who still have to launch features over the break.
Ok, so now you’re charging ahead anyway, without your whole team on board, it’s a period of heightened risk and it’s important that you approach production changes with an appropriate level of caution and care.
“Initial commit” is so uninspiring yet we’ve all committed it somewhere!
I’ve recently found myself creating a noticeable handful of repositories for various projects and it got me thinking: whats in a first commit? It’s the commit that hangs around like a bad smell for years after you make it. It appears in github in that placeholder .gitignore, or in that tiny file that never gets changed. So why think about it?
Backwards compatibility is one of the most crucial factors of when and how to release a new feature. Maintaining a stable API while constantly improving your service is critical - you don’t want to be breaking your API clients every second Tuesday. In this simple example I want to share how fields that are enums (commonly status fields) are crucial parts of your API stability and how changing them is a terrible idea.
Surprise (or no surprise) - I’m in Seattle for #MSBuild this week! I’m also delighted to be part of a small Microsoft-invited group called TAG (Technical Advisory Group), composed of folks from around the world with a strong open source tech background.
Our itineraries are packed, and I’ll be sharing some of the sights, insights and delights along the way.
In today’s itinerary, we’ve been treated to a round of shiny toys and tech-theatre.