According to abbreviationfinder, URI stands for Uniform Resource Identifiers. Short string of characters that uniquely identifies a resource (service, page, document, email address, encyclopedia, etc.). These resources are normally accessible on a network or system.
URI has a shared history with URL. In 1990, Tim Berners implicitly introduced the idea of a URL as a short string representing a resource that is the target of a hyperlink.
In the next 3.5 years, as the fundamental technologies of the World Wide Web of HTML (the HyperText Markup Language), HTTP, and web browsers, developed, the need to distinguish a string that provides an address of an emerged resource appears.
During the discussion on the definition of URLs and ballot boxes it became clear that the two concepts embodied by the terms were nothing more than aspects of the fundamental and general notion of resource identification. In June of 1994, the IETF published Berners-Lee RFC 1630: RFC first time (in its non – normative text) acknowledged the existence of URLs and urns, and, more importantly, a formal syntax defined hand Universal resource identifiers.
The publication of RFC 2396 in August of 1998 saw the URI syntax be a separate specification and most parts of RFCs 1630 and 1738 on the URI and URL, in general, have been revised and expanded. The new RFC changed the meaning of “U” into “URI”: it tried to represent “uniform” instead of “Universal”.
From December of 1999 to January of the 2005 is a period of community efforts, coordinated by RFC 2396 co-author Roy Fielding, to achieve publication of the version of the URI syntax from 2009 [update], it has the RFC 3986 version.
Parts that count
- Schema: name that refers to a specification to assign identifiers, eg urn:, tag:, cid:. In some cases it also identifies the access protocol to the resource, for example http:, mailto:, ftp:.
- Authority: hierarchical element that identifies the authority of names (for example //es.wikitel.info).
- Path: Information usually organized in a hierarchical way, which identifies the resource in the scope of the URI scheme and the naming authority (eg / wiki / Uniform_Resource_Identifier).
- Query: Information with a non-hierarchical structure (usually “key = value” pairs) that identifies the resource in the scope of the URI scheme and the naming authority. The beginning of this component is indicated by the ‘?’ Character.
- Fragment: It allows identifying a part of the main resource, or a view of a representation of it. The beginning of this component is indicated by the ‘#’ character.
Relationship of URI to URL and URN
The URL locator and URN name schemes function as resource identifiers, so URLs and URNs are subsets of URIs. A URI can be a URL locator, a URN name, or both. A URL is a URI that, in addition to identifying a resource (Web), allows acting on said resource, because it describes the access method. For example, the URL http://www.ecured.cu is a URI that identifies the EcuRed home page and implies that said web resource can be accessed through the HTTP protocol on a server called www.cured. cu. A Uniform Resource Name (URN) is a URI that identifies a resource by name, in a given XML space. A URN can be used to deal with a resource without expressing its location or how to access it. For example, the URN urn: isbn: is a URI that allows you to deal with a book by its ISBN number, but does not say where a copy of it is obtained.
A URI reference can take the form of a complete URI, or just the specific part of one’s scheme, or even some final component of it, even the empty string. An optional identifier fragment, preceded by #, can be present at the end of a URI reference. The part of the reference before the # indirectly identifies a resource, and the chunk identifier identifies a part of that resource. To obtain a URI from a reference URI, the software converts the reference URI to “absolute” form by merging it with an absolute “base” URI according to a fixed algorithm.
The system treats the URI reference as relative to the base URI, although in the case of an absolute reference, the base has no relevance. The base URI typically identifies the document containing the URI reference, although this can be overridden by statements made in the document or as part of an external data transmission protocol. If the base URI includes a chunk identifier, it is ignored during the merge process. If a chunk identifier is in the URI, it is preserved during the merge process. Web document markup languages frequently use URI references to point to other resources, such as external documents or specific parts of the logical document itself.
The current URI specification as of 2009 [update], RFC 3986, defines a reference URI as a reference to the same document, if when resolved absolutely, it is exactly equivalent to the base URI in the effect of the reference. Typically, the base URI is the URI of the document that contains the reference. XSLT 1.0, for example, has a document () function that, in effect, implements this functionality. RFC 3986 also formally defines URI equivalency, which can be used to determine that a URI reference, although not identical to the base URI, is still the same resource and therefore can be considered as a reference to the same document.
The syntax of a URI is: the URI scheme, such as “HTTP”, “FTP”, “mailto”, “URN”, “tel”, “rtsp”, “file”, etc., followed by the character: (two points) and a specific part of the scheme. The syntax and semantics of the specific-part are defined in the specification of each schema, although the syntax of the URI makes all the schemas follow certain common conventions that, among other things, reserve some characters for special uses (without there being any to say what special use it is), for example the% character. 1. ? RFC 2396 (Uniform Resource Identifiers: Generic Syntax)
Using case sensitive
According to the STD66 standard, the parts of a URI behave differently: The schema and the domain are case insensitive and therefore generalize as lowercase. The route, on the other hand, is sensitive, as is the request and the fragment. Of course, this sensitivity also depends on the server that is processing the address, since that server can be configured to normalize everything to lowercase. However, most servers, Apache in particular, respect capitalization in the appropriate parts.
Incorrectly (or it will be normalized to lower case): HTTP://www.DOMINIO.com/
Relative URIs are partial URIs, used to refer to a document from another on the same computer. In this way, we can define it, as the path that must be followed from the location of the current document (directory path) to the location of the referred resource, in addition to the file name. Suppose that the current document, located at ” http://servidor.es/documentos/index.asp “, needs to point to a document located at ” http://servidor.es/documentos/nuevos/mejores/dos.asp “. The relative URI to refer to that resource from the current document will be: “new / best / dos.asp” The special directory “…” provides a way to go back to the “parent” directory. So to point from ” http: “a” http://nuevoservidor.mil/documentos/antiguos/mejores/junio.htm “, the relative URI will be:”../../antiguos/mejores/junio.htm ”
To “resolve” a URI, either to convert a URI reference relation to absolute form, or to un-reference a URI or URI reference by trying to get a representation of the resources that identify it. The ‘resolution’ component in document processing software generally provides both services.
A URI reference can be thought of as a reference to the document itself: a reference to the document that contains the URI reference of itself. Document processing software can efficiently use your current document representation to satisfy the resolution of a referenced document itself without fetching a new representation. This is only a recommendation, and document processing software can also use other mechanisms to determine if a new representation should be obtained.