HTTP methods were designed for document management, not complex business processes. This guide presents 5 practical patterns for designing REST APIs that communicate business intent: (1) expose primary entities as root resources and scope child entities beneath them, (2) break out sub-resources when field groups represent distinct processes, (3) model actions as sub-resources by turning verbs into nouns (e.g., 'pay' becomes 'payments'), (4) promote complex multi-resource actions to root-level resources with their own lifecycle, and (5) fall back to RPC-style verb URIs when no meaningful noun exists. Real-world examples from Stripe, GitHub, PayPal, and Wise illustrate each pattern.