Identificador de Recurso Uniforme - Uniform Resource Identifier

Identificador Uniforme de Recursos (URI)
Domínio Rede mundial de computadores
Abreviação URI

Um Uniform Resource Identifier ( URI ) é uma sequência única de caracteres que identifica um recurso lógico ou físico usado por tecnologias da web. URIs podem ser usados ​​para identificar qualquer coisa, incluindo objetos do mundo real, como pessoas e lugares, conceitos ou recursos de informação, como páginas da web e livros. Alguns URIs fornecem um meio de localizar e recuperar recursos de informação em uma rede (na Internet ou em outra rede privada, como um sistema de arquivos de computador ou uma Intranet); estes são Localizadores Uniformes de Recursos (URLs). Um URL fornece a localização do recurso. Um URI identifica o recurso por nome no local ou URL especificado. Outros URIs fornecem apenas um nome exclusivo, sem um meio de localizar ou recuperar o recurso ou informações sobre ele, são nomes de recursos uniformes (URNs). As tecnologias da web que usam URIs não se limitam a navegadores da web. URIs são usados ​​para identificar qualquer coisa descrita usando o Resource Description Framework (RDF), por exemplo, conceitos que fazem parte de uma ontologia definida usando a Web Ontology Language (OWL), e as pessoas que são descritas usando o vocabulário Friend of a Friend iriam cada uma tem um URI individual.

História

Concepção

URIs e URLs têm um histórico compartilhado. Em 1990, as propostas de Tim Berners-Lee para hipertexto implicitamente introduziram a ideia de URL como uma string curta que representa um recurso que é o alvo de um hiperlink . Na época, as pessoas se referiam a ele como um "nome de hipertexto" ou "nome de documento".

Nos três anos e meio seguintes, conforme as tecnologias centrais da World Wide Web de HTML, HTTP e navegadores da web se desenvolveram, surgiu a necessidade de distinguir uma string que fornecia um endereço para um recurso de uma string que meramente nomeava um recurso. Embora ainda não definido formalmente, o termo Uniform Resource Locator passou a representar o primeiro, e o mais controverso Uniform Resource Name passou a representar o último. Em julho de 1992, o relatório de Berners-Lee sobre o "UDI (Universal Document Identifiers) BOF " da IETF menciona URLs (como Uniform Resource Locators), URNs (originalmente, como Unique Resource Numbers) e a necessidade de estabelecer um novo grupo de trabalho. Em novembro de 1992, o "URI Working Group" da IETF se reuniu pela primeira vez.

Durante o debate sobre a definição de URLs e URNs, tornou-se evidente que os conceitos incorporados pelos dois termos eram meramente aspectos da noção fundamental e abrangente de identificação de recursos . Em junho de 1994, a IETF publicou a primeira solicitação de comentários de Berners-Lee que reconhecia a existência de URLs e URNs. Mais importante ainda, definiu uma sintaxe formal para Identificadores de Recursos Universais (ou seja, strings semelhantes a URL, cujas sintaxes e semânticas precisas dependiam de seus esquemas). Além disso, a RFC  1630 tentou resumir as sintaxes dos esquemas de URL em uso na época. Ele reconheceu - mas não padronizou - a existência de URLs relativos e identificadores de fragmentos.

Refinamento

Em dezembro de 1994, a RFC  1738 definiu formalmente os URLs relativos e absolutos, refinou a sintaxe geral do URL, definiu como resolver os URLs relativos para a forma absoluta e enumerou melhor os esquemas de URL então em uso. A definição e sintaxe acordadas de URNs tiveram que esperar até a publicação da IETF RFC 2141 em maio de 1997.

A publicação da IETF RFC 2396 em agosto de 1998 viu a sintaxe URI se tornar uma especificação separada e a maioria das partes das RFCs 1630 e 1738 relacionadas a URIs e URLs em geral foram revisadas e expandidas pela IETF . O novo RFC mudou o significado de "U" em "URI" para "Uniforme" de "Universal".

Em dezembro de 1999, o RFC  2732 forneceu uma pequena atualização para o RFC 2396, permitindo que os URIs acomodassem endereços IPv6 . Uma série de deficiências descobertas nas duas especificações levaram a um esforço da comunidade, coordenado pelo co-autor da RFC 2396, Roy Fielding , que culminou na publicação da IETF RFC 3986 em janeiro de 2005. Embora tenha tornado obsoleto o padrão anterior, ele não forneceu os detalhes de esquemas de URL existentes obsoletos; A RFC 1738 continua a governar esses esquemas, exceto onde substituída de outra forma. IETF RFC 2616, por exemplo, refina o httpesquema. Simultaneamente, a IETF publicou o conteúdo da RFC 3986 como o padrão completo STD 66, refletindo o estabelecimento da sintaxe genérica do URI como um protocolo oficial da Internet.

