#REST-API
13 posts tagged with this topic. ← All tags
-
Cursor-based pagination: the implementation that doesn't break under load.
Offset pagination skips rows, which breaks when data changes between pages. Cursor-based pagination uses a stable position marker that stays correct regardless of concurrent writes.
-
API design review: 10 questions before you call an endpoint done.
A checklist of design decisions that are easy to skip when building an endpoint and painful to change after consumers depend on it.
-
tRPC: end-to-end type safety without writing an API spec.
tRPC lets your frontend call backend procedures with full TypeScript types — no REST spec, no codegen, no type drift between client and server.
-
GraphQL vs REST: the actual tradeoff, not the hype.
A realistic comparison of GraphQL and REST covering over-fetching, type safety, tooling, caching, and when each approach wins.
-
Swagger UI without polluting your app: CDN-hosted docs in 10 lines.
Swagger UI can be served from a CDN with a single HTML file and no npm packages. Here's how to wire it to your OpenAPI spec without adding dependencies to your app.
-
OpenAPI spec: the minimum you need to write and what it unlocks.
OpenAPI specs enable auto-generated docs, client SDK generation, and request validation. Here's the minimum viable spec and what you get from writing it.
-
API error responses: the format that makes frontend error handling not miserable.
Inconsistent error responses force frontend developers to write brittle parsing code. A predictable error format makes client-side error handling straightforward.
-
Idempotency: why your PUT endpoint should be safe to call twice.
Idempotency is a property of HTTP methods that makes distributed systems more reliable. Here's what it means, which methods must have it, and how to implement it for POST.
-
Offset pagination breaks at scale. Here's how cursor pagination fixes it.
OFFSET-based pagination is easy to implement but produces inconsistent results as data changes. Cursor pagination is stable, performant, and the right default for most APIs.
-
API versioning: 3 strategies, 1 that doesn't create maintenance debt.
API versioning is how you change your API without breaking existing clients. Here are three common strategies, their trade-offs, and the one that scales without accumulating maintenance burden.
-
HTTP 200 is not always success. The status codes that make a difference.
Using 200 for everything is technically wrong and makes error handling harder for API consumers. Here are the status codes worth using and what each one communicates.
-
URL design: naming conventions that prevent bikeshedding on every PR.
URL structure debates slow down teams. Establishing consistent naming conventions up front eliminates the recurring arguments and makes your API predictable.
-
REST constraints: the 3 that actually change how you write code.
REST has six architectural constraints. Three of them directly shape how you design endpoints and handle state. Here's what they mean in practice.