Identificador uniforme de recursos

Este artículo incluye una lista de referencias generales , pero carece de suficientes citas en línea correspondientes . Ayúdenos a mejorar este artículo introduciendo citas más precisas. ( febrero de 2024 ) ( aprenda cómo y cuándo eliminar este mensaje )

Un identificador uniforme de recursos ( URI ), anteriormente identificador universal de recursos , es una secuencia única de caracteres que identifica un recurso abstracto o físico, ^[1] como recursos en una página web, dirección de correo electrónico, número de teléfono, ^[2] libros, objetos del mundo real como personas y lugares, conceptos. ^[3] Los URI se utilizan para identificar cualquier cosa descrita utilizando el marco de descripción de recursos (RDF), por ejemplo, los conceptos que forman parte de una ontología definida utilizando el lenguaje de ontología web (OWL) y las personas que se describen utilizando el vocabulario Amigo de un amigo tendrían cada uno un URI individual.

Los URI que proporcionan un medio para localizar 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 ) son localizadores uniformes de recursos ( URL ). Por lo tanto, los URL son un subconjunto de los URI, es decir, cada URL es un URI (y no necesariamente al revés). ^[2] Otros URI proporcionan solo un nombre único, sin un medio para localizar o recuperar el recurso o información sobre él; estos son nombres uniformes de recursos (URN). Las tecnologías web que utilizan URI no se limitan a los navegadores web .

Los URI y las URL tienen una historia compartida. 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 objetivo de un hipervínculo . ^[4] En ese momento, la gente se refería a ella como "nombre de hipertexto" ^[5] o "nombre de documento".

Durante los tres años y medio siguientes, a medida que se desarrollaban las tecnologías básicas de la World Wide Web , HTML , HTTP y los navegadores web , surgió la necesidad de distinguir una cadena que proporcionaba una dirección para un recurso de una cadena que simplemente nombraba un recurso. Aunque todavía no se había definido formalmente, el término Localizador Uniforme de Recursos pasó a representar al primero, y el más polémico Nombre Uniforme de Recurso pasó a representar al segundo. En julio de 1992, el informe de Berners-Lee sobre los identificadores universales de documentos (UDI, Universal Document Identifiers) BOF del Grupo de Trabajo de Ingeniería de Internet (IETF) menciona las URL (como localizadores uniformes de recursos), los URN (originalmente, como números únicos de recursos) y la necesidad de constituir un nuevo grupo de trabajo. ^[6] En noviembre de 1992, el "Grupo de trabajo URI" del IETF se reunió por primera vez. ^[7]

Durante el debate sobre la definición de URL y URN, se hizo evidente que los conceptos incorporados por ambos 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 más importante es que definía una sintaxis formal para los identificadores universales de recursos (es decir, cadenas similares a URL cuya sintaxis y semántica precisas dependían de sus esquemas). Además, la RFC  1630 intentó 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. ^[8]

En diciembre de 1994, el RFC  1738 definió formalmente las URL relativas y absolutas, perfeccionó la sintaxis general de las URL, definió cómo resolver las URL relativas a la forma absoluta y enumeró mejor los esquemas de URL que se utilizaban en ese momento. ^[9] La definición y sintaxis acordadas de las URN tuvieron que esperar hasta la publicación del RFC  2141 del IETF ^[10] en mayo de 1997.

La publicación de la RFC  2396 de la IETF ^[11] en agosto de 1998 hizo que la sintaxis de URI se convirtiera en una especificación independiente ^[11] y la IETF revisó y amplió la mayoría de las partes de las RFC 1630 y 1738 relacionadas con las URI y las URL en general. La nueva RFC cambió el significado de U en URI de "Universal" a "Uniforme".

