Identificador Uniforme de Recursos

Las URI y las URL tienen una historia común. En 1990, las propuestas de Tim Berners-Lee para el hipertexto introdujeron implícitamente la idea de una URL como una cadena corta que representa un recurso que es el destino de un hipervínculo . ^{[ 2 ]} En ese momento, la gente se refería a ella como un "nombre de hipertexto" ^{[ 3 ]} o "nombre de documento".

Durante los siguientes tres años y medio, a medida que se desarrollaban las tecnologías centrales de la World Wide Web ( HTML , HTTP y navegadores web) , surgió la necesidad de distinguir entre una cadena que proporcionaba una dirección para un recurso y una que simplemente lo nombraba. Aunque aún no se había definido formalmente, el término Localizador Uniforme de Recursos (URL) pasó a representar al primero, y el más controvertido Nombre Uniforme de Recursos (URN) pasó a representar al segundo. En julio de 1992, el informe de Berners-Lee sobre el Grupo de Trabajo de Ingeniería de Internet (IETF) «UDI (Identificadores Universales de Documentos) BOF » menciona las URL (como Localizadores Uniformes de Recursos), los URN (originalmente, como Números Únicos de Recursos) y la necesidad de crear un nuevo grupo de trabajo. ^{[ 4 ]} En noviembre de 1992, el Grupo de Trabajo URI del IETF se reunió por primera vez. ^{[ 5 ]}

Durante el debate sobre la definición de URL y URN, se hizo evidente que los conceptos que englobaban ambos términos eran meros aspectos de la noción fundamental y general de identificación de recursos . En junio de 1994, la IETF publicó la RFC 1630 , la primera solicitud de comentarios de Berners-Lee que reconocía la existencia de URL y URN. Lo más importante es que definía una sintaxis formal para los identificadores universales de recursos (es decir, cadenas similares a las URL cuya sintaxis y semántica precisas dependían de sus esquemas). También intentaba resumir las sintaxis de los esquemas de URL en uso en ese momento. Reconocía —pero no estandarizaba— la existencia de URL relativas e identificadores de fragmentos. ^{[ 6 ]} 

En diciembre de 1994, el RFC 1738 ^{[ 7 ]} definió formalmente las URL relativas y absolutas, perfeccionó la sintaxis general de las URL, definió cómo convertir las URL relativas a absolutas y enumeró mejor los esquemas de URL que se utilizaban entonces. La definición y sintaxis acordadas de los URN tuvieron que esperar hasta la publicación del IETF RFC 2141 ^{[ 8 ]} en mayo de 1997.  

La publicación del RFC 2396 de la IETF ^{[ 9 ]} en agosto de 1998 convirtió la sintaxis URI en una especificación independiente ^{[ 9 ]} y la IETF revisó y amplió la mayor parte de las secciones de los RFC 1630 y 1738 relativas a las URI y las URL en general. El nuevo RFC cambió el significado de la U en URI de "Universal" a "Uniforme". 

En diciembre de 1999, el RFC 2732 ^{[ 10 ]} proporcionó una actualización menor al RFC 2396 , permitiendo que las URI admitieran direcciones IPv6 . Una serie de deficiencias descubiertas en las dos especificaciones llevaron a un esfuerzo comunitario, coordinado por el coautor del RFC 2396 , Roy Fielding , que culminó con la publicación del IETF RFC 3986 ^{[ 1 ]} en enero de 2005. Si bien dejó obsoleto el estándar anterior, no hizo que los detalles de los esquemas de URL existentes quedaran obsoletos; el RFC 1738 continúa rigiendo dichos esquemas, excepto donde se haya reemplazado. El IETF RFC 2616 ^{[ 11 ]} , por ejemplo, refina el esquema. Simultáneamente, el IETF publicó el contenido del RFC 3986 como el estándar completo STD 66, reflejando el establecimiento de la sintaxis genérica de URI como un protocolo oficial de Internet.   http

En 2001, el Grupo de Arquitectura Técnica (TAG) del Consorcio World Wide Web (W3C) publicó una guía sobre las mejores prácticas y las URI canónicas para publicar múltiples versiones de un recurso determinado. ^{[ 12 ]} Por ejemplo, el contenido podría variar según el idioma o el tamaño para ajustarse a la capacidad o la configuración del dispositivo utilizado para acceder a dicho contenido.

