Steve Atkins wrote:
On May 4, 2008, at 9:02 AM, Christopher Laco wrote:
My pet peeve is that /foo/primary_key makes computers happy... but not
people.
/products/23
/products/ABC-1234
The first is the PK for a product record..
The second is the actual sku for a product... just a unique as the
pk...but not the PK itself...
Now what does "id" mean in this case?
What id your SKU is a numeric just like your PK?
Two different and equally useful ways to get at the same resource.
If you're talking about an interface where humans know the skus, and
computers know the id (restfully and/or remotely).. you need a sane uri:
/products/id/<id>
/products/sku/<sku>
In the end, I always run into a situation where humans (think
marketing SEO pushers who know not of REST) want something other than
a true restful uri.
Part of the problem here might be the wish to avoid a natural
primary key in the database schema, preferring a synthetic
primary key even when there's a perfectly good natural
primary key.
That's something that I expect to see from the ruby on
rails crowd, not the (presumably more pragmatic) perl folks.
If your SKU is unique, then it's a perfectly good primary
key, and having a synthetic numeric primary key isn't
necessary.
Not really. SKU is unique yes, but it can change (renamed, reconfigured
when companies merge, etc) for the same physical product. It's a poor PK
for the purposes of joining records to it, but a great key for the
purposes of lookup and selling the item.
One could argue that UPC is a better key than sku, but that's not very
friendly.
-=Chris
_______________________________________________
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/
