Hot off the presses
There's No Reason to Write OpenAPI By Hand
Sometimes you see people complaining about OpenAPI (formerly Swagger), saying they don't want to to write out a whole bunch of YAML/JSON by hand. Other than disability, there's no reason you need to do that, and there hasn't be for a long time. Whether you pick code-first or design-first, you've got some options.
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.