En diciembre de 1999, RFC  2732 ^[12] proporcionó una actualización menor a RFC 2396, permitiendo que los URIs admitieran direcciones IPv6 . Una serie de deficiencias descubiertas en las dos especificaciones condujeron a un esfuerzo comunitario, coordinado por el coautor de RFC 2396 Roy Fielding , que culminó en la publicación de IETF RFC  3986 ^[13] en enero de 2005. Si bien dejó obsoleto el estándar anterior, no dejó obsoletos los detalles de los esquemas de URL existentes; RFC 1738 continúa gobernando dichos esquemas excepto cuando se reemplazan de otra manera. IETF RFC  2616 ^[14] , por ejemplo, refina el esquema. Simultáneamente, 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 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 de mejores prácticas y URI canónicos para publicar múltiples versiones de un recurso determinado. ^[15] 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, la RFC  3305 de la IETF ^[16] señaló que el término "URL", a pesar de su uso público generalizado, había caído casi en desuso y sólo sirve como recordatorio de que algunas URI actúan como direcciones al tener esquemas que implican accesibilidad a la red, independientemente de dicho uso real. Como demuestran 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 tampoco implicar recursos basados ​​en la red en absoluto.

La Web Semántica utiliza el esquema de URI HTTP para identificar tanto documentos como conceptos para usos prácticos, una distinción que ha causado confusión en cuanto a cómo distinguirlos. El TAG publicó un correo electrónico en 2005 con una solución al problema, que se conoció como la resolución httpRange-14 . ^[17] Posteriormente, el W3C publicó una nota del grupo de interés titulada Cool URIs for the Semantic Web , que explicaba el uso de la negociación de contenido y el código de respuesta HTTP 303 para redirecciones con más detalle. ^[18]

