Overview#

Uniform Resource Identifier (URI) is a string of characters used to identify a name of a resource.

Such identification enables interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols.

Schemes specifying a concrete syntax and associated protocols define each URI. The most common form of URI is the Uniform Resource Locator (URL), frequently referred to informally as a web address. More rarely seen in usage is the Uniform Resource Name or (URN), which was designed to complement URLs by providing a mechanism for the identification of resources in particular namespaces.

Syntax#

The Uniform Resource Identifier syntax consists of a Uniform Resource Identifier scheme name (such as "http", "ftp", "mailto", "crid" or "file") followed by a colon character, and then by a scheme-specific part.

The specifications that govern the schemes determine the syntax and semantics of the scheme-specific part.

However, URI syntax does require all schemes to adhere to a general syntax that (among other things) reserves certain characters for special purposes (without always identifying those purposes).

The URI syntax also enforces restrictions on the scheme-specific part in order to (for example) provide for a degree of consistency when the part has a hierarchical structure.

Internet standard STD 66 (also RFC 3986, RFC 6874 and RFC 7320) defines the generic syntax to be used in all URI Schemes.

Every Uniform Resource Identifier is defined as consisting of several parts, as follows:

                    hierarchical part
        ┌───────────────────┴─────────────────────┐
                    authority               path
        ┌───────────────┴───────────────┐┌───┴────┐
  abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
  └┬┘   └───────┬───────┘ └────┬────┘ └┬┘           └─────────┬─────────┘ └──┬──┘
scheme  user information     host     port                  query         fragment

  urn:example:mammal:monotreme:echidna
  └┬┘ └──────────────┬───────────────┘
scheme              path

A typical Uniform Resource Identifier might look like:

URI = <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]

For the particular case of the HTTP (and HTTPS) scheme, defined on RFC 7230, the syntax becomes:

http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]

Uniform Resource Identifier Components#

  • URI Scheme
  • Hierarchical - The hierarchical part of the URI is intended to hold identification information hierarchical in nature. If this part begins with a double forward slash ("//"), it is followed by an authority part and a path. If the hierarchical part doesn't begin with ("//") it contains only a path.
  • URI Authorities
  • URI Path
  • URI Query
  • URI Fragment Identifiers

Alternatives to Specifying Structure in URIs (From RFC 7320)#

Given the issues described in RFC 7320 Section 1, the most successful strategy for applications and extensions that wish to use URIs is to use them in the fashion they were designed: as links that are exchanged as part of the protocol, rather than statically specified syntax.

Several existing specifications can aid in this.

  • RFC 5988 specifies relation types for Web Linking. By providing a framework for linking on the Web, where every link has a relation type, context and target, it allows applications to define a link's semantics and connectivity.
  • RFC 6570 provides a standard syntax for URI Templates that can be used to dynamically insert application-specific variables into a URI to enable such applications while avoiding impinging upon URI owners' control of them.
  • RFC 5785 allows specific paths to be 'reserved' for standard use on URI Schemes that opt into that mechanism ('http' and 'https' by default). Note, however, that this is not a general "escape valve" for applications that need structured URIs; see that specification for more information.

Specifying more elaborate structures in an attempt to avoid collisions is not an acceptable solution, and does not address the issues in RFC 7320 Section 1. For example, prefixing query parameters with "myapp_" does not help, because the prefix itself is subject to the risk of collision (since it is not "reserved").

URIs, URLs, and URNs#

What is the difference between URIs, URLs, and URNs?

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-9) was last changed on 23-Apr-2017 09:45 by jim