HTTP says nothing about hierarchy in URI paths

http does not interpret the request uri

so make the path component of the request-uri /uuid and be done with it

at the level of the http interface, a request-uri equivalent to a key in a dictionary lookup

this is more or less what i understand document-oriented databases to do

(i haven't used one yet, because i'm doing more or less the same thing but with triple stores)

conclusion: the system can and should be completely oblivious to the content of the uri except to locate a resource

in REST, the clients are not expected to infer any meaning in the uri, as it is supposed to be provided by hypertext

but if hypertext is supposed to provide access to the full range of resources in and around a particular system, that puts a significant strain on its authors.

Path hierarchies are a historical artifact

path

HTTP URIs are clearly modeled after POSIX file paths, with the // before the authority reminiscent of UNC paths. The URI grammar has been designed to reflect a hierarchy of decreasing significance and increasing specificity of a given identifier from its left side to its right. The URI specification defines the path component as depicting a hierarchy, and has been explicitly designed so that the ./ and ../ relative path segments behave as they do under POSIX.

There is no deliberation that the Web was intended, at least initially, to capitalize on the infrastructure provided by a typical workstation of the era. In addition to the co-opting of the hierarchical file system, HTML was conceived as a subset of SGML, which could be freely composed with any generic text editor.

Despite a historical connection to file system hierarchies, Sir Berners-Lee has emphasized in numerous accounts that the shape of the Web is and ought to be a web — that is, a graph, which has no intrinsic concept of hierarchy. As we have seen, the HTTP protocol treats the content of the request-URI as opaque,

query

the html spec defines form data as a set of key-value pairs.

when a form method is GET, a query string is composed from the form data (usually in document order but not guaranteed to be), supplanting any existing query string supplied to the form's @action (note, the spec says appended, but one would hope it would supplant)

when a form method is POST, the query string in @action is left alone (we hope, the spec doesn't say anything about it. open question: how do browser implementations behave)

this is echoed on the server side with cgi libraries (which are concerned with the contents of HTML forms) and subsequent technologies (php, asp, jsp, coldfusion, etc)

What does the system need?

The UUID could serve as the key to uniquely identify the resource

We could trade in all URI paths for UUIDs e.g. http://example.com/efe7ed84-42e4-44e1-9117-da07f70b5a29 with no loss of functionality from the point of view of the system.

In fact, we would gain functionality, because notwithstanding deletions, links wouldn't break anymore because there would be few reasons to ever rename or mint a second UUID for the same object.

This idea is closely aligned with key-value and document-oriented databases, which have recently found a resurgence of popularity under the moniker NoSQL.

URIs are both content and UX

understandable URIs with discernible anatomies are more than just a historical artifact

uris are content as well as ux, which means they should be controllable by content strategists, information architects and interaction designers.

Abandon strict hierarchies

what's the best you've got? a card sort?

Flatten the namespace

the requirement of the system is that it needs unambiguous keys with which to look up resources

if you did away with hierarchical components you would quickly run out of useful (readable, understandable) symbols to use