I still wonder about my POST approach a few posts up. It has the “query URI” to identify just the subset of data we want to update, but then POSTs to the URI in order to avoid the expense of having to pull all the data over the wire, increment it client-side, and push it back up. Basically it maps things nicely into resources as Stelios suggested, but allows POST with an expression language to change resources. What do you think about that?

I won’t elaborate much more on the caching point. You really have to implement it. Suffice to say that it’s really not that difficult at all to keep state changes local. And where it isn’t, just turn off caching. But be wary of models or conventions which require turning it off.

To do the equivalent of your UPDATE example (btw, your SQL could use some work 8-) RESTfully – and I mentioned this on my weblog comments in the context of a similar example – the server could offer a GET form that the client could first populate with “500″ (addressing the >500 requirement), creating a new “query URI” (ala HTML forms) upon which GET would return a document representing all the foo values. Then the client would do the “+1″ and PUT it back to the server. Voila!

what you propose is to have the operation in the body of the HTTP message in some sort of tunneling which is not RESTful (REST has a standard number of operation that for HTTP are GET,POST,HEAD,DELETE,PUT) but let’s see what Mark has to say on the subject :-)

Stelios

I think I’d like to do it a little bit differently, to avoid having to transfer all the data back and forth. Something like

POST /codd/table?bar>=500

and then in the message body the operation to apply to every row:

foo = foo + 1

This would map quite nicely to SQL:

UPDATE table SET foo = foo + 1 WHERE bar>=500

I wonder what Mark thinks about this.