Uniform Resource Identifier
Uniform Resource Locator
What are they, simply?
These terms are coined by the RFC (Request for Comments), which is very, very unclear about their particular uses.
Tl;dr the sum is that all URL’s are URI’s, whereas not all URI’s are URL’s. URI’s are the major superset of all resource identifiers, as they come in other forms than URL’s.
For example, anything starting with http:// or https:// that you type into a web browser is going to be a URL, whereas typing something like 127.0.0.1 to enter your localhost can be considered a URI!
Why the confusion?
The RFC has three different definitions throughout the RFC manual specifying the difference as follows:
Each URI begins with a scheme name, as defined in Section 3.1, that refers to a specification for assigning identifiers within that scheme.RFC 3986; Section 1.1.1
A URI can be further classified as a locator, a name, or both. The term “Uniform Resource Locator” (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”).RFC 3986; Section 1.1.3
The URI itself only provides identification; access to the resource is neither guaranteed nor implied by the presence of a URI.RFC 3986; Section 1.2.2
Now with three different definitions, where do you begin to outline what it actually means? Well starting from the top, URI’s begin with scheme names. Here are some random ones I picked out of IANA’s list.
Resource Identifier (RI) Scheme name: afp Status: provisional Scheme syntax: over TCP/IP: afp://[<user>@]<host>[:<port>][/[<path>]] or over AppleTalk: afp:/at/[<user>@]<host>[:<zone>][/] Scheme semantics: Accessing Apple Filing Protocol shares Encoding considerations: Unknown, use with care. Applications/protocols that use this scheme name: Interoperability considerations: Unknown, use with care. May be unsuitable for open use on the public internet. Security considerations: Unknown, use with care. Contact: Registering party: Dave Thaler <dthalerµsoft.com> Scheme creator: Apple Author/Change controller: Either the registering party or someone who is verified to represent the scheme creator. See previous answer. References: http://en.wikipedia.org/wiki/Apple_Filing_Protocol#The_Mac_OS_X_client, http://tools.ietf.org/html/draft-ietf-svrloc-afp-service
Resource Identifier (RI) Scheme name: ms-settings: Status: provisional Scheme syntax: ms-settings:[<path>] (Where <path> is a non-hierarchical path. It does not include the slash character ("/"). Instead, it uses the dash character ("-") for semantic, hierarchical and other purposes) Scheme semantics: Launches the settings application Encoding considerations: Unknown, use with care Applications/protocols that use this scheme name: Settings application in Windows Interoperability considerations: None Security considerations: None Contact: Zakir Gazizov, zakirgaµsoft.com Darryl Brown, darrylbµsoft.com Author/Change controller: urischemeownersµsoft.com Note: This scheme is for private use on specific devices, and SHOULD NOT be used on the open Internet
You get the idea. The important parts are the sections highlighted by Schema Syntax which has to be embedded in the file for the information to be able to be extracted.
How does this differ to URL’s?
Well, URL’s have a similar “schema” if you will, however it’s way more simple and auto-generated. An example of a URL schema would require a http:// or https:// root. The file types, such as .xml, .xhtml, and structured data markup are technically considered schema’s as well, but not top level schema’s, because they are subject to http:// or https://, not the other way around.
URI’s have a much deeper schema organisation that relates to a website-server interaction, which URL’s do too, but there exist more types of URI’s than types of URL’s.