Beyond CRUD: A Practical Guide to Modeling Business Processes in REST APIs

Most developers agree that naming things is one of the hardest parts of our job. Designing a clear, effective RESTful API comes in as a close runner-up. On the surface, REST makes a lot of sense. Compared to its dominant predecessor, SOAP, which involved hammering a POST endpoint with unwieldy XML requests, REST feels like a breath of fresh air. By combining an HTTP Method with a URI (Uniform Resource Identifier), you can create (POST), read (GET), update (PUT or PATCH), and delete (DELETE) resources. Simple and intuitive, right? Not quite. HTTP methods were originally designed to manage documents, not to model complex business processes. They assume that all you need to do with a resource is create, read, update, or delete it. In reality, business applications often require more: resources might need to be approved, cancelled (without being deleted), paid, or moved between different states. Sometimes, a process even spans several resources at once. Mapping these kinds of business acti