Un nombre de recurso uniforme (URN) es un URI que identifica un recurso por su nombre en un espacio de nombres en particular. Un URN puede usarse para hablar sobre un recurso sin implicar su ubicación o cómo acceder a él. Por ejemplo, en el sistema de Número estándar internacional 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 brinda 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 sobre 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_Pagese refiere a un recurso identificado como /wiki/Main_Page, cuya representación 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. (En este caso, HTTP generalmente implica que está en forma de HTML y código relacionado. En la práctica, ese no es necesariamente el caso, 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 los estándares producidos por la IETF y el W3C, normalmente reflejan una visión delineada 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 principal (por ejemplo, su "ubicación" en la red), en lugar de por otros atributos que pueda tener. ^[19]

Como tal, una URL es simplemente un URI que apunta a un recurso en una red. ^{[a] [16]} Sin embargo, en contextos no técnicos y en software para la World Wide Web, el término "URL" sigue utilizándose ampliamente. 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 llevar a confusión, por ejemplo, en el caso de 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 nuevas usan URL sobre URI . ^[20]

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

Si bien la mayoría de los esquemas 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 se usa generalmente para interactuar con recursos web mediante HTTP, pero el archivo de esquema no tiene protocolo.

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 utilizan 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 RFC  2396, publicada en agosto de 1998, ^[11] y se finalizó en RFC  3986, publicada en enero de 2005. ^[22]

Un URI se compone de un conjunto permitido de caracteres ASCII que consiste en caracteres reservados (gen-delims: :, /, ?, #, [, ], y @; sub-delims: !, $, &, ', (, ), *, +, ,, ;y =), ^[23] caracteres no reservados ( letras mayúsculas y minúsculas , dígitos decimales , -, ., _y ~), ^[23] y el carácter %. ^[24] 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, ^{[13] : §2} y codificaciones de porcentaje cuando el carácter correspondiente está fuera del conjunto permitido o se está utilizando como 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 consta del carácter %seguido de los dos dígitos hexadecimales que representan el valor numérico de ese octeto. ^{[13] : §2.1}

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

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

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

El componente de autoridad consta de subcomponentes :

autoridad = [información de usuario "@"] host [": "puerto]

Esto se representa en un diagrama de sintaxis como:

La URI comprende:

• Un no vacíocomponente de esquema seguido de dos puntos (:), que consiste en una secuencia de caracteres que comienza con una letra y sigue de cualquier combinación de letras, dígitos, más (+), punto (.) o guión (-). 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. Algunos ejemplos de esquemas populares sonhttp,https,ftp,mailto,file,datayirc. Los esquemas URI deben estar registrados en laAutoridad de Números Asignados de Internet (IANA), aunque en la práctica se utilizan esquemas no registrados.^[b]
• Un opcionalcomponente de autoridad precedido de dos barras (//), que comprende:
  • Un opcionalSubcomponente userinfo seguido de un símbolo arroba (@), que puede consistir en unnombre de usuarioy unacontraseñaprecedida por dos puntos (:). El uso del formatousername:passworden el subcomponente userinfo está en desuso por razones de seguridad. Las aplicaciones no deben representar como texto sin formato ningún dato después de los primeros dos puntos (:) que se encuentre dentro de un subcomponente userinfo a menos que los datos después de los dos puntos sean una cadena vacía (que indica que no hay contraseña).
  • Asubcomponente de host , que consiste en un nombre registrado (incluido, entre otros, unnombre de host) o unadirección IP.IPv4deben estar ennotación decimal con puntoyIPv6deben estar entre corchetes ([]).^{[13] : §3.2.2  [c]}
  • Un opcionalsubcomponente de 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 ( ). Siempre se define una ruta para un URI, aunque la ruta definida puede estar vacía (longitud cero). Un segmento también puede estar vacío, lo que da como resultado dos barras consecutivas (//) en el componente de ruta. Un componente de ruta puede parecerse o mapearse exactamente a 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 (/). Si un componente de autoridad no está definido, entonces la ruta no puede comenzar con un segmento vacío, es decir, con dos barras (//), ya que los siguientes caracteres se interpretarían como un componente de autoridad.^{[11] : §3.3}

Por convención, en las URI http y https , la última parte de una ruta se denominapathinfo y es opcional. Está compuesto por 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 administrado por unservidor web; esto se usa a menudo para seleccionar contenido dinámico (un documento, etc.) o para adaptarlo según lo solicitado (ver también:CGIy PATH_INFO, etc.).

Ejemplo:

Dirección URL:"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 de información de ruta sin una parte de consulta también puede denominarse " URL limpia ", cuya última parte puede ser un " slug ".

• Un opcionalComponente 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.
• Un opcionalComponente de fragmento precedido por un símbolo hash(#). El fragmento contiene unidentificador de fragmentoque proporciona la dirección a un recurso secundario, como un encabezado de sección en un artículo identificado por el resto del URI. Cuando el recurso principal es unHTML, el fragmento suele ser unidatributode un elemento específico y los navegadores web desplazarán este elemento para mostrarlo.

El carácter reservado específico del esquema o de la implementación +se puede utilizar 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 de la implementación !, $, &, ', (, ), *, ,, ;, y =se pueden utilizar en la información de usuario, el host, la ruta, la consulta y el fragmento. Además, el carácter reservado genérico :se puede utilizar en la información de usuario, la ruta, la consulta y el fragmento, los caracteres reservados genéricos @y /se pueden utilizar en la ruta, la consulta y el fragmento, y el carácter reservado genérico ?se puede utilizar en la consulta y el fragmento. ^{[13] : §A}

La siguiente figura muestra ejemplos de URI y sus componentes.

  puerto de host de información de usuario ┌──┴───┐ ┌───────┴──────┐ ┌┴─┐     https://[email protected]:1234/forum/questions/?tag=networking&order=newest#top └─┬─┘  └─────────────┬─────────────┘ └───── ──┬─────── ┘ └────────────┬────────────┘ └┬┘ esquema autoridad ruta consulta fragmento usuarioinfo host puerto ┌──┴───┐ ┌───────┴──────┐ ┌┴─┐              https://[email protected]:1234/forum/questions/?tag=networking&order=newest#:~:text=loquesea └─┬─┘  └─────────────┬─────────────┘ └───── ──┬─────── ┘ └────────────┬────────────┘ └────────┬────────┘ fragmento de consulta de ruta de autoridad de esquema        ldap://[2001:db8::7]/c=GB?objectClass?uno └┬─┘  └───────────┘ └─┬─┘ └────────┬─────┘ consulta de ruta de autoridad de esquema      mailto:[email protected] └─┬──┘  └────┬──────────────┘ ruta del esquema   noticias:comp.infosystems.www.servers.unix └┬─┘  └───────────────┬──────────────────┘ ruta del esquema   Teléfono: +1-816-555-1212 └┬┘  └───────┬──────┘ ruta del esquema   telnet://192.0.2.16:80/ └─┬──┘  └─────┬─────┘ │ ruta de autoridad del esquema    urn:oasis:nombres:especificación:docbook:dtd:xml:4.1.2 └┬┘  └──────────────────────────┬─────────────────────────┘ ruta del esquema  

Los DOI ( identificadores de objetos digitales ) encajan dentro del sistema de identificadores y se adaptan al sistema URI, tal y como lo facilita 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 ( :). ^{[13] : §4.1} Un segmento de ruta que contiene un carácter de dos puntos (por ejemplo, foo:bar) no se puede utilizar como el primer segmento de ruta de una referencia relativa si su componente de ruta no comienza con una barra ( /), ya que se confundiría con un componente de esquema. Un segmento de ruta de este tipo debe estar precedido por un segmento de ruta de punto (por ejemplo, ./foo:bar). ^{[13] : §4.2}

Los lenguajes de marcado de documentos web utilizan con frecuencia referencias URI para señalar otros recursos, como documentos externos o partes específicas del mismo documento lógico: ^{[13] : §4.4}

• en HTML , el valor del srcatributo del imgelemento proporciona una referencia URI, al igual que el valor del hrefatributo del elemento aor 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; al igual que el primer argumento de la document()función.

https://example.com/path/resource.txt#fragment//ejemplo.com/ruta/recurso.txt/ruta/recurso.txtruta/recurso.txt../recurso.txt./recurso.txtrecurso.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: ^{[13] : §5.1}

• la propia URI de referencia 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: ^{[13] : §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 añade un comando a una URL, normalmente al final, después de un token "?" . Se utiliza habitualmente en WebDAV como mecanismo para añadir funcionalidad a HTTP . En un sistema de control de versiones, por ejemplo, para añadir 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. ^[28]

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. ^[29] Sin embargo, generalmente no se considera que el nombre sea un URI, ^[30] porque la especificación de 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 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 uso de referencias URI relativas fue desestimado por el W3C. ^[31] Una especificación W3C separada para espacios de nombres en XML 1.1 permite que las referencias de Identificador de Recurso Internacionalizado (IRI) sirvan como base para los nombres de espacios de nombres además de las referencias URI. ^[32]

• CURIE
• Datos vinculados
• Identificador de recursos extensible
• Identificador de recursos internacionalizado (IRI)
• Localizador de recursos de Internet
• Localizador uniforme de recursos persistente
• Convención de nomenclatura uniforme
• Lenguaje de descripción del directorio de recursos
• Identificador universal único
• Lista de esquemas URI

• Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (enero de 2005). RFC 3986 Identificador uniforme de recursos (URI): sintaxis genérica. Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC3986 . RFC 3986 . Consultado el 16 de febrero de 2024 .{{citation}}: CS1 maint: multiple names: authors list (link)

• Whitehead, EJ (1998). "WebDAV: estándar IEFT para la creación colaborativa en la Web". IEEE Internet Computing . 2 (5): 34–40. doi :10.1109/4236.722228. ISSN  1941-0131 . Consultado el 12 de octubre de 2021 .

• Esquemas URI: registro de esquemas URI mantenido por la IANA
• Esquemas URI en la wiki del W3C
• Arquitectura de la World Wide Web, Volumen Uno, §2: Identificación – por W3C
• Aclaración de URL del W3C