On Sun, May 4, 2008 at 6:06 PM, J. Shirley <[EMAIL PROTECTED]> wrote: > 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.
Then we are talking about two diffrent things. My point is that you should not have /foo/create and foo/{id or token} - because you mix a reserverd work 'create' with data, you can never guarantee that the data, be it primary key or token or whatever, does not contain 'create'. I do understand that in full REST design you would not have a '/foo/create/' uri - but if you want to add this REST as an add-on to a controller you'll still have other methods on the controller that could conflict with the token/id. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ _______________________________________________ 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/