Hot off the presses
Why Show Users Garbage API Errors
What happens in your client application when an API error pops up beyond the common cases of Logged Out, Not Found, etc.? Do you vomit random API error codes and exception class names all over your end users screens, pointlessly confusing the hell out of them?
Designing the world's most beautiful API is only half the story, somebody needs to interact with it!
API Developers focus so much on designing and building their APIs, yet often we seem to forget the folks on the other end of the line. You, the frontend and backend developers trying to integrate our data and functionality into your own work, often get left with junky docs, or are just assumed to know how things are going to work.
Everyone and their dog wants an API, so you should probably learn how to build them.
Tasked with building an API for your company but don't have a clue where to start? Taken over an existing API and hate it? Built your own API and still hate it? This book is for you. This book has been up on the LeanPub top 10 for most of its lifetime, and was the #5 Best Selling Book of 2015, so it can't be too bad.
About this Community
API development is a topic very close to Phil's heart. APIs You Won't Hate started out as a book, with Phil pouring everything API related he knew, all the problems he faced, all the design decisions he wish he thought about earlier.
Since the book, Phil has continued to learn and grow, thanks to new experiences, and new conversations with really smart people. Learning never stops, and the Slack channel that grew from the book subscribers and their friends has become home to the largest API chat group on the internet.
APIs You Won't Hate is dedicated to learning, writing, sharing ideas and bettering understanding of API practices. Together we can erradicate APIs we hate.
About Phil Sturgeon
Since 2010 I've worked as a freelancer, consultant, Head of API, and CTO, for several API-centric technology startups.
Previously at Ride, I was given the chance to work with amazing developers, including several Rails API contributors. We built an event-driven architecture with several REST APIs and a few RPC ones, and it was here I learned the benefits of REST being a state machine over HTTP.
Then at WeWork, I used my experience to help educate developers, define standards for API design and architecture, and work on open-source tooling for OpenAPI, JSON Schema, and HTTP. WeWork has 50+ APIs, and here I have had a chance to learn a lot about keeping distributed applications performant. Timeouts, retries, circuit breakers, keep alive settings, and HTTP caching specificially.
I try to turn all of this learning into books, videos, and articles, so others can learn easily things I've had to learn the hard way.