En agosto de 2002, el RFC 3305 de la IETF ^{[ 13 ]} señaló que el término "URL", a pesar de su uso público generalizado, había caído casi en desuso, y sirve únicamente como recordatorio de que algunas URI actúan como direcciones al tener esquemas que implican accesibilidad a la red, independientemente de cualquier uso real de este tipo. Como evidencian los estándares basados ​​en URI, como el Resource Description Framework , la identificación de recursos no implica necesariamente la recuperación de representaciones de recursos a través de Internet, ni implica necesariamente recursos basados ​​en la red. 

La Web Semántica utiliza el esquema URI HTTP para identificar tanto documentos como conceptos para usos prácticos, una distinción que ha causado confusión sobre cómo diferenciarlos. El TAG publicó un correo electrónico en 2005 con una solución al problema, que se conoció como la resolución httpRange-14 . ^{[ 14 ]} Posteriormente, el W3C publicó una nota del Grupo de Interés titulada "URIs interesantes para la Web Semántica", que explicaba con más detalle el uso de la negociación de contenido y el código de respuesta HTTP 303 para redirecciones. ^{[ 15 ]}

Un nombre uniforme de recurso (URN) es una URI que identifica un recurso por su nombre en un espacio de nombres específico. Un URN puede usarse para referirse a un recurso sin indicar su ubicación ni cómo acceder a él. Por ejemplo, en el sistema de numeración internacional estándar de libros (ISBN), el ISBN 0-486-27557-4 identifica una edición específica de la obra de William Shakespeare, Romeo y Julieta . El URN para esa edición sería urn:isbn:0-486-27557-4 . Sin embargo, no proporciona información sobre dónde encontrar un ejemplar de ese libro.

