REST APIs
Predictable, documented REST APIs that frontend and partners actually like consuming.
I have designed and shipped dozens of REST APIs across Node.js, NestJS, Express, and Spring Boot. I care about predictable resource modeling, sensible status codes, consistent error shapes, OpenAPI documentation, and versioning that does not break consumers on a whim.
How I work with REST APIs
REST is the API style I have shipped the most. I design resources around business nouns, keep verbs on HTTP methods, and use status codes properly — including the ones developers commonly skip (409, 422, 429).
Every public API I lead has an OpenAPI document generated from the code (NestJS decorators or springdoc) so the documentation cannot drift from the implementation. I include real example payloads, error schemas, and rate-limit headers.
I think about consumer DX as a first-class concern: consistent error envelopes, idempotency keys on mutating endpoints, ETags where caching helps, and predictable pagination. Good API design is a multiplier — bad API design is a tax everyone pays forever.
REST APIs across business domains
Designed the public REST API for an AI document-processing product, with async-job endpoints + status polling and webhook callbacks for partners.
Built listing, agent, and lead REST APIs consumed by web, mobile, and partner integrations.
Implemented compliance + audit REST APIs with versioning and strict schema validation for B2B consumers.
Delivered REST endpoints for dealer inventory + lead routing, integrated with external CRMs over REST/webhooks.
Real issues I resolved using REST APIs
Standardized error responses across 80+ endpoints
Different endpoints were returning different error shapes — some `{ message }`, some `{ error: { code, detail } }`, some raw strings. Frontend error handling was a mess.
Defined a single error envelope (code, message, details, requestId), enforced it via a global exception filter, and updated the OpenAPI document so consumers could rely on the contract.
Frontend error handling collapsed into one helper, partner integrations got simpler, and bug reports about 'weird error format' stopped showing up.
Added idempotency to a payment API to stop duplicate charges
Clients occasionally retried payment requests on network errors, and the API would happily charge twice.
Added an `Idempotency-Key` header convention: requests with the same key + payload returned the original response within a window; mismatched payloads returned 409.
Duplicate-charge incidents stopped, network-retry behavior became safe, and partners adopted the pattern without resistance because it was standard.
Versioned the API without breaking existing consumers
A required breaking change was blocked because partners on v1 could not migrate quickly.
Adopted URL-based versioning (`/v1`, `/v2`) at the gateway level, kept v1 stable, and rolled out v2 with the breaking change plus a migration guide and a deprecation timeline.
The breaking change shipped on schedule for new consumers; existing partners migrated on their own timeline without emergency.
Often used together
Have a REST APIs project in mind?
I am open to full-time and contract work where REST APIsis core to the stack. Let's talk about what you are building.