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 busi