I think that there are two distinct uses of URIs. There are URIs that are never intended to be typed by people (or at least don't need to be), and there are URIs that only people will type.
Namespaces that are recognizable in typed URIs are a convenience to users. It allows them to do things with your service that you might not have known how to architect into a particular flow that you designed in your "client" application. As soon as you publish a URI, in some form, then you have committed to that. If the URI structure changes, then you invalidate all "old" clients using the old structure. So, at some level, you always have "committed" to a particular URI structure, and whether you use ?pic=3123312332132 or /pictures/2008/12/02/pic1.jpg, you have to honor that structure and perform the right processing somewhere in your system. This is one of the primary reasons that I think that URIs don't really provide any real abstraction. Instead, they just provide a namespace, and it can be equally represented as a programming language method signature or some such. Providing something that the clients can use as easily and as effectively as possible to gain all the power of the service that is available is what adds the most value. Gregg Wonderly 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] > <mailto:service-orientated-architecture%40yahoogroups.com>, "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 > <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 <http://atownley.org> > > > >
