You are going to contend that users should just try URLs until they find something? Nonsense. And yes, it does make sense that URL(1) can point to more than one thing (it is, after all, only one layer beneath the top of the site, so the specificity is minimal unless you have a VERY small product list). URLs are not meant to be accessible, and if they are at all specific in a non-trivial site schema, they will be inaccessible due either to length
Specificity breeds inaccessibility, and merely reading someone's monograph does not change that -- a forty-foot URL is no more "accessible" than a 32-character UNID. That which shows in the address bar (beyond the site root) is for the machine -- links, searches and other user tools is what brings the human to the data.
"Friendly" URLs may look pretty, but they mean bloated view indexes, extra views (by the score, in this case), and reduced performance. And it still doesn't add to usability or accessibility. Decent, usable navigation will get you to the same place without making the application unworkable.
(And yes, I also pooh-pooh REST as a web service access method, since it can do so little compared to POST/SOAP and parametered GETs unless the URL is so contrived as to be meaningless again. Not to mention that everything's passed in the clear, which is also a problem with GET.)
You are going to contend that users should just try URLs until they find something? Nonsense. And yes, it does make sense that URL(1) can point to more than one thing (it is, after all, only one layer beneath the top of the site, so the specificity is minimal unless you have a VERY small product list). URLs are not meant to be accessible, and if they are at all specific in a non-trivial site schema, they will be inaccessible due either to length
.../mysite.nsf/products/fasteners/MILSPEC/threaded/hex/UNC/SWIRE/3%2F8/1-3%2F4/...etc
or to obscurity
.../mysite.nsf/products/fasteners/AN180976-17A/1-3%2F4
(not unlike a Domino unid) or to encoding
.../mysite.nsf/products/fasteners/threaded/3%2F8UNC%20x%201-3%2F4%20Hex%20safety%20wire%20drilled
Specificity breeds inaccessibility, and merely reading someone's monograph does not change that -- a forty-foot URL is no more "accessible" than a 32-character UNID. That which shows in the address bar (beyond the site root) is for the machine -- links, searches and other user tools is what brings the human to the data.
"Friendly" URLs may look pretty, but they mean bloated view indexes, extra views (by the score, in this case), and reduced performance. And it still doesn't add to usability or accessibility. Decent, usable navigation will get you to the same place without making the application unworkable.
(And yes, I also pooh-pooh REST as a web service access method, since it can do so little compared to POST/SOAP and parametered GETs unless the URL is so contrived as to be meaningless again. Not to mention that everything's passed in the clear, which is also a problem with GET.)