Design Cool URIs
On the conceptual design side of uris, Sir Tim Berners Lee proposes the notion of Cool uris to guarantee that uris are maintainable, persistent and simple (see w3.org/TR/cooluris/). To ensure sustainable uris, it is important to design a “cool” uri scheme that doesn't change over time. To do so one has to follow these basic rules, resumed in Fig. 7:
• Make the uri independent from the underlying technology used to generate or describe the resource. This means avoid extensions such as .php, .cgi and
.html in the uri path. To know what to return when a resource is requested (without any extension), it is recommended to implement a content negotiation mechanism in the http server that is able to outstream the appropriate content.
• Make also the uri independent of the physical location of the ﬁle describing the resource. Never forget that physical locations are subject to change.
• Make sure that resource metadata are not included in the uri because of their evolution over time. In other words, one has to not encode the following in the uri the authorship, the status of the resource (ﬁnal, old, latest, etc.), the access rights (public, private, etc.) since this may change over time.
Fig. 7. URI Design rules
Opaque vs. Non opaque URIs
Designing mnemonic and readable uris for identifying business resources can help human users to get preliminary knowledge on the targeted item. However, from a business point of view, this readability may have side eﬀects if it also reveals an internal organisation system structure. Non Opaque uri may reveal conceptual structure but never should reveal physical or logical data structures. In fact, third party users or external applications can attempt to hack the uri scheme, reverse engineer all business resources and abuse the access to some strategic assets. When there are security risks, it is recommended to use opaque uris instead of readable ones. An opaque uri is a uri conforming to a scheme that satisﬁes the following conditions:
• Addressable and accessible resources should be referenced by identiﬁers instead of human readable labels.
• The resource uri should not contain explicit path hierarchy that can be hacked to retrieve sibling resources for example.
• The uri content should not provide means to gain information on the referenced resource, i.e., a third party client cannot analyse the uri string to extract useful knowledge on the resource.
For non-opaque uri, only the ﬁrst constraint is not followed.