I’ve designed maybe fifteen or twenty internal APIs at this point, across different companies and stacks. I’ve also consumed enough poorly designed ones to know exactly which mistakes feel obvious in hindsight and still get made every time.<\/p>\n
The turning point for me was the first time another team had to integrate with something I’d built. Watching them hit the rough edges I hadn’t thought about was educational in a way that code review never quite is. You learn different things when you’re the one being integrated against.<\/p>\n
These are the rules I actually go back to every time I’m designing an API from scratch. Not a comprehensive spec \u2014 a short list of things that resolve the most common arguments and prevent the most debugging time.<\/p>\n
The most common REST API mistake is using endpoints as action names instead of resource names.<\/p>\n
# Avoid this\nPOST \/createUser\nPOST \/deleteUser?id=123\nGET \/getUserById?id=123\nPOST \/updateUser\n\n# Do this instead\nPOST \/users\nDELETE \/users\/{id}\nGET \/users\/{id}\nPATCH \/users\/{id}\n<\/code><\/pre>\nThe HTTP method already describes the action. Your endpoint should describe the thing<\/em> being acted on. Once you internalize this, a lot of design decisions stop being decisions \u2014 you’re just modeling your domain as nouns and letting the verbs come from HTTP.<\/p>\nThe tricky cases are operations that don’t fit cleanly into CRUD. “Archive an order” \u2014 is that a PATCH to set status: archived<\/code>? A DELETE? A POST to \/orders\/{id}\/archive<\/code>? I usually go with PATCH and a status field, because it keeps the resource model clean and lets you distinguish archiving from hard deletion at the data layer. The Google API Design Guide<\/a> has good thinking on custom methods if you hit genuinely complex cases.<\/p>\nVersion from the start, even if you think you won’t need to<\/h2>\n
I’ve never worked on an API that didn’t need versioning at some point. The only question is whether you planned for it.<\/p>\n
Versioning in the URL (\/api\/v1\/users<\/code>) is the most common approach and the most practical for most teams. Verbose but explicit \u2014 you can see exactly which version you’re calling, and you can run v1 and v2 side by side during a transition.<\/p>\nVersioning via headers (Accept: application\/vnd.api+json;version=2<\/code>) is technically cleaner but harder to test in a browser or with a basic curl<\/code> command. In practice, teams that use header versioning spend more time explaining how to set headers correctly than teams that use URL versioning.<\/p>\nPut the version in the URL. Accept that it looks a bit clunky. Future you will be grateful.<\/p>\n
Return consistent error shapes<\/h2>\n
This is the thing that causes the most pain in integrations, and it’s completely avoidable.<\/p>\n
Every error response from your API should have the same shape. The shape I use looks roughly like this:<\/p>\n
{\n "error": {\n "code": "VALIDATION_ERROR",\n "message": "Email address is invalid",\n "field": "email"\n }\n}\n<\/code><\/pre>\nThe code<\/code> is a machine-readable string that clients can switch<\/code> on. The message<\/code> is human-readable text for logging or display. Optional fields like field<\/code> carry context specific to the error type.<\/p>\nWhat you want to avoid is a mix of shapes across endpoints \u2014 sometimes {\"error\": \"something went wrong\"}<\/code>, sometimes {\"message\": \"Invalid input\", \"errors\": [...]}<\/code>, sometimes a plain string body. This forces every client to handle every possible shape, and they usually do it poorly.<\/p>\nThere’s an actual RFC for this \u2014 RFC 7807 (Problem Details for HTTP APIs)<\/a> \u2014 if you want a standard to point colleagues to. Pick one shape, document it, and stick to it across every endpoint including 4xx and 5xx responses.<\/p>\nUse 422 for validation errors, not 400<\/h2>\n
This comes up in code review often enough that it’s worth a dedicated section.<\/p>\n
400 (Bad Request) should mean the request is malformed \u2014 invalid JSON, wrong Content-Type header, something the server can’t parse. 422 (Unprocessable Content) is for requests that are syntactically valid but semantically wrong: a required field is missing, an email doesn’t match the expected format, a date is in the past when it needs to be in the future.<\/p>\n
The distinction matters because clients can handle these differently. A 400 means “fix how you’re sending the request.” A 422 means “fix the data you’re sending.” Conflating them makes client-side error handling more ambiguous than it needs to be.<\/p>\n
Same principle applies to 404 vs 403. 404 means the thing doesn’t exist. 403 means the thing exists but you can’t see it. Using 404 when you mean 403 (a common privacy pattern) is a deliberate choice some APIs make \u2014 just make it deliberately, not because you mixed them up.<\/p>\n
Paginate everything that returns a list<\/h2>\n
Any endpoint that returns a list should be paginated, even if you currently have five items and can’t imagine having more. Lists grow. APIs that don’t paginate force you to add it later, which is a breaking change if clients are relying on getting everything in one shot.<\/p>\n
I default to cursor-based pagination for anything that might have concurrent writes:<\/p>\n
{\n "data": [...],\n "pagination": {\n "next_cursor": "eyJpZCI6MTIzfQ",\n "has_more": true\n }\n}\n<\/code><\/pre>\nOffset pagination (?page=2&per_page=20<\/code>) is simpler and fine for static or append-only data. For anything where items can be inserted or deleted between pages, cursor pagination avoids the skipped-row and duplicate-row bugs that offset pagination produces under concurrent load.<\/p>\nThe format matters less than the consistency. Use the same pagination shape across all list endpoints, or your clients will have to write different pagination logic for each one.<\/p>\n
Design the error cases before the happy path<\/h2>\n
I picked this up from a talk I half-remember and can’t find the source for, but it’s changed how I approach API design.<\/p>\n
Before writing any endpoint logic, I write down every error case I can think of: what if the resource doesn’t exist? What if the user doesn’t have permission? What if a required field is missing? What if two requests race on the same resource?<\/p>\n
Once the error cases are explicit, the happy path usually writes itself. And you end up with a much more complete error surface documented before any client hits a production edge case.<\/p>\n
This pairs well with thinking about idempotency keys early \u2014 if clients might retry requests (and they will), which endpoints need to be safe to call twice? Better to decide that upfront than to discover an order got charged twice after launch.<\/p>\n
For how error handling actually looks in the service layer behind the API, the post on Go error handling patterns<\/a> covers the approach I use in the services that sit behind these endpoints.<\/p>\nThis week: pick one of your own APIs and check whether its error responses have a consistent shape across every endpoint. If they don’t, that’s probably the highest-leverage fix you can make without breaking existing clients.<\/p>\n
\n