Identificador uniforme de recursos

Un identificador uniforme de recursos (URI) es una secuencia única de caracteres que identifica un recurso lógico o físico utilizado por las tecnologías web. Los URI se pueden usar para identificar cualquier cosa, incluidos objetos del mundo real, como personas y lugares, conceptos o recursos de información, como páginas web y libros. Algunos URI proporcionan un medio para ubicar y recuperar recursos de información en una red (ya sea en Internet o en otra red privada, como un sistema de archivos de computadora o una Intranet); estos son localizadores uniformes de recursos (URL). Una URL proporciona la ubicación del recurso. Un URI identifica el recurso por su nombre en la ubicación o URL especificada. Otros URI brindan solo un nombre único, sin un medio para ubicar o recuperar el recurso o información sobre él, estos son Nombres de recursos uniformes (URN). Las tecnologías web que utilizan URI no se limitan a los navegadores web. Los URI se utilizan para identificar todo lo que se describe mediante el marco de descripción de recursos (RDF), por ejemplo, los conceptos que forman parte de una ontología definida mediante el lenguaje de ontología web (OWL) y las personas que se describen mediante el vocabulario Amigo de un amigo. tener un URI individual.

Historia

Concepción

Las URI y las URL tienen un historial compartido. En 1990, las propuestas de hipertexto de Tim Berners-Lee introdujeron implícitamente la idea de una URL como una cadena corta que representa un recurso que es el objetivo de un hipervínculo. En ese momento, la gente se refería a él como un "nombre de hipertexto" o "nombre del documento".

Durante los siguientes tres años y medio, a medida que se desarrollaban las tecnologías centrales de HTML, HTTP y los navegadores web de la World Wide Web, surgió la necesidad de distinguir una cadena que proporcionaba una dirección para un recurso de una cadena que meramente nombrado un recurso surgido. Aunque aún no se ha definido formalmente, el término Localizador Uniforme de Recursos pasó a representar el primero, y el más polémico Nombre Uniforme de Recursos pasó a representar el segundo. En julio de 1992, el informe de Berners-Lee sobre el IETF "UDI (Universal Document Identifiers) BOF" menciona URLs (como Localizadores Uniformes de Recursos), URNs (originalmente, como Números Únicos de Recursos) y la necesidad de establecer un nuevo grupo de trabajo. En noviembre de 1992, el IETF "Grupo de trabajo URI" conoció por primera vez.

Durante el debate sobre la definición de URL y URN, se hizo evidente que los conceptos representados por los dos términos eran simplemente aspectos de la noción fundamental y general de identificación de recursos. En junio de 1994, el IETF publicó la primera Solicitud de comentarios de Berners-Lee que reconocía la existencia de URL y URN. Lo que es más importante, definió una sintaxis formal para Identificadores de recursos universales (es decir, cadenas similares a URL cuyas sintaxis y semántica precisas dependían de sus esquemas). Además, el RFC 1630 intentó resumir la sintaxis de los esquemas de URL que se usaban en ese momento. Reconoció, pero no estandarizó, la existencia de URL relativas e identificadores de fragmentos.

Refinamiento

En diciembre de 1994, RFC 1738 definió formalmente las URL relativas y absolutas, perfeccionó la sintaxis de URL general, definió cómo convertir las URL relativas en forma absoluta y enumeró mejor los esquemas de URL que se usaban en ese momento. La definición y la sintaxis acordadas de URN tuvieron que esperar hasta la publicación de IETF RFC 2141 en mayo de 1997.

La publicación de IETF RFC 2396 en agosto de 1998 hizo que la sintaxis de URI se convirtiera en una especificación separada y la mayoría de las partes de RFC 1630 y 1738 relacionadas con URI y URL en general fueron revisadas y ampliadas por IETF. El nuevo RFC cambió el significado de "U" en "URI" a "Uniforme" de "Universal".

