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.

there is no need to have 2000 round trips to update 1000 rows. In my example GET /codd/table?bar=>500/foo could return a list of (ID, foo-value) pairs, in other words a 2-ary relation. (Actually it couldn’t have been otherwise because the URI does not uniquely identify a row in the table). Now the client could update all the foo values, reconstruct the list, and PUT it in the server. (Etag/If-Match conditional update is more difficult in this case but it’s certainly doable…)

So the update process is:

fs = GET /codd/table?bar=>500/foo

fun = function(id, foo-value) { return (id, ++foo-value);} fs’ = map fun fs

PUT /codd/table?bar=>500/foo fs’

:-D

Stelios

Mark, your first comment seems to say that anything not RESTful is not the Web. Web services and SPARQL HTTP bindings and SQL queries sent via POST requests are certainly not RESTful, but that doesn’t necessarily make them unappropriate for the Web. 99% of deployed Web content is not RESTful, and most of it works anyway (think cookies).

I agree with Alex on the caching point. I don’t believe that many real-world systems can be partitioned in a way that a change to one resource never changes the representations of another resource.

Stelios’ proposal is nice, unless you want to do something that does not cleanly map to a single resource, like my UPDATE example. It requires 2000 roundtrips to update 1000 rows, where a simple “send SQL via POST” approach would require one roundtrip to do the same. Same for RESTQL, which otherwise is an interesting idea.

This is about distributed data computing. This is about efficient and non-trivial client-specified adhoc querying via http, and local processing for arbitrary-sourced combinations, and probably local processing of relative updates as in this case.

This is about scaling through applying this distributed-store/local-processing internally in partitioning our data stores. This is about dealing with caching by strong support in the “physical” model, not by impinging on the logical layer.

It implies all updates are occuring only through HTTP? how practical is that in reality?

If I have an application running inside AMAZON’s network that applies some general discounting rules then all cached URI’s that represent books are immediately out of date anyway?

It is not as if because we expose our data restfully, all of a sudden that is going to be the only way you can update it.

So I don’t see why you should enforce some rules about PUT granularity in your REST implementation, it makes no sense to me.

I also don’t buy the HTTP swamping argument either. Updates are generally a lot less frequent than gets, so why not go granular on the update. If you have a number of tuples to update sure go more chunky, that is a standard piece of distributed architecture advice, but if you have only one thing to update, why pass everything else?

That can have some nasty side effects too, you might now introduce the last update problem, because of optimistic concurrency issues, i.e. the server doesn’t actually know what fields you are trying to update so it assumes you are trying to update everything.

If in our distributed systems we mandate chunkyness we simply further increase the systems brittleness.