Em 2001, o Grupo de Arquitetura Técnica (TAG) do W3C publicou um guia de práticas recomendadas e URIs canônicos para publicar várias versões de um determinado recurso. Por exemplo, o conteúdo pode diferir por idioma ou tamanho para ajustar a capacidade ou as configurações do dispositivo usado para acessar esse conteúdo.

Em agosto de 2002, o IETF RFC  3305 apontou que o termo "URL", apesar do uso público generalizado, quase se tornou obsoleto e serve apenas como um lembrete de que alguns URIs atuam como endereços por ter esquemas que implicam em acessibilidade à rede, independentemente de tais uso real. Como os padrões baseados em URI, como Resource Description Framework, tornam evidente, a identificação de recursos não precisa sugerir a recuperação de representações de recursos na Internet, nem precisa implicar em recursos baseados em rede.

A Web Semântica usa o esquema HTTP URI para identificar documentos e conceitos no mundo real, uma distinção que tem causado confusão sobre como distinguir os dois. O TAG publicou um e-mail em 2005 sobre como solucionar o problema, que ficou conhecido como resolução httpRange-14 . O W3C posteriormente publicou uma Nota de Grupo de Interesse intitulada Cool URIs for the Semantic Web , que explicava o uso da negociação de conteúdo e o código de resposta HTTP 303 para redirecionamentos com mais detalhes.

Projeto

URLs e URNs

Um Uniform Resource Name (URN) é um URI que identifica um recurso por nome em um determinado namespace. Um URN pode ser usado para falar sobre um recurso sem sugerir sua localização ou como acessá-lo. Por exemplo, no sistema International Standard Book Number (ISBN), o ISBN 0-486-27557-4 identifica uma edição específica da peça Romeu e Julieta de Shakespeare . O URN dessa edição seria urn: isbn: 0-486-27557-4 . No entanto, não fornece informações sobre onde encontrar uma cópia desse livro.

Um Uniform Resource Locator (URL) é um URI que especifica os meios de agir sobre ou obter a representação de um recurso, ou seja, especificando seu mecanismo de acesso primário e localização de rede. Por exemplo, a URL http://example.org/wiki/Main_Pagerefere-se a um recurso identificado como /wiki/Main_Page, cuja representação, na forma de HTML e código relacionado, pode ser obtida por meio do Protocolo de Transferência de Hipertexto ( http:) de um host de rede cujo nome de domínio é example.org.

Um URN pode ser comparado ao nome de uma pessoa, enquanto um URL pode ser comparado ao seu endereço. Em outras palavras, um URN identifica um item e um URL fornece um método para localizá-lo.

Publicações técnicas, especialmente padrões produzidos pela IETF e pelo W3C , normalmente refletem uma visão delineada em uma recomendação do W3C de 30 de julho de 2001, que reconhece a precedência do termo URI em vez de endossar qualquer subdivisão formal em URL e URN.

URL é um conceito útil, mas informal: um URL é um tipo de URI que identifica um recurso por meio de uma representação de seu mecanismo de acesso primário (por exemplo, sua "localização" de rede), em vez de alguns outros atributos que possa ter.

Como tal, um URL é simplesmente um URI que aponta para um recurso em uma rede. No entanto, em contextos não técnicos e em software para a World Wide Web, o termo "URL" permanece amplamente utilizado. Além disso, o termo "endereço da web" (que não tem definição formal) geralmente ocorre em publicações não técnicas como sinônimo de um URI que usa os esquemas http ou https . Essas suposições podem causar confusão, por exemplo, no caso de namespaces XML que têm uma semelhança visual com URIs resolvíveis .

As especificações produzidas pelo WHATWG preferem URL em vez de URI e, portanto, as APIs HTML5 mais recentes usam URL em vez de URI .

Padronize no termo URL. URI e IRI [Identificador de Recurso Internacionalizado] são apenas confusos. Na prática, um único algoritmo é usado para ambos, portanto, mantê-los distintos não ajuda ninguém. URL também vence facilmente o concurso de popularidade dos resultados da pesquisa.

Embora a maioria dos esquemas de URI tenha sido originalmente projetada para ser usada com um protocolo específico e geralmente tenha o mesmo nome, eles são semanticamente diferentes dos protocolos. Por exemplo, o esquema http é geralmente usado para interagir com recursos da web usando HTTP, mas o arquivo de esquema não tem protocolo.

Sintaxe