En diciembre de 1999, RFC 2732 proporcionó una actualización menor a RFC 2396, lo que permitió que los URI admitieran direcciones IPv6. Varias deficiencias descubiertas en las dos especificaciones dieron lugar a un esfuerzo de la comunidad, coordinado por el coautor de RFC 2396, Roy Fielding, que culminó con la publicación de IETF RFC 3986 en enero de 2005. Aunque dejó obsoleto el estándar anterior, no proporcionó los detalles. de esquemas de URL existentes obsoletos; RFC 1738 continúa rigiendo dichos esquemas excepto donde se reemplace de otra manera. IETF RFC 2616, por ejemplo, refina el esquema http. Simultáneamente, el IETF publicó el contenido de RFC 3986 como el estándar completo STD 66, lo que refleja el establecimiento de la sintaxis genérica de URI como protocolo oficial de Internet.

En 2001, el Grupo de arquitectura técnica (TAG) del W3C publicó una guía de prácticas recomendadas y URI canónicos para publicar varias versiones de un recurso determinado. Por ejemplo, el contenido puede diferir según el idioma o el tamaño para ajustarse a la capacidad o la configuración del dispositivo utilizado para acceder a ese contenido.

En agosto de 2002, IETF RFC 3305 señaló que el término "URL" había, a pesar del uso público generalizado, casi obsoleto, y sirve solo como un recordatorio de que algunos URI actúan como direcciones al tener esquemas que implican accesibilidad a la red, independientemente de cualquier uso real. Como lo hacen evidente los estándares basados en URI, como Resource Description Framework, la identificación de recursos no necesita sugerir la recuperación de representaciones de recursos a través de Internet, ni implicar recursos basados en red en absoluto.

La web semántica utiliza el esquema HTTP URI para identificar documentos y conceptos en el mundo real, una distinción que ha causado confusión sobre cómo distinguirlos. El TAG publicó un correo electrónico en 2005 sobre cómo resolver el problema, que se conoció como la resolución httpRange-14. Posteriormente, el W3C publicó una nota de grupo de interés titulada Cool URIs for the Semantic Web, que explicaba con más detalle el uso de la negociación de contenido y el código de respuesta HTTP 303 para las redirecciones.

Diseño

URL y URN

Un nombre de recurso uniforme (URN) es un URI que identifica un recurso por su nombre en un espacio de nombres particular. Una URN se puede usar para hablar sobre un recurso sin implicar su ubicación o cómo acceder a él. Por ejemplo, en el sistema del Número Estándar Internacional de Libros (ISBN), ISBN 0-486-27557-4 identifica una edición específica de la obra de Shakespeare Romeo y Julieta. El URN para esa edición sería urn:isbn:0-486-27557-4. Sin embargo, no da información sobre dónde encontrar una copia de ese libro.

Un localizador uniforme de recursos (URL) es un URI que especifica los medios para actuar u obtener la representación de un recurso, es decir, especifica tanto su mecanismo de acceso principal como su ubicación en la red. Por ejemplo, la URL http://example.org/wiki/Main_Page hace referencia a un recurso identificado como /wiki/Main_Page, cuya representación, en forma de HTML y código relacionado, se puede obtener a través del Protocolo de transferencia de hipertexto (http:) desde un host de red cuyo nombre de dominio es example.org.

Una URN es análoga al nombre de una persona, mientras que una URL es análoga a su dirección postal. En otras palabras, una URN identifica un elemento y una URL proporciona un método para encontrarlo.

Las publicaciones técnicas, especialmente los estándares producidos por el IETF y el W3C, normalmente reflejan una visión descrita en una Recomendación del W3C del 30 de julio de 2001, que reconoce la precedencia del término URI en lugar de respaldar cualquier subdivisión formal en URL y URN.

URL es un concepto útil pero informal: una URL es un tipo de URI que identifica un recurso a través de una representación de su mecanismo de acceso primario (por ejemplo, su red "localización"), en lugar de por otros atributos que pueda tener.

Como tal, una URL es simplemente una URI que apunta a un recurso en una red. Sin embargo, en contextos no técnicos y en software para la World Wide Web, el término "URL" sigue siendo muy utilizado. Además, el término "dirección web" (que no tiene una definición formal) aparece a menudo en publicaciones no técnicas como sinónimo de un URI que utiliza los esquemas http o https. Tales suposiciones pueden generar confusión, por ejemplo, en el caso de espacios de nombres XML que tienen una similitud visual con URI resolubles.

