Ajaxian » URI vs. URL: What’s the difference?

Ajaxian » URI vs. URL: What’s the difference?

URI

A URI identifies a resource either by location or name. More often than not, most of us use URIs that defines a location to a resource. However, a URI does not have to specify the location of a specific representation. Citing and example of a W3C URI for their home image, they use the following URI: http://www.w3.org/Icons/w3c_home. Note the absence of a file extension. The URI for the w3c_home image is still universally unique, but it does not specify the specific representation of the image (either a GIF, PNG, or JPG). The selection of the representation can be determined by the web server through HTTP content negotiation. The Apache HTTPD server has had excellent support for content negotiation for many years. Oddly, few sites take advantage of HTTP content negotiation. The W3C is one web application that makes heavy use of URIs and content negotiation.

URL

A URL is a URI but a URI is not a URL. A URL is a specialization of URI that defines the network location of a specific representation for a given resource. Taking the same W3C example, there are actually 2 representations available for the w3c_home resource:

* http://www.w3.org/Icons/w3c_home.gif
* http://www.w3.org/Icons/w3c_home.png

These URIs also define the file extension that indicates what content type is available at the URL. Through content negotiation, the web server will forward the user agent to the proper type, depending on the client’s capabilities, when the URI http://www.w3.org/Icons/w3c_home is accessed.

More often than not, URI is the correct term to use when referring to the location of resources on the WWW.

Content negotiation - Wikipedia, the free encyclopedia

Content negotiation is a mechanism defined in the HTTP specification that makes it possible to serve different versions of a document (or more generally, a resource) at the same URI, so that user agents can choose which version fit their capabilities the best. One of the most classical uses of this mechanism is to serve an image as both GIF and PNG, so that a browser that doesn't understand PNG can still display the GIF version. To summarize how this works, it's enough to say that user agents are supposed to send an HTTP header (Accept) with the various MIME types they understand and with indications of how well they understand it. Then, the server replies with the version of the resource that fits the user agents' needs.