Un Localizador Uniforme de Recursos (URL) es un URI que especifica la forma de acceder a un recurso o de obtener su representación, 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_Pagese refiere a un recurso identificado como /wiki/Main_Page, cuya representación se puede obtener mediante el Protocolo de Transferencia de Hipertexto ( http: //) desde un host de red cuyo nombre de dominio es example.org. (En este caso, HTTP suele implicar que se trata de HTML y código relacionado. En la práctica, esto no siempre es así, ya que HTTP permite especificar formatos arbitrarios en su encabezado).

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

Las publicaciones técnicas, especialmente las normas elaboradas por la IETF y el W3C, suelen reflejar la opinión expuesta en una Recomendación del W3C del 30 de julio de 2001, que reconoce la primacía del término URI en lugar de respaldar cualquier subdivisión formal en URL y URN.

La 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 principal (por ejemplo, su "ubicación" de red), en lugar de por otros atributos que pueda tener. ^{[ 16 ]}

Como tal, una URL es simplemente un URI que apunta a un recurso a través de una red. ^{[ a ] ​​[ 13 ]} Sin embargo, en contextos no técnicos y en software para la World Wide Web, el término "URL" sigue siendo ampliamente 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 los espacios de nombres XML que tienen una similitud visual con los URI resolubles .

Las especificaciones producidas por WHATWG prefieren URL sobre URI , por lo que las API HTML5 más recientes utilizan URL sobre URI . ^{[ 17 ]}

Estandarizar el término URL. URI e IRI (Identificador Internacionalizado de Recursos) solo generan confusión. En la práctica, se utiliza un único algoritmo para ambos, por lo que mantenerlos distintos no beneficia a nadie. Además, URL gana fácilmente en popularidad en los resultados de búsqueda. ^{[ 18 ]}

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

Una URI posee un esquema que hace referencia a una especificación para la asignación de identificadores dentro de dicho esquema. Por lo tanto, la sintaxis de la URI es un sistema de nombres federado y extensible, donde la especificación de cada esquema puede restringir aún más la sintaxis y la semántica de los identificadores que utilizan ese esquema. La sintaxis genérica de la URI es un superconjunto de la sintaxis de todos los esquemas de URI. Se definió por primera vez en la RFC 2396 , publicada en agosto de 1998, ^{[ 9 ]} y se finalizó en la RFC 3986 , publicada en enero de 2005. ^{[ 19 ]}  

Una URI se compone de un conjunto permitido de caracteres ASCII que consiste en caracteres reservados (gen-delims: :, /, ?, #, [, ], y @; sub-delims: !, $, &, ', (, ), *, +, ,, ;, y =), ^{[ 1 ] : 13–14} caracteres no reservados ( letras mayúsculas y minúsculas , dígitos decimales , -, ., _, y ~), ^{[ 1 ] : 13–14} y el carácter %. ^{[ 1 ] : 12} Los componentes y subcomponentes de sintaxis están separados por delimitadores de los caracteres reservados (solo de caracteres reservados genéricos para componentes) y definen datos de identificación representados como caracteres no reservados, caracteres reservados que no actúan como delimitadores en el componente y subcomponente respectivamente, ^{[ 1 ] : §2} y codificaciones de porcentaje cuando el carácter correspondiente está fuera del conjunto permitido o se está utilizando como un delimitador de, o dentro de, el componente. Una codificación porcentual de un octeto de datos de identificación es una secuencia de tres caracteres, que consiste en el carácter %seguido de los dos dígitos hexadecimales que representan el valor numérico de ese octeto. ^{[ 1 ] : §2.1}

La sintaxis genérica de URI consta de cinco componentes organizados jerárquicamente en orden de importancia decreciente de izquierda a derecha: ^{[ 1 ] : §3}

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

Un componente no está definido si tiene un delimitador asociado y este no aparece en la URI; los componentes de esquema y ruta siempre están definidos. ^{[ 1 ] : §5.2.1} Un componente está vacío si no tiene caracteres; el componente de esquema siempre está no vacío. ^{[ 1 ] : §3}

El componente de autoridad consta de subcomponentes :

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

Esto se representa en un diagrama de sintaxis como:

La URI comprende:

• Un no vacíoComponente del esquema seguido de dos puntos (:), que consiste en una secuencia de caracteres que comienza con una letra y va seguida de cualquier combinación de letras, dígitos, signo más (+), punto (.) o guion (-). Aunque los esquemas no distinguen entre mayúsculas y minúsculas, la forma canónica es minúscula y los documentos que especifican esquemas deben hacerlo con letras minúsculas. Ejemplos de esquemas populares incluyenhttp,https,ftp,mailto,file,datayirc. Los esquemas URI deben registrarse en laAutoridad de Números Asignados de Internet (IANA), aunque en la práctica se utilizan esquemas no registrados. ^{[ 20 ]}
• Una opciónComponente de autoridad precedido por dos barras diagonales (//), que comprende:
  • Una opciónEl subcomponente userinfo va seguido de un símbolo arroba (@), que puede consistir en unnombre de usuarioy unacontraseñaprecedida de dos puntos (:). El uso de este formatousername:passworden el subcomponente userinfo está desaconsejado por motivos de seguridad. Las aplicaciones no deben mostrar como texto plano ningún dato que:aparezca después de los primeros dos puntos ( ) dentro del subcomponente userinfo, a menos que dicho dato sea una cadena vacía (lo que indica que no hay contraseña).
  • Asubcomponente de host , que consiste en un nombre registrado (incluido, pero no limitado a, unnombre de host) o unadirección IP.IPv4deben estar ennotación decimal con puntos, yIPv6deben estar entre corchetes ([]). ^{[ 1 ] : §3.2.2 [ b ]}
  • Una opciónsubcomponente del puerto precedido por dos puntos (:), que consta de dígitos decimales.
• AComponente de ruta , que consiste en una secuencia de segmentos de ruta separados por una barra diagonal (/). Siempre se define una ruta para una URI, aunque la ruta definida puede estar vacía (longitud cero). Un segmento también puede estar vacío, lo que resulta en dos barras diagonales consecutivas (//) en el componente de ruta. Un componente de ruta puede parecerse o corresponderse exactamente con unaruta del sistema de archivos, pero no siempre implica una relación con una. Si se define un componente de autoridad, entonces el componente de ruta debe estar vacío o comenzar con una barra diagonal (/). Si no se define un componente de autoridad, entonces la ruta no puede comenzar con un segmento vacío, es decir, con dos barras diagonales (//), ya que los caracteres siguientes se interpretarían como un componente de autoridad. ^{[ 9 ] : §3.3}

Por convención, en las URI http y https , la última parte de una ruta se llamapathinfo es opcional. Se compone de cero o más segmentos de ruta que no hacen referencia 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 debe pasarse por separado a la primera parte de la ruta que identifica un módulo ejecutable o un programa gestionado por unservidor web; esto se usa a menudo para seleccionar contenido dinámico (un documento, etc.) o para adaptarlo según se solicite (véase también:CGIy PATH_INFO, etc.).

Ejemplo:

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

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

Una URI http o https que contiene una parte pathinfo sin una parte de consulta también puede denominarse ' URL limpia ', cuya última parte puede ser un ' slug '.

• Una opciónComponente de consulta precedido por un signo de interrogación (?), que consiste en unacadena de consultade datos no jerárquicos. Su sintaxis no está bien definida, pero por convención suele ser una secuencia depares atributo-valorseparados por undelimitador.
• Una opciónEl fragmento está precedido por unaalmohadilla(#). Contiene unidentificadorque dirige a un recurso secundario, como el encabezado de una sección de un artículo, identificado por el resto de la URI. Cuando el recurso principal es unHTML, el fragmento suele ser unidatributode un elemento específico, y los navegadores web desplazan este elemento para que sea visible.

El carácter reservado específico del esquema o implementación +puede usarse en el esquema, userinfo, host, ruta, consulta y fragmento, y los caracteres reservados específicos del esquema o implementación !, $, &, ', (, ), *, ,, ;, y =pueden usarse en userinfo, host, ruta, consulta y fragmento. Además, el carácter reservado genérico :puede usarse en userinfo, ruta, consulta y fragmento, los caracteres reservados genéricos @y /pueden usarse en la ruta, consulta y fragmento, y el carácter reservado genérico ?puede usarse en la consulta y fragmento. ^{[ 1 ] : §A}

A continuación se muestran ejemplos de URI y sus componentes.

userinfo host puerto ┌──┴───┐ ┌──────┴──────┐ ┌┴─┐ https :// john.doe @www. example.com :1234/forum/questions/?tag=networking&order=newest#top └─┬─┘ └─────────────┬─────────────┘ └───────┬───────┘ └────────────┬────────────┘ └┬┘ esquema autoridad ruta consulta fragmento información de usuario host puerto ┌──┴───┐ ┌──────┴──────┐ ┌┴─┐ https://john.doe@www.example.com:1234/forum/questions/?tag=networking&order=newest#:~:text=whatever └─┬─┘ └─────────────┬─────────────┘ └───────┬───────┘ └────────────┬───────────┘ └───────┬───────┘ esquema autoridad ruta consulta fragmentoldap ://[2001:db8::7]/c=GB?objectClass?one └┬─┘ └─────┬─────┘ └─┬─┘ └──────┬──────┘ esquema autoridad ruta consultamailto :John.Doe@example.com └─┬──┘ └────┬─────────────┘ ruta del esquemanoticias : comp.infosystems.www.servers.unix └┬─┘ └─────────────┬─────────────────┘ ruta del esquema​tel :+1-816-555-1212 └┬┘ └──────┬──────┘ ruta del esquematelnet ://192.0.2.16:80/ └─┬──┘ └─────┬─────┘ │ ruta de autoridad del esquemaurna : oasis : nombres: especificación: docbook : dtd : xml : 4.1.2 └┬┘ └──────────────────────┬──────────────────────┘ ruta del esquema

Los DOI ( identificadores de objetos digitales ) se ajustan al sistema Handle y al sistema URI, gracias a la sintaxis adecuada .

Una referencia URI es una URI o una referencia relativa cuando no comienza con un componente de esquema seguido de dos puntos ( :). ^{[ 1 ] : §4.1} Un segmento de ruta que contiene un carácter de dos puntos (p. ej., foo:bar) no puede usarse como primer segmento de ruta de una referencia relativa si su componente de ruta no comienza con una barra inclinada ( /), ya que se confundiría con un componente de esquema. Dicho segmento de ruta debe ir precedido de un segmento de ruta de punto (p. ej., ./foo:bar). ^{[ 1 ] : §4.2}

Los lenguajes de marcado de documentos web frecuentemente utilizan referencias URI para apuntar a otros recursos, como documentos externos o partes específicas del mismo documento lógico: ^{[ 1 ] : §4.4}

• En HTML , el valor del srcatributo del imgelemento proporciona una referencia URI, al igual que el valor del hrefatributo del elemento ao ;link
• En XML , el identificador del sistema que aparece después de la SYSTEMpalabra clave en un DTD es una referencia URI sin fragmentos;
• En XSLT , el valor del hrefatributo del xsl:importelemento/instrucción es una referencia URI; del mismo modo, el primer argumento de la document()función.

https://example.com/path/resource.txt#fragment //ejemplo.com/ruta/recurso.txt /ruta/recurso.txt ruta/recurso.txt ../resource.txt ./resource.txt recurso.txt #fragmento 

La resolución de una referencia URI con respecto a una URI base da como resultado una URI de destino . Esto implica que la URI base existe y es una URI absoluta (una URI sin componente de fragmento). La URI base se puede obtener, en orden de precedencia, de: ^{[ 1 ] : §5.1}

• la URI de referencia en sí misma, si es una URI;
• el contenido de la representación;
• la entidad que encapsula la representación;
• la URI utilizada para la recuperación real de la representación;
• el contexto de la aplicación.

Dentro de una representación con una URI base bien definida de

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

Una referencia relativa se resuelve a su URI de destino de la siguiente manera: ^{[ 1 ] : §5.4}

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

La manipulación de URL es una técnica mediante la cual se agrega un comando a una URL, generalmente al final, después de un token "?" . Se usa comúnmente en WebDAV como mecanismo para agregar funcionalidad a HTTP . En un sistema de versiones, por ejemplo, para agregar un comando "checkout" a una URL, se escribe 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. ^{[ 24 ]}

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 ajustarse a la sintaxis genérica de URI. ^{[ 25 ]} Sin embargo, el nombre generalmente no se considera una URI, ^{[ 26 ]} porque la especificación de URI basa la decisión no solo en 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 URI; por ejemplo, un nombre de espacio de nombres que comience con http: puede no tener ninguna connotación con el uso de HTTP .

Originalmente, el nombre del espacio de nombres podía coincidir con la sintaxis de cualquier referencia URI no vacía, pero el W3C desaconsejó el uso de referencias URI relativas. ^{[ 27 ]} Una especificación independiente del W3C para espacios de nombres en XML 1.1 permite que las referencias de identificadores de recursos internacionalizados (IRI) sirvan como base para los nombres de los espacios de nombres, además de las referencias URI. ^{[ 28 ]}

• Bray, Tim ; Hollander, Dave; Layman, Andrew; Tobin, Richard, eds. (16 de agosto de 2006). "Espacios de nombres en XML 1.1 (Segunda edición)" . Consorcio World Wide Web . 2.2 Uso de URI como nombres de espacios de nombres . Recuperado el 31 de agosto de 2015 .
• Bray, Tim ; Hollander, Dave; Layman, Andrew; Tobin, Richard; Thompson, Henry S., eds. (2009-12-08). "Espacios de nombres en XML 1.0 (Tercera edición)" . Consorcio World Wide Web . 2.2 Uso de URI como nombres de espacios de nombres . Recuperado el 31 de agosto de 2015 .
• Harold, Elliotte Rusty (2004). XML 1.1 Bible (Tercera  ed.). Wiley Publishing . pág.  291. ISBN 978-0-7645-4986-1.
• Lawrence, Eric (2014-03-06). "Browser Arcana: IP Literals en URL" . IEInternals . Microsoft . Recuperado el 2016-04-25 .
• Morrison, Michael Wayne (2006). "Hora 5: Uso de espacios de nombres ". Sams Teach Yourself XML . Sams Publishing . pág.  91.
• Whitehead, EJ (1998). "WebDAV: estándar IEFT para la autoría colaborativa en la Web". IEEE Internet Computing . 2 (5): 34– 40. doi : 10.1109/4236.722228 . ISSN 1941-0131 .