Las especificaciones producidas por WHATWG prefieren URL sobre URI, por lo que las API de HTML5 más nuevas usan URL sobre URI.

Estándarizar en el término URL. URI e IRI [Identificador internacionalizado de recursos] son simplemente confusos. En la práctica se utiliza un único algoritmo para ambos, por lo que mantenerlos distintos no ayuda a nadie. URL también gana fácilmente el concurso de popularidad de resultados de búsqueda.

Si bien la mayoría de los esquemas de URI se diseñaron originalmente para usarse con un protocolo en particular y, a menudo, tienen el mismo nombre, son semánticamente diferentes de los protocolos. Por ejemplo, el esquema http generalmente se usa para interactuar con recursos web mediante HTTP, pero el esquema archivo no tiene protocolo.

Sintaxis

Un URI tiene un esquema que hace referencia a una especificación para asignar identificadores dentro de ese esquema. Como tal, la sintaxis de URI es un sistema de nombres federado y extensible en el que la especificación de cada esquema puede restringir aún más la sintaxis y la semántica de los identificadores que usan ese esquema. La sintaxis genérica de URI es un superconjunto de la sintaxis de todos los esquemas de URI. Se definió por primera vez en el RFC 2396, publicado en agosto de 1998, y se finalizó en el RFC 3986, publicado en enero de 2005.

