explaingit

interagent/http-api-design

13,690Audience · developerComplexity · 1/5Setup · easy

TLDR

A practical written guide for designing consistent HTTP APIs, based on real decisions Heroku made building its platform API, covering URL structure, error handling, versioning, and more.

Mindmap

mindmap
  root((http-api-design))
    What it is
      API design guide
      Heroku conventions
      Team agreement doc
    Topics covered
      URL structure
      Error handling
      Versioning
    Audience
      Backend developers
      API teams
    Use Cases
      Team standards
      API review
      New API design
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Use these conventions as a team agreement to stop debating API design choices and ship consistent endpoints faster

USE CASE 2

Review an existing API against Heroku's guidelines to find inconsistencies before a public launch

USE CASE 3

Follow the URL structure, error format, and versioning recommendations when designing a new web API from scratch

Getting it running

Difficulty · easy Time to first run · 5min

In plain English

This repository is a written guide for designing HTTP APIs, the kind of interfaces that let software applications talk to each other over the web. It started as an internal document at Heroku, drawn from real decisions made while building the Heroku Platform API. Heroku later published it openly so other developers could use the same conventions. The guide is a collection of opinionated recommendations about how to structure an API: what URLs should look like, how to handle errors, how to version an API over time, and similar questions that every team building a web API has to answer. The stated goal is consistency, not finding the single perfect answer to every question. The authors wanted a shared set of rules that a team could agree on and stop debating repeatedly, which they describe as avoiding "bikeshedding" (spending too much time arguing about small stylistic choices). The actual guide content lives in the repository as text files rather than code. Reading it is easiest through the GitBook link mentioned in the README, which renders the chapters in a more readable format. The guide assumes the reader already knows what HTTP and JSON are and covers how to apply them well rather than explaining the basics. The repository has been translated by volunteers into Italian, Korean, Portuguese, Spanish, Turkish, Traditional Chinese, and Simplified Chinese, suggesting it found an audience among developers worldwide. Contributions to the guide are welcome through the standard GitHub pull request process.

Copy-paste prompts

Prompt 1
Using the Heroku http-api-design conventions, review this endpoint and suggest improvements: POST /users/create with a JSON body
Prompt 2
Based on the http-api-design guide, write an OpenAPI spec for a simple task management API with properly structured error responses
Prompt 3
Apply the http-api-design versioning recommendations to help me decide between URL versioning and Accept-header versioning for my REST API
Prompt 4
Write an error response format for my REST API that matches the Heroku http-api-design guide, including status code, id, and message fields
Open on GitHub → Explain another repo

← interagent on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.