10 March 2007


PUT remains one of the most confusing HTTP verbs because it is so frequently misdescribed, even by people who really do know better. The common description is that PUT is for UPDATE and POST is for creating new resources; and this is wrong, wrong, wrong.

Source: PUT is not UPDATE

Elliote is dead on here. I am guilty of comparing REST to SQL CRUD, including PUT == UPDATE. Upon reflection, however, I always thought of a "complete" update...comparable to Eliotte's DELETE then INSERT with the same primary key. Nevertheless, despite intentions, UPDATE does carry certain connotations.

Elliote references Joe Gregio's pioneering thoughts on REST from 3 years ago. It doesn't seem to suggest that PUT == "partial" UPDATE. I recall a Roy Fielding quote (but couldn't find the reference) in saying PUT is not a byte for byte replacement of the resource by the exact contents of representation. Rather, the server interprets the representation, but does in fact update the entire resource with information from the representation.

Joe does place a disclaimer in the very article that it is dangerous to begin thinking of REST in terms of SQL tables.

I hesitated to include this table. By presenting it, I wanted to point out the overlap in the four basic methods of HTTP. What I don't want to happen is that you start thinking of web resources as SQL tables. Don't do that.

Source: How to Create a REST Protocol

So it seems the lesson (finally) learned by myself is to not describe REST to people in terms of ambiguous SQL idioms. There is some overlap, but no absolutes. If the SQL comparison is necessary, disclaim the caveats upfront.

It's difficult to avoid thinking interms of SQL. Especially for me, having taking three courses on relational algebra in college. Opposite of my upbringing, however, traditional relational databases will be marginalized over the next decade as more specialize data systems become evident (i.e. BigTable).