On Fri, Apr 25, 2008 at 7:57 AM, 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
The point of my bringing up the AWWWv1 was simply to demonstrate that there are more principles that constrain Web architecture than just REST. Hence a different term is needed. Whether that term is WOA or simply "Web Architecture" or "AWWW" or "Web-Style" ... the community of interest will decide. As for the "avoid URI aliasing principle", it is based on the fundamental principle of "network effects" as the AWWW explains: Although there are benefits (such as naming flexibility) to URI aliases, there are also costs. URI aliases are harmful when they divide the Web of related resources. A corollary of Metcalfe's Principle (the "network effect") is that the value of a given resource can be measured by the number and value of other resources in its network neighborhood, that is, the resources that link to it. The problem with aliases is that if half of the neighborhood points to one URI for a given resource, and the other half points to a second, different URI for that same resource, the neighborhood is divided. Not only is the aliased resource undervalued because of this split, the entire neighborhood of resources loses value because of the missing second-order relationships that should have existed among the referring resources by virtue of their references to the aliased resource. A simple example of this problem in action is when two groups of people bookmark (say via delicious) the same resource using different URLs. Now the two communities miss the benefits of each other's comments. I agree the advice could be better expressed (and it is better expressed elsewhere), but the principle is a sound one: do what you can to maximize the network effect of a URL (eg redirects and embedding the cannonical URL in the representation returned as ATOM enables you to do). As for URL opaqueness, this principle has been widely misunderstood. It should have been called something like: Don't make users guess the meaning of a URL -- document it. Again, the AWWW provides clarification by referencing http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061204.htmlfor a more detailed discussion. Three principles from that document that are relevant in this context are: 1. *Constraint:* Web software MUST NOT depend on the correctness of metadata inferred from a URI, except when the encoding of such metadata is documented by applicable standards and specifications. 2. *Good Practice:* URIs intended for direct use by people should be easy to understand, and should be suggestive of the resource actually named. 3. *Good Practice:* URI assignment authorities and the Web servers deployed for them may benefit from an orderly mapping from resource metadata into URIs. So your two more readable examples above are perfectly fine -- as long as they are documented. For an example of sufficient documentation, the TAG provides this simple example: "For the best weather information for your city, visit http://example.org/weather/*your-city-name-here*."; -- Nick
