Odd things

I posted this comment to PragDave's Blog re: his entry titled: The RADAR Architecture: RESTful Application, Dumb-Ass Recipient

I'm not sure why all transformations on the data received cannot be performed in terms of the basic primitives (C.R.U.D in database parlance as it were)?

I think the trouble is that sometimes we insist that an operation like "EDIT" is somehow atomic, even though by its very nature, an EDIT implies a GET!

Even in 2-tier fat client versions, a "GET" is implied. The presence of the form which recives data from the server (be it DB or HTTP) is an indication that a "GET" happened during the development/analysis phase and is sort of frozen in time, so whenever a "fat" client does an EDIT operation, the GET has already been done for us (convention).

The issue with the slightly sexier TN3270 terminal (i.e., IE, e.g,) is that when it want's to do something called "EDIT", it needs to know WHAT it would be editing. Maybe stating the obvious here, but what I'm trying to say is that EDIT is a PUT, yes, but before a PUT, it is a GET. The thing is that what we need are "smart" GET operations. A GET for an eventual PUT (for EDIT purposes) is not the same as a GET for it's own sake (for eventual, and ultimately SHOW only purposes).

A really naive way of handling this in one GET would be that whenever we make a GET request on a resource which can also be edited, the RESPONSE has two parts, a SHOW part and an EDIT part. Now, if we want to EDIT it, we use the EDIT part, and do a PUT on the resource back to the server. If we just want to SHOW, then we just don't do a PUT with the edited stuff in the next REQUEST cycle. What i'm implying here, essentially, is an out of band channel, except that both "channels" are marshalled in the same response (to a given GET).

Same thing goes for CREATE. Before we create it, we need to know what the resource is (DESC TABLENAME in oracle terminology). That information can come via the GET and only then can we create it on the second part. I think this can still stay stateless and avoid all the monkey business of tacking on the action at the end of the URL etc.

So in C.R.U.D every single 'verb' is preceded by the READ verb by default.

C -> R+C
R -> R
U -> R+U
D -> R+D

I guess the crux of my argument is that a READ is _always_ implied, and since it is, we need not worry about what action is "legal", the GET/READ on any given resource should bring with it all that would be needed to do a CREATE/UPDATE/DELETE. All actions should be broken down into primitives, and one should not conflate the protocol with the internal implementation of how a framework or a server will serve a resource.

Also, techincally, an XML version of a page ought to be treated as a different resource than an ATOM version of it. Doesn't matter if it is being generated by the same controller or whatever piece of machinery is in vogue at the moment. From the protocol purposes, it ought to be treated as a separate resource, so a get for README.XML is different than a get for README.HTML or README.TXT althought it may be the exact same object being rendered by some smart piece of code in n-ways from sunday.

snip..snip..snip...

"CLOG"

What is really needed is a comment log, so your comments can be treated as a coherent narrative all across the internet. I think the age of "clogs" is near! :-)

Obviously, this would mean a protocol (yet another one) which identifies not only the place where the comment was entered, but also the owner of comments. The possibilities of mashups in this area give me the jeebies of the heebie kind.