Unless you know all the assumptions the consumers of your API have made, it’s impossible to reliably avoid breaking their software. Assuming you, like me, can’t read minds, what can we do to try and keep the number of sad developers to a minimum?
Breaking changes are sad. We’ve all been there; someone else changes their API in a way you weren’t expecting, and now you have a live-ops incident you need to fix urgently to get your software working again. Of course, many of us are on the other side too: we build APIs that other people’s software relies on. There are many strategies to mitigate breaking changes: think SemVer or API versioning, but all rely on the API developer identifying which changes are breaking.
That’s the bit we’ll focus on in this talk: how do you (a) Get really good at identifying what changes might break someone’s integration (b) Help your API consumers to build integrations that are resilient to these kinds of changes © Release potentially breaking changes as safely as possible
Priority access to all content
Community Discord
Exclusive promotions and giveaways
