graphing
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.