#REST
Articles about REST — exploring patterns, best practices, and real-world implementations in production systems.
5 posts tagged with rest. ← All posts
The real skill isn't cutting a v2 — it's knowing which changes are safe to ship silently, which ones break clients you'll never meet, and how to retire an old version responsibly instead of forever.
Changing an API without breaking consumers: what counts as breaking, versioning strategies and their trade-offs (URI vs header vs additive evolution), the robustness principle and its limits, and responsible deprecation with Sunset headers and usage telemetry.
Why a consistent, machine-readable error model (RFC 9457 problem+json) and idempotency keys are the difference between an API clients can trust and one that quietly double-charges them.
The two things that make an API safe to build on: a consistent machine-readable error model (RFC 9457 problem+json, stable error codes, no leaked internals) and idempotency (the Idempotency-Key pattern so retries don't double-charge).
Shaping the payloads clients actually consume — consistent bodies, content negotiation, field selection, and pagination that survives scale and mutation.
Shaping the payloads clients consume: consistent naming, dates and money done right, content negotiation, field selection, and pagination — why offset pagination breaks at scale and how cursor/keyset pagination fixes it.
How to model resources as nouns, choose HTTP methods by their spec-defined semantics, return the right status codes, and decide honestly how much hypermedia your API actually needs.
Designing REST resources the right way: modeling resources as nouns, URI design, HTTP method semantics (safe vs idempotent, PUT vs PATCH), using status codes correctly, and a realistic take on the Richardson Maturity Model and HATEOAS.
The opening post of a series on designing APIs people actually enjoy using — why an API is a contract and a product, the qualities that separate a good one from a bad one, and why the contract should exist before a single line of implementation.
The opener to an API design series: an API is a contract and a product whose users are developers — the qualities that matter (consistency, evolvability, hard-to-misuse), API-first vs code-first, the interface/implementation boundary, and the paradigms you'll weigh.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.