Un URI se compone de un conjunto permitido de caracteres ASCII que consta de caracteres reservados (genérico: :, /, ? , #, [, ] y @; específico del esquema o de la implementación: < código>!, $, &, ', (, ), *, +, ,, ; y =), caracteres no reservados (letras mayúsculas y minúsculas, dígitos decimales, -, ., _, y ~), y el carácter %. Los componentes y subcomponentes de sintaxis están separados por delimitadores de los caracteres reservados (solo de los caracteres genéricos reservados para los componentes) y definen datos identificativos representados como caracteres no reservados, caracteres reservados que no actúan como delimitadores en el componente y subcomponente respectivamente, y codificaciones porcentuales cuando el carácter correspondiente está fuera del conjunto permitido o se utiliza como delimitador del componente o dentro del mismo. Una codificación porcentual de un octeto de datos de identificación es una secuencia de tres caracteres, que consta del carácter % seguido de dos dígitos hexadecimales que representan el valor numérico de ese octeto.

La sintaxis genérica de URI consta de cinco componentes organizados jerárquicamente en orden de importancia decreciente de izquierda a derecha:

URI = esquema ":" ["//" autoridad] camino ["?" consulta] ["#" fragmento]

Un componente es indefinido si tiene un delimitador asociado y el delimitador no aparece en la URI; los componentes de esquema y ruta siempre están definidos. Un componente está vacío si no tiene caracteres; el componente del esquema siempre no está vacío.

El componente de autoridad consta de subcomponentes:

autoridad = [userinfo "@"] host [":" port]

Esto se representa en un diagrama de sintaxis como:

La URI comprende:

• A non-empty esquema componente seguido de un colon:), que consiste en una secuencia de caracteres que comienzan con una letra y seguido de cualquier combinación de letras, dígitos, más (+), período (., o hiphen (-). Aunque los esquemas son insensibles, la forma canónica es minúscula y los documentos que especifican los esquemas deben hacerlo con letras minúsculas. Ejemplos de esquemas populares incluyen http, https, ftp, mailto, file, data y irc. Los esquemas URI deben inscribirse en la Autoridad de Números Asignados a Internet (IANA), aunque los esquemas no registrados se utilizan en la práctica.
• Un opcional autoridad componente precedido por dos barras (//), que comprende:
  • Un opcional userinfo subcomponente seguido de un símbolo (@), que puede consistir en un nombre de usuario y una contraseña opcional precedida por un colon (:). Uso del formato username:password in the userinfo subcomponent is deprecated for security reasons. Las aplicaciones no deben presentar como texto claro ningún dato después del primer colon (:) encontrado dentro de un subcomponente usuarioinfo a menos que los datos después del colon sea la cadena vacía (indicando no contraseña).
  • A anfitrión subcomponente, consistente en un nombre registrado (incluyendo pero no limitado a un nombre de host) o una dirección IP. Las direcciones IPv4 deben estar en notación dot-decimal, y las direcciones IPv6 deben ser encerradas entre corchetes ([]).
  • Un opcional puerto subcomponente precedido por un colon:), que consiste en dígitos decimales.
• A sendero componente, que consiste en una secuencia de segmentos de ruta separados por un barranco (/). Un camino siempre se define para un URI, aunque el camino definido puede estar vacío (longitud cero). Un segmento también puede estar vacío, dando lugar a dos cortes consecutivos (//) en el componente de ruta. Un componente de ruta puede parecerse o mapear exactamente a una ruta del sistema de archivos, pero no siempre implica una relación con uno. Si se define un componente de autoridad, entonces el componente de ruta debe estar vacío o comenzar con una barra (slash)/). Si un componente de autoridad no está definido, entonces el camino no puede comenzar con un segmento vacío, es decir, con dos barras (//) - ya que los siguientes caracteres serían interpretados como un componente de autoridad.

Por convención, en http:// y https URIs, la última parte de un sendero se llama pathinfo y es opcional. Está compuesto por segmentos de cero o más trayectorias que no se refieren a un nombre de recurso físico existente (por ejemplo, un archivo, un programa de módulo interno o un programa ejecutable) sino a una parte lógica (por ejemplo, un comando o una parte calificadora) que tiene que pasar por separado a la primera parte de la ruta que identifica un módulo ejecutable o programa gestionado por un servidor web; esto se utiliza a menudo para seleccionar contenido dinámico (un documento, etc.)

Ejemplo:

URI: "http://www.example.com/questions/3456/my-document"

Donde: "/questions" es la primera parte de la sendero (un módulo ejecutable o programa) y "/3456/my-document" es la segunda parte de la sendero llamado pathinfo, que se pasa al módulo ejecutable o programa llamado "/questions" para seleccionar el documento solicitado.

An http:// o https URI que contiene pathinfo parte sin una parte de consulta también se puede llamar como una ' URL limpia' cuya última parte puede ser un 'slug'.

• Un opcional query componente precedido de una marca de preguntas (?), que consiste en una cadena de consulta de datos no jerárquicos. Su sintaxis no está bien definida, pero por convención es más a menudo una secuencia de atributos-valor pares separados por un delimitador.
• Un opcional fragmento componente precedido por un hash (#). El fragmento contiene un identificador fragmentario que proporciona dirección a un recurso secundario, como una sección encabezada en un artículo identificado por el resto de la URI. Cuando el recurso primario es un documento HTML, el fragmento es a menudo un atributo id de un elemento específico, y los navegadores web desplazarán este elemento a la vista.

El carácter reservado específico del esquema o la implementación + se puede usar en el esquema, la información de usuario, el host, la ruta, la consulta y el fragmento, y los caracteres reservados específicos del esquema o la implementación !, $, &, ', (, ), *, ,, ; y = se pueden usar en la información de usuario, host, ruta, consulta y fragmento. Además, el carácter genérico reservado : se puede utilizar en la información de usuario, la ruta, la consulta y el fragmento, los caracteres genéricos reservados @ y / se pueden utilizado en la ruta, la consulta y el fragmento, y el carácter reservado genérico ? se puede utilizar en la consulta y el fragmento.

URI de ejemplo

La siguiente figura muestra ejemplos de URI y sus componentes.

 userinfo anfitrión puerto - Nos vemos. - No. .https://john.doe@www.example.com:123/forum/questions/?tag=networking prójimoorder=newest#top
 . - No.- Sí. - No. } esquema autoridad sendero query fragmentoldap://[2001:db8::7]/c=GB?objectClass?one
- No.
and path consulta

mailto:John.Doe@example.com
- No.
and

news:comp.infosystems.www.servers.unix
- No.
and

tel: +1-816-555-1212
- No.
and

telnet://192.0.2.16:80/
─
and

urn:oasis:names:specification:docbook:dtd:xml:4.1.2
- No.
and

Los DOI (identificadores de objetos digitales) se ajustan al sistema de identificadores y al sistema de URI, según lo facilita la sintaxis adecuada.

Referencias URI

Una referencia URI es una URI o una referencia relativa cuando no comienza con un componente del esquema seguido de dos puntos (:). Un segmento de ruta que contiene un carácter de dos puntos (por ejemplo, foo:bar) no se puede usar como el primer segmento de ruta de una referencia relativa si su componente de ruta no comienza con una barra inclinada (/< /code>), ya que se confundiría con un componente del esquema. Dicho segmento de ruta debe estar precedido por un segmento de ruta de puntos (por ejemplo, ./foo:bar).

Los lenguajes de marcado de documentos web suelen utilizar referencias URI para apuntar a otros recursos, como documentos externos o partes específicas del mismo documento lógico:

• en HTML, el valor del src atributo del img elemento proporciona una referencia URI, al igual que el valor del href atributo del a o link elemento;
• en XML, el identificador del sistema aparece después del SYSTEM keyword in a DTD is a fragmentless URI reference;
• en XSLT, el valor del href atributo del xsl:import elemento/instrucción es una referencia URI; igualmente el primer argumento al document() función.

https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
path/resource.txt
../resource.txt
./resource.txt
resource.txt
#fragment

Resolución

Resolver una referencia de URI contra un URI base da como resultado un URI de destino. Esto implica que el URI base existe y es un URI absoluto (un URI sin componente de fragmento). El URI base se puede obtener, en orden de precedencia, de:

• la referencia URI si es un URI;
• el contenido de la representación;
• la entidad que encapsula la representación;
• la URI utilizó para la recuperación real de la representación;
• el contexto de la aplicación.

Dentro de una representación con un URI base bien definido de

http://a/b/c/d;p?q

una referencia relativa se resuelve en su URI de destino de la siguiente manera:

"g:h" - título "g:h"
"g" - título "http://a/b/c/g"
"./g" - título "http://a/b/c/g"
"g/" - título "http://a/b/c/g/"
"/g" - título "http://a/g"
"//g" - título "http://g"
"?y" - título "http://a/b/c/d;p?y"
"g?y" - título "http://a/b/c/g?y"
"#s" - titulado "http://a/b/c/d;p?q#s"
"g#s" - título "http://a/b/c/g#s"
"g?y#s" - título "http://a/b/c/g?y#s"
";x" - título "http://a/b/c/;x"
"g;x" - título "http://a/b/c/g;x"
"g;x?y#s" - título "http://a/b/c/g;x?y#s"
" - título "http://a/b/c/d;p?q"
". - título "http://a/b/c/"
"./" - título "http://a/b/c/"
".." - titulado "http://a/b/"
"./" - título "http://a/b/"
"./g" - título "http://a/b/g"
"./.." - título "http://a/"
"./././" - título "http://a/"
"./../g" - título "http://a/g"

Publicidad de URL

El munging de URL es una técnica mediante la cual se agrega un comando a una URL, generalmente al final, después de un "?" simbólico. Se usa comúnmente en WebDAV como un mecanismo para agregar funcionalidad a HTTP. En un sistema de control de versiones, por ejemplo, para agregar un "pago" comando a una URL, está escrito como http://editing.com/resource/file.php?command=checkout. Tiene la ventaja de ser fácil para los analizadores CGI y también actúa como intermediario entre HTTP y el recurso subyacente, en este caso.

Relación con espacios de nombres XML

En XML, un espacio de nombres es un dominio abstracto al que se puede asignar una colección de nombres de elementos y atributos. El nombre del espacio de nombres es una cadena de caracteres que debe cumplir con la sintaxis URI genérica. Sin embargo, el nombre generalmente no se considera un URI, porque la especificación del URI basa la decisión no solo en los componentes léxicos, sino también en su uso previsto. Un nombre de espacio de nombres no implica necesariamente ninguna de las semánticas de los esquemas de URI; por ejemplo, un nombre de espacio de nombres que comience con http: puede no tener ninguna connotación para el uso de HTTP.

Originalmente, el nombre del espacio de nombres podía coincidir con la sintaxis de cualquier referencia de URI no vacía, pero el W3C desaprobó el uso de referencias de URI relativas. Una especificación separada del W3C para espacios de nombres en XML 1.1 permite que las referencias del Identificador de recursos internacionalizados (IRI) sirvan como base para los nombres de espacios de nombres además de las referencias URI.