The following is a response mailed to a friend of mine about Jim Webber's post.
I generally agree with the graph, but... imagine that that graph doesn't have time as it's x-axis, but instead has "inverse [user] expressibility" as it's x-axis. The y-axis then needs to become..."constraint".
I think there's a negative-slope graph of some other quantity -- maybe "understandability" or "optimizability" or "infrastructure utility" or something that crosses the above one just /at/ REST ... and maybe even just to the left of it.
The line itself is ... something ... maybe ... "goodness" or "Quality", and it is actually the lower bound of the two lines posited above. Thus, it peaks [just to the left of] REST...
WebDAV is just to the left of REST.
And there's something else, with a very small number of additional verbs, just to the left of that.
But, I believe, that's where it peaks.
To the right is the semantic fog of "do" [or "processMessage" or whatever...].
To the left is a whole layer devoted to the transfer of arbritrary verbs, which is, effectively, also a semantic fog of "do".
Right at the peak is an area where the infrastructure is actually something the application can leverage, since the operational semantics are well defined. I think. I'm not quite sure, how, yet, but I'm trying to figure that out... :) At least, developers/intermediaries/&c. benefit from the consistency and clarity.But I do think there are definitely things that a real container can provide, there.
[For instance, one desire would be to have a first-order b[atch]GET operation, allowing the server to optimize the multiple safe/idempotent read operation.]
In the mean time, Mark Baker has posted his take , which -- as usual -- better expresses what I was trying to get across.