Build APIs You Won't Hate

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 #5 Best Selling Book of 2015, so it can't be too bad.

It's also available on these sites, but a much bigger chunk goes in their pocket.

Amazon US Amazon UK Amazon FR Amazon DE

What the book covers


Naming things is hard, and working out how to structure your endpoints can be tough. Understand the benefits of plural v singular, collections, resources, sub-resources, sub-collections, etc.

Input and Output

Learn which data formats are nice to work with, and why form data is so entirely useless. Compare Facebook, Twitter and existing standards like JSON-API.

File Uploads and Downloads

APIs aren't just about JSON data, you can upload and download files of all sorts. Images, videos, CSV, etc.


Public and Private APIs need good quality documentation, generated from simple specifications. Otherwise you're all just guessing at what the contracts are.

Errors and Validation

Look at what makes a good error message, making it understandable for humans and computers alike with the inclusion of codes, documentation links, and usage of standards.


Shoud you use HTTP Basic, HTTP Digest, OAuth 1.0a or OAuth 2.0 to secure your API? The answer is probably OAuth 2.0, but find out a huge load of pros and cons on each of them.


Working with APIs can be a little confusing at first, especially if you're trying to use the browser or Curl. This chapter outlines some powerful tools to make it easy as pie.


What approach should you take to versioning your APIs, when to use which approach, and why they're all terrible.


Copies sold





About the book

API development is increasingly common for server-side developers thanks to the rise of front-end JavaScript frameworks, iPhone applications, and API-centric architectures. It might seem like grabbing stuff from a data source and shoving it out as JSON would be easy, but surviving changes in business logic, database schema updates, new features, or deprecated endpoints can be a nightmare.

After finding many of the existing resources for API development to be lacking, Phil learned a lot of things the hard way through years of trial and error. This book aims to condense that experience, taking examples and explanations further than the trivial apples and pears nonsense tutorials often provide.

Phil worked primarily as an API developer for the last three years. One horror was managing an API built in FuelPHP by a freelancer at the million dollar startup he joined. It was utilizing a then deprecated ORM which had been hacked to death by the previous developer, so took the time to delete that mess and build the next version in Laravel, leveraging it's simple routing, database migrations, schema, seeding, etc. When the following major version of the API was built no rewrite was required, and both managed to live side-by-side on the same "API" servers.

By passing on some best practices and general good advice you can hit the ground running with API development, combined with some horror stories and how they were overcome/avoided/averted. This book will discuss the theory of designing and building APIs in any language or framework, with this theory applied in PHP-based examples.

Some of the more advanced topics covered here are endpoint testing, embedding data objects in a consistent and scalable manner, paginating responses (including embedded objects) and hypermedia "HATEOAS" controls.

People who no longer hate their APIs

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 me 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. Tmeouts, 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.