REST API
A REST API is an HTTP interface built around resources, such as orders or users. Each request stands on its own, uses standard HTTP meanings, can support caching, and may pass through layers.
Another example
A warehouse app gets `/orders/784`, changes its address with a conditional `PATCH`, and follows a `Link` header to tracking. Any stateless server can handle the request. If the `ETag` is old, the server returns 412 instead of replacing a newer edit.
Main parts
- 01Resource identifier
- 02Uniform HTTP operation
- 03Representation and links
Use it when
Use REST when resource-based HTTP, caching, middle layers, and clients that can change on their own fit the product.
Do not use it when
An API is not RESTful just because it sends JSON over HTTP. Stateful sessions, RPC command tunnels, or ignored HTTP meanings are different designs.
Name used in code
client-server + stateless + cache + uniform interface + layered system + hypermedia Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review REST API for this system while keeping data correct, secure, and easy to operate. User context: A warehouse app gets `/orders/784`, changes its address with a conditional `PATCH`, and follows a `Link` header to tracking. Any stateless server can handle the request. If the `ETag` is old, the server returns 412 instead of replacing a newer edit. Technical concept or control: REST API. Why it fits: Use REST when resource-based HTTP, caching, middle layers, and clients that can change on their own fit the product. Do not use it when: An API is not RESTful just because it sends JSON over HTTP. Stateful sessions, RPC command tunnels, or ignored HTTP meanings are different designs. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of REST API. Definition: A REST API is an HTTP interface built around resources, such as orders or users. Each request stands on its own, uses standard HTTP meanings, can support caching, and may pass through layers. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.