On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote: > > Sorry but I don't understand your point - so maybe first I'll restate > mine. If you have primary key in the database that is of type varchar > (or char or ...) then 'create' is a legitimage value for that primary > key. > > If you just don't like the string 'id' in the URI - then I have not > any preference to that - it can be /foo/primary_key/ for me. >
My point is that you do not have to use the primary key as the record lookup identifier. A user has no control over the record lookup identifier (ID) when you do things like /user/{primary_key} (or /user/id/{primary_key}, which is just converting named params to positional in a weird way). In a lot of cases, the record lookup identifier makes more sense to be somewhat bound to the user. As an example, lets say registering for a web service where you have to have a unique login: POST /user/jshirley --- login: jshirley first_name: Jay last_name: Shirley ... Now, it's a simple check here - does /user/jshirley exist? If so, reject the request appropriately. If not, create the user at /user/jshirley. The primary key that the database uses is completely useless to the user. /user/1634254 is silly, /user/jshirley is meaningful. If the ID is generated, that gets a bit trickier but I usually handle that with a POST to /user with the data and then let the application forward me to the final URL of where the resource exists. The other reason is that this system breaks when you no longer have records tied to a database. As an example, if you use an md5 sum of a file as the identifier. /file/1234 doesn't work because it isn't in a database under that system (think of a MogileFS cluster or something with hash keys rather than primary keys in the conventional sense) - instead /file/{md5sum} is used. In brief summary, over-utilization of primary keys as record lookup identifiers ends up diminishing the human readability and accessibility of your web service. I'm not trying to win over any converts, because I think there is a time and a place for each (even in the same application, it just depends upon what each action is really doing). If I'm not building something that is REST/webservice driven I tend to do the /user/{id or token} (with a simple regex to check, and if someone has a login of all numbers then screw 'em) - but it's a very different strategy when I work with webservices -- each time I always make sure if the record lookup indicator should be the primary key, and what cases should it not and then react accordingly. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/