preface

My career has spanned more than two decades, mostly in finance, and during that time I have worked on connecting software across networks using technologies like FTP, Sun RPC, CORBA, Java RMI, SOAP, and web APIs. I have complained about terrible internal and third-party APIs (web services, RPC, etc.) and created awful ones myself. I’ve witnessed how flawed API design causes confusion, prolonged development, brittle code, rising technical debt, wasted resources, production crashes, and security breaches.

As technology evolved, connecting software became easier, especially with web APIs. The rise of “as a service” products and successful public APIs like Twilio and Stripe in the 2010s raised expectations for API design and developer experience; sending SMS messages and money with simple code was a game-changer. It transformed my approach to software and API design: why, I wondered, couldn’t I always have such a fantastic experience? However, even after the API hype started, many private and public web APIs were neglected, just as their predecessors had been. They were often seen as mere technical plumbing, and well-meaning creators often fell into common traps that I also encountered.