Exactly! I agree Nick's comments on opaqueness, and I think he said it pretty well. I think the number of URLs that you make "human friendly" and are prepared to support from a system perspective should be kept to the minimum that makes sense.
This is a trade-off, of course, but my rule of thumb is that each human-readable URL should be a separate service. For example, http://mysite.com/mail should be your electronic mail, but you shouldn't go as far as http://mysite.com/mail/inbox. This also comes back to my (much at this stage) earlier thoughts on REST APIs, because you should only need to give the client a well-known URL as the entrypoint and then it should only be able to do what the service tells it it can via hypermedia exchange. If you expose URLs to spidering, that's a bit different in that you have to make a commitment to supporting them once they're made public. However, that doesn't mean that URLs that aren't the "front door" to your service are good candidates for being non-opaque. I think URI design is difficult to do well, because it's based on a set of assumptions that may change over time. Many times I've thought I had a good strategy designed that eventually broke down for some reason as the site/service evolved. Keeping the URIs that encourage users to type them into the browser to the minimum helps you more gracefully evolve your service. For the most part, once the user is using the service (automated or interactively), the URLs shouldn't matter much as long as they're pretty stable. If users regularly need to type opaque URLs in to a browser, there's a problem with your service design and information architecture rather than with the URL. Cheers, ast On Sat, 2008-04-26 at 05:33 +0000, Rob Eamon wrote: > Ah, I see. Much like "intelligent keys" where a caller assume chars 4- > 11 are the account number so they don't query for the account number. > Makes sense. > > Thanks for the info! > > -Rob > > --- In [email protected], "Andrew S. > Townley" <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2008-04-25 at 14:53 +0000, Rob Eamon wrote: > > > > But I much prefer this URL to something truly opaque like: > > > > > > > > http://www/example.com/123453456234511111 > > > > > > Perhaps you've covered this before, but what is the rationale > > > behind using an artificial key in this context? > > > > > > > You mean besides ensuring that whomever is using it can't make any > > assumptions about the URL and they have to treat it like "just" an > > identifier, e.g. URI? ;) > > > > While they can be useful, inferring semantics from a URI without a > > specification that says you can and a commitment to ensuring the > > spec is followed is to start down a slippery slope sure to end in > > disaster (and spending a lot of money at some stage). > > > > It also gives you more architectural flexibility in your > > implementation without having to support a bunch of different URI > > namespaces. > > > > There are other advantages, but those are the primary ones I see. > > > > HTH, > > > > ast > > -- > > Andrew S. Townley <[EMAIL PROTECTED] > > http://atownley.org > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > -- Andrew S. Townley <[EMAIL PROTECTED] http://atownley.org
