The 12 API bugs I check for first
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
Blog
Status codes, contracts, pagination, auth, and the API bugs that surface before the UI is ready.
A high-value checklist: the twelve API bugs that surface most often, from wrong status codes to idempotency failures.
The specific bugs that hide in paginated, filtered, and sorted endpoints — off-by-one pages, unstable sorts, and filter leaks.
Skip the full registry — learn the dozen status codes that carry real meaning, what each promises, and how to spot when the code and the body disagree.
The API ships weeks before the screen. Test it directly from the contract — the whole bad-input, auth, and edge class is open at the API and invisible once the UI hides it.
Items vanished and duplicated on scroll; the frontend took the blame for two sprints. The cause was an unstable API sort over a non-unique key. Follow the symptom down the stack.
API suites fail on shared, stale, order-dependent data more than on wrong assertions. The own-your-data strategy — independent, unique, cleaned — that keeps them reliable.
Test the full rate-limit contract — enforcement, 429, Retry-After headers, recovery, scope — with a low configurable limit and a dedicated key, not by flooding shared staging.
An OpenAPI spec is a ready-made test plan — every param and status code is a case — and its gaps (missing errors, unbounded fields, drift) predict the bugs.
Not winner-takes-all — Postman for exploring and sharing, REST Assured for the durable automated suite in CI. The dividing line is lifespan and automation.
Three tools, three very different bets on what API testing should feel like. I've been comparing them for teams who want to move off ad-hoc curl scripts, and here's the pick.
Wiki pages about APIs go stale in three months. The API test suite gets opened every single day. Write tests that read like documentation — and stop writing the wiki.
Contract testing is two things wearing one name: a model and a tool. The model is genuinely useful; the marketing for the tool oversells where it fits. Here's the model, separated from any vendor's pitch.
Most 'REST vs GraphQL' content is about API design. The testing perspective is different — query construction, schema-aware tooling, the N+1-shaped test bug, and why GraphQL flips the test pyramid.