Cada URI começa com um nome de esquema que se refere a uma especificação para atribuir identificadores nesse esquema. Como tal, a sintaxe URI é um sistema de nomenclatura federado e extensível em que a especificação de cada esquema pode restringir ainda mais a sintaxe e a semântica dos identificadores que usam esse esquema. A sintaxe genérica de URI é um superconjunto da sintaxe de todos os esquemas de URI. Ele foi definido pela primeira vez no RFC  2396 , publicado em agosto de 1998, e finalizado no RFC  3986 , publicado em janeiro de 2005.

A sintaxe genérica do URI consiste em uma sequência hierárquica de cinco componentes :

URI = scheme:[//authority]path[?query] [#fragment]

onde o componente de autoridade se divide em três subcomponentes :

authority = [userinfo@]host[:port]

Isso é representado em um diagrama de sintaxe como:

Diagrama de sintaxe URI

O URI compreende:

  • Um não vazio componente de esquema seguido por dois pontos (:), consistindo em uma sequência de caracteres começando com uma letra e seguida por qualquer combinação de letras, dígitos, mais (+), ponto (.) ou hífen (-). Embora os esquemas não façam distinção entre maiúsculas e minúsculas, a forma canônica é minúscula e os documentos que especificam esquemas devem fazê-lo com letras minúsculas. Exemplos de esquemas populares incluemhttp,https,ftp,mailto,file,data, eirc. Os esquemas de URI devem ser registrados naAutoridade para Atribuição de NúmerosdaInternet (IANA), embora esquemas não registrados sejam usados ​​na prática.
  • Um opcional componente de autoridade precedido por duas barras (//), compreendendo:
    • Um opcional subcomponente
    userinfo que pode consistir em umnome de usuárioe umasenhaopcionalprecedidos por dois pontos (:), seguidos por um símbolo de arroba (@). O uso do formatousername:passwordno subcomponente userinfo foi descontinuado por motivos de segurança. Os aplicativos não devem renderizar como texto não criptografado nenhum dado após os primeiros dois pontos (:) encontrados em um subcomponente userinfo, a menos que os dados após os dois pontos sejam uma string vazia (indicando que não há senha).
  • UMA subcomponente de host , que consiste em um nome registrado (incluindo, mas não se limitando a umnome de host) ou umendereço IP. OsendereçosIPv4devem estar emnotação ponto-decimaleosendereçosIPv6devem ser colocados entre colchetes ([]).
  • Um opcional subcomponente da porta precedido por dois pontos (:).
  • UMA componente de caminho , que consiste em uma sequência de segmentos de caminho separados por uma barra (/). Um caminho é sempre definido para um URI, embora o caminho definido possa estar vazio (comprimento zero). Um segmento também pode estar vazio, resultando em duas barras consecutivas (//) no componente de caminho. Um componente de caminho pode ser parecido ou mapeado exatamente para umcaminho de sistema de arquivos,mas nem sempre implica uma relação com um. Se um componente de autoridade estiver presente, o componente de caminho deve estar vazio ou começar com uma barra (/). Se um componente de autoridade estiver ausente, o caminho não pode começar com um segmento vazio, ou seja, com duas barras (//), pois os caracteres a seguir seriam interpretados como um componente de autoridade. O segmento final do caminho pode ser referido como um 'slug'.
  • Delimitador de consulta Exemplo
    E comercial ( &) key1=value1&key2=value2
    Ponto e vírgula ( ;) key1=value1;key2=value2
    • Um opcional componente de consulta precedido por um ponto de interrogação (?), contendo umastringdeconsultade dados não hierárquicos. Sua sintaxe não é bem definida, mas por convenção é mais frequentemente uma sequência depares de valordeatributoseparados por umdelimitador.
    • Um opcional componente de fragmento precedido por umhash(#). O fragmento contém umidentificador de fragmento quefornece orientação para um recurso secundário, como um título de seção em um artigo identificado pelo restante do URI. Quando o recurso principal é umdocumentoHTML, o fragmento geralmente é umidatributode um elemento específico e os navegadores da web rolarão esse elemento para exibição.

    Strings de octetos de dados em um URI são representados como caracteres. Os caracteres permitidos em um URI são os caracteres ASCII para as letras maiúsculas e minúsculas do alfabeto inglês moderno , os algarismos arábicos , o hífen , o ponto , o sublinhado e o til . Os octetos representados por qualquer outro caractere devem ser codificados em porcentagem .

    Do conjunto de caracteres ASCII, os caracteres : / ? # [ ] @são reservados para uso como delimitadores dos componentes URI genéricos e devem ser codificados por porcentagem - por exemplo, %3Fpara um ponto de interrogação. Os caracteres ! $ & ' ( ) * + , ; =são permitidos pela sintaxe URI genérica para serem usados ​​não codificados nas informações do usuário, host e caminho como delimitadores. Além disso, :e @pode aparecer não codificado no caminho, consulta e fragmento; e ?e /podem aparecer codificada como dados dentro da consulta ou fragmento.

    A figura a seguir exibe URIs de exemplo e seus componentes.

                     porta do host       userinfo ┌──┴───┐ ┌──────┴───────┐ ┌┴┐
                
      https: //john.doe@www.example.com: 123 / forum / questions /? tag = networking & order = newest # top
      └─┬─┘    └────────────┬──────────────┘ └────────┬────────────────────┬───────  └──────────────┬──────────────┘  └┬┘ 
      fragmento de consulta de caminho de autoridade de esquema                                                        
    
      ldap: // [2001: db8 :: 7] / c = GB? objectClass? one
      └┬─┘ └─────┬─────┘└─┬─┘ └──────┬───────
      consulta de caminho de autoridade de esquema
    
      mailto: John.Doe@example.com
      └─┬──┘ └────┬───────────────┘
      caminho do esquema
    
      notícias: comp.infosystems.www.servers.unix
      └┬─┘ └──────────────┬────────────────────────
      caminho do esquema
    
      tel .: + 1-816-555-1212
      └┬┘ └───────┬──────┘
      caminho do esquema
    
      telnet: //192.0.2.16: 80 /
      └─┬──┘ └─────┬─────┘│
      caminho de autoridade do esquema
    
      urn: oásis: nomes: especificação: docbook: dtd: xml: 4.1.2
      └┬┘ └───────────────────────┬────────────────────────────────────────────────────────────────────────
      caminho do esquema
    

    Referências URI

    Uma referência de URI é um URI ou uma referência relativa quando não começa com um componente de esquema seguido por dois pontos ( :). Um segmento de caminho que contém um caractere de dois pontos (por exemplo, foo:bar) não pode ser usado como o primeiro segmento de caminho de uma referência relativa se seu componente de caminho não começar com uma barra ( /), pois seria confundido com um componente de esquema. Esse segmento de caminho deve ser precedido por um segmento de caminho de ponto (por exemplo, ./foo:bar).

    Linguagens de marcação de documento da Web freqüentemente usam referências de URI para apontar para outros recursos, como documentos externos ou partes específicas do mesmo documento lógico:

    • em HTML , o valor do srcatributo do imgelemento fornece uma referência de URI, assim como o valor do hrefatributo do elemento aou link;
    • em XML , o identificador do sistema que aparece após a SYSTEMpalavra - chave em um DTD é uma referência de URI sem fragmentos;
    • em XSLT , o valor do hrefatributo do xsl:importelemento / instrução é uma referência URI; da mesma forma, o primeiro argumento para a document()função.
    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
    

    Resolução

    Resolver uma referência de URI em relação a um URI de base resulta em um URI de destino . Isso implica que o URI básico existe e é um URI absoluto (um URI sem nenhum componente de fragmento). O URI de base pode ser obtido, em ordem de precedência, a partir de:

    • o próprio URI de referência se for um URI;
    • o conteúdo da representação;
    • a entidade que encapsula a representação;
    • o URI usado para a recuperação real da representação;
    • o contexto da aplicação.

    Dentro de uma representação com um URI de base bem definido de

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

    uma referência relativa é resolvida para seu URI de destino da seguinte maneira:

    "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"
    

    URL munging

    URL munging é uma técnica pela qual um comando é anexado a um URL, geralmente no final, após um "?" token . É comumente usado no WebDAV como um mecanismo de adição de funcionalidade ao HTTP . Em um sistema de controle de versão, por exemplo, para adicionar um comando "checkout" a um URL, ele é escrito como http://editing.com/resource/file.php?command=checkout. Ele tem a vantagem de ser fácil para analisadores CGI e também atuar como um intermediário entre o HTTP e o recurso subjacente, neste caso.

    Relação com namespaces XML

    Em XML , um namespace é um domínio abstrato ao qual uma coleção de nomes de elementos e atributos podem ser atribuídos. O nome do namespace é uma string de caracteres que deve seguir a sintaxe URI genérica. No entanto, o nome geralmente não é considerado um URI, porque a especificação do URI baseia a decisão não apenas nos componentes lexicais, mas também no uso pretendido. Um nome de namespace não implica necessariamente em nenhuma das semânticas dos esquemas de URI; por exemplo, um nome de namespace começando com http: pode não ter conotação com o uso do HTTP .

    Originalmente, o nome do namespace poderia corresponder à sintaxe de qualquer referência de URI não vazia, mas o uso de referências de URI relativas foi preterido pelo W3C. Uma especificação W3C separada para namespaces em XML 1.1 permite que referências de identificador de recurso internacionalizado (IRI) sirvam como base para nomes de namespace, além de referências de URI.

    Veja também

    Notas

    Referências

    Leitura adicional

    links externos