ROA vs GET/POST

Bill deHora has a great response to one of my (somewhat) recent REST posts. The timing is perfect, because I've been thinking a lot about what I said in those posts. I've also just finished reading the RESTful Web Services book, which is the most useful technical book I've read in a while, and have been thinking a lot about what it says too (and talking about it with Craig). I've been mulling over a post for a couple of days, and Bill's post is the impetus I needed to share what I've been thinking.

In RESTful Web Services, the authors define and argue the merits of Resource Oriented Architecture. ROA maps directly to the REST-as-CRUD model for thinking of the world, where interaction with your system is modeled entirely in terms of create, read, update and delete operations against data resources. For data-centric services, like the del.icio.us service that they refactor in the book, this model makes a ton of sense.

But what if your problem domain is more focused on processes than data? As the authors show with their proposal for modeling transactions, you can map any process to ROA with the following steps (or ones like them):

• PUT/POST to create a new process resource
• PUT to update that resource to include the data it needs
• PUT to execute that process
• GET to fetch the result

This maps any process to a set of resources. From this perspective, my argument that HTTP is all about POST and everything else is an optimization or unnecessary doesn’t make sense.

So could I model all processes the ROA way? Undoubtedly yes. But, what’s the value of this over just doing a POST with the data I want to process and getting the result back? It’s much easier to implement that because I don’t need the build-up of the process resource to span multiple stateless requests. I don’t ask this rhetorically, I really want to understand why people think this approach to modeling processes is better. (This is especially true if core bits of network infrastructure don’t support PUT/DELETE and you end up having to tunnel them through POST anyway.)

Maybe the process perspective is just the wrong way to think about the world, but it’s where a lot of people’s heads are at, including almost all the SOA/WS folks out there. In looking at my own system, I see one interface that is obviously data-centric and fits easily into the ROA model. Another interface is very process oriented. Right now we’re doing it with GET for read and POST for write, and it works and people get it. While I can see how to map it into the ROA model, I’m still unclear on how it helps.

So, to summarize, Bill is right: you shouldn’t follow what I said in that earlier post. (I always reserve the right to get smarter, and I’m using that now.) I’m still debating between the full ROA vs. GET for read and POST for write (again, especially if I have to tunnel through POST anyway), I really need to build some more stuff and see how it plays out.