Abstract

A Uniform Resource Identifier (URI) identifies a resource in the context of the Web. A URI has several parts, most generally speaking a scheme (which indicates the way resources can be accessed), and a scheme-specific part. Rather than exposing a file system or similar resources through URIs, the namespace of a set of resources on the Web should be designed and maintained. This way, URIs can be used in a way which breaks fewer links by keeping URIs stable even when a Web site is completely redesigned and uses a different technology in its new incarnation.

URIs and URLs

• Uniform Resource Locator (URL) was the original term
• Uniform Resource Identifier (URI) was intended to be a generalization
  • a URI can either be a URL or a Uniform Resource Name (URN)
  • URNs are of the form urn:ietf:rfc:2648 and require a lookup service
  • several URNs are registered but support is not built into the mainstream browsers
• Distinguishing URLs and URNs is not easily possible
  • many URL schemes also introduce indirections
  • URNs are just one URI scheme among many others
• URL officially have been retired, there is no URL specification in force
  • technically, URL should be replaced with URI everywhere

Resource Identification

• The Web is centered around resources
  • HTTP has been designed to manipulate resources
  • HTTP provides methods for getting, putting, updating, and even deleting resources
• Resources are useful abstractions for interfaces
  • instead of an API, interaction is built around manipulating resources
  • does that sound familiar?
  • Document exchanges as components of business models
  • APIs change and bind closely, documents can better withstand change and bind loosely
  • the whole Web is built around resources, not APIs
  • Representational State Transfer (REST) is the principle behind this design

URI Schemes

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

• URIs in their general case are very simple
  • the scheme identifies how resources are identified
  • the identification may be hierarchical or non-hierarchical
• Many URI schemes are hierarchical
  • it is then possible to use relative URIs such as in a href="../"
  • the slash character is not just a character, in URIs it has semantics

[...] the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.

Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, January 2005

Query Information

• Query components specify additional information
  • it is non-hierarchical information further identifying the resource
  • in most cases, it can be regarded as input to the resource

The query component contains non-hierarchical data that, along with data in the path component [...], serves to identify a resource within the scope of the URI's scheme and naming authority [...].

Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, January 2005

Processing URIs

• Processing URIs is not as trivial as it may seem
  • escaping and normalization rules are non-trivial
  • many implementations are broken
  • complain about broken implementations
• URIs are not just strings
  • URIs are strings with a considerable set of rules attached to them
  • implementing all these rules is non-trivial
  • implementing all these rules is crucial
  • application development environments provide functions for URI handling

Resources vs. Representations

• URIs identify resources
  • abstractions which may not have physical representation
• Requesting a URI yields a resource representation
  • should be an appropriate and useful manifestation of the abstraction
• Resources can have different representations
  • in a well-designed environment, you should get what works best for you

Bad Service

What's Bad?

• Implementation issues should not be reflected in the URI
  • .do is probably indicating a Java/struts implementation
  • if the implementation changes, existing bookmarks will break
• Index pages should be named as such
  • the index is simply the page identified by no name
• Resources should be delivered in an appropriate way
  • screen size is an important parameter

Popular Screen Resolutions

URI Design

• URIs should be carefully designed names for resources
• Many Web sites are built the other way around
  • resources are created and stored in a storage structure (such as a file system)
  • the file system (or application resource) structure is exposed as URIs (ISO)
  • CMS-based solutions are even worse sometimes (http://.../content/node-36328.html)
• Bad name choices result in bad Web sites
  • users cannot bookmark resources (if there is no persistent URI)
  • bookmarks break often (if site redesigns change URIs)
  • users cannot navigate the site (if there is no hierarchical namespace)

Web Site Structure

• Most Web sites are not strictly hierarchical
  • there are various possible ways to get to a resource
  • creating a main structure is a bit artificial, but also beneficial
• Hierarchical structures enable easy navigation and generate URIs
  • alternative paths can be provided as well, but are across the main structure
  • any non-trivial Web site should have a search feature anyway
• Web site planning should start early with creating a hierarchical structure
  • dynamically generated pages to persistent resources should have URIs as well
  • http://.../products/bikes/road/2007/letour
• Problem Space vs. Solution Space
  • Web site planning should not involve implementation issues

URIs vs. File Systems

• URIs should be well-designed and managed resource identifiers
• File names are transient names in a temporary storage medium
• URIs should not expose the file extension
  • unnecessary detail, implementation-dependent, security issues, URI lifetime
• URIs should not expose the resource language
  • resources and representations are separate issues
• URIs should not expose the directory index name
  • unnecessary detail, prevents URI-based navigation, URI lifetime

Persistent URIs

• Changing URIs means renaming important assets (important to you and others)
  • we just broke all your bookmarks by improving our Web site
  • we could not figure out a structure, so we did not implement one
  • we thought you might be interested how our new file system looks
• What to leave out
  • authors name
  • subject
  • status
  • access
  • file name extension
  • software mechanisms
• Store everything as resource metadata and provide search facilities
  • this also is a good way to manage various resource variants

URIs as Interfaces

• URIs can be considered a part of the UI
• Web servers provide support for improving the interface
  • mod_rewrite rewrites requested URIs on the fly
  • mod_mime and mod_mime_magic for handling resource types and variants
  • mod_speling tries to fix spelling errors in invalid URIs
• URI design is not as obvious as visual UI design
  • but it is an important factor in a site's usability and accessibility
  • usability testing should include tasks with URI-related activities

Generic Links

• Links on Web pages should always be generic
  • they should identify a resource, not a specific resource variant
  • http://.../en/products is not a good link (and not a good URI)
• Many Web pages use redirects for delivering resource variants
  • this is bad design because it hardcodes variant information into the URI
  • bookmarks will point to variants and not to resources
  • links being created on the pages should not point to variants
• Links should be as generic as possible
  • Content Negotiation can then be used to negotiate the best variant dynamically
  • when switching languages or screens, bookmarks will still work as expected

Handle With Care

• Web resources should be treated carefully
• Web site design starts with URI design
• Web Services should also be based on URIs (REST)
• Think about URIs without thinking about implementations
• URI design is not hard, but often neglected