Gateway Gus saysDesign resources (nouns) first, then map operations to HTTP methods — not RPC-style verbs.
Good REST design starts by modeling the domain as resources: what things exist and how they relate. Then the HTTP method supplies the verb. Resist /createOrder, /cancelOrder RPC sprawl — model an /orders resource and use POST/PATCH/DELETE. For genuine actions that aren't CRUD, a sub-resource (POST /orders/9/refunds) usually fits.
Power-ups you unlock
Model resources (nouns) first
HTTP method is the verb
Avoid RPC verb sprawl in URLs
Non-CRUD actions → sub-resources
Timeout Titan attacks — common mistakes
/doThing verb endpoints everywhere
Forcing every action into rigid CRUD
Inconsistent resource modeling across the API
Boss battleRedesign /cancelOrder and /refundOrder as resources + methods.
Example code
<!doctype html><html><head><meta charset="utf-8"></head>
<body style="background:#06040d;color:#e6e0ff;font-family:monospace;padding:20px"><pre>RPC: POST /cancelOrder?id=9
REST: PATCH /orders/9 { "status":"cancelled" }
POST /orders/9/refunds</pre></body></html>