REST

I design REST APIs as interfaces, not endpoints: resources named and nested around the domain, verbs that map to HTTP, and explicit status semantics that make clients predictable. Consistency of contracts matters more than any single convention.

Pragmatism guides the details — collections with pagination and filtering, idempotency where it matters, error envelopes with request IDs, and careful use of caching headers. The goal is APIs that are easy to consume today and safe to evolve tomorrow.

Versioning and backward compatibility are design work, not an afterthought. I treat the public contract as a shipped product, documented and tested, so breaking changes are deliberate and rare.

Resource modelling is where I earn the architecture. I make nouns match the domain (an order, a customer, a payment) rather than exposing internal query shapes, which keeps the API stable even when the implementation underneath changes.

HTTP semantics are used properly, not superficially. GET for reads, POST for actions, PUT/PATCH for updates with the right idempotency, DELETE for removal, and status codes that mean something — so clients can rely on the protocol instead of parsing magic strings.

Pagination, filtering, and sorting are consistent across collections. I settle on one convention and apply it everywhere, so every list endpoint behaves predictably — which is the small print that separates a usable API from a frustrating one.

Errors are structured and debuggable. A consistent error envelope with a code, a message, and a request ID lets a client recover gracefully and an operator trace the failure to a log line — instead of a bare 500 and guesswork.

The API is authenticated, rate-limited, and validated by default. Access control, quotas, and strict input validation sit at the edge, so services behind the API can assume safety rather than reinvent enforcement.

I keep it honest about REST too: not every integration calls for resourceful HTTP. Where RPC-style actions or event streams fit a problem better, I use them — REST is the default for CRUD-shaped resources, not a religion.

I model resources around the domain, not the query. Nouns match the business — an order, a payment, a customer — so the API stays stable even when the implementation underneath changes.

HTTP semantics are used honestly. GET for reads, POST for actions, PUT/PATCH for updates with the right idempotency, DELETE for removal, and status codes that mean something.

Pagination, filtering, and sorting are one consistent convention across every collection, so each list endpoint behaves predictably instead of inventing its own quirks.

Errors are structured and repeatable. A consistent envelope with a code, a message, and a request ID lets clients recover and operators trace the failure to a log line.

Idempotency is added where it matters. Mutations that can be retried safely get idempotency keys, so a flaky network does not produce duplicate side effects.

Versioning and deprecation are designed in from the start. I treat the public contract as a shipped product that must evolve cleanly, with breaking change as a deliberate, rare step.

Auth, rate limits, and strict validation sit at the edge. The API enforces access and safety once, so services behind it can trust the request instead of re-inventing enforcement.

Caching is used deliberately. Cache headers and HTTP caching at the right layer protect the hot path without serving dangerously stale data.

I am honest about REST — it is the right default for CRUD-shaped resources, but where an RPC-style action or an event stream fits better, I use that without apology.