Now I like non-opaque URIs, to me they make sense and the single redirect also makes sense, as does the navigation approach you suggest.
My issue was with any standard using the phrase "arbitrary" in connection with a SHOULD NOT as its very hard to see any scenario where it could be defined as arbitrary unless using purely opaque URIs which are generated just by random. In your example below though would the sku specific order include the full order, or just the part of it that relates to that sku? Steve On 25/04/2008, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > I have my issues with the AWWW v1. > > From a resource modeling perspective, I'd like the option of > navigating to a resource through multiple paths, e.g.: > > http://www.example.com/parts/sku1234/orders/order56789 > http://www.example.com/customers/cust23457/orders/order56789 > > These are not arbitrary URIs. They also are not especially opaque > because the path provides semantic information. > > Now, as Stefan recommends, both of these URIs should be redirected to > a single URL, e.g.: > > http://www.example.com/orders/order56789 > > But I much prefer this URL to something truly opaque like: > > http://www/example.com/123453456234511111 > > Anne > > > On Thu, Apr 24, 2008 at 1:59 PM, Steve Jones <[EMAIL > PROTECTED]<jones.steveg%40gmail.com>> > wrote: > > > > > > > > > > > > > > On 24/04/2008, Stefan Tilkov <[EMAIL PROTECTED]<stefan.tilkov%40innoq.com>> > wrote: > > > On Apr 24, 2008, at 7:00 PM, Steve Jones wrote: > > > > On 22/04/2008, Nick Gall <[EMAIL PROTECTED]<nick.gall%40gmail.com>> > wrote: > > > > > > > > > [snip] > > > > > For example, the AWWW v1 contains the following practice that is > > > > not strictly required by REST: > > > > > > > > > > > > > > > Good practice: Avoiding URI aliases -- A URI owner SHOULD NOT > > > > associate arbitrarily different > > > > > URIs with the same resource. > > > > > > > > I've wondered about this phrase. Given that arbitrarily means sort of > > > > random or on a whim it is an odd phrase as it implies you can do it > > > > deliberately if you want but don't be random about it. Given that > > > > URIs can (should?) be opaque its hard to see what it is actually > > > > forbidding. > > > > > > > > > > > > > > > > > The point here is mainly that the abilities for caching are hurt if > > > different URIs are used for the same thing. I would consider it > > > preferable to rarely use multiple URIs for the same resource, and if > > > so, redirect the aliases to the 'canonical' one. > > > > Now that make sense, but surely then the statement above doesn't need > > the words "arbitrarily different" which add nothing except confusion > > (IMO) to the definition. It then becomes a much simpler, and > > understandable, statement which offers guidance. Its not a MUST NOT > > but its a strong guidance. > > > > Steve > > > > > > > > > > Stefan > > > -- > > > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > > > > > > > > > > > > > > I've never actually seen a system in which people did random > > > > assignment of important objects under different names, except of > > > > course in C when people screwed up their pointers. > > > > > > > > Steve > > > > > > > > > > > > > [snip] > > > > > -- Nick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > >
