SAP Gateway Zero-to-Hero — Pt. 5.2

URI, URL e URN — Tendo uma visão de Desenvolvedor, e não apenas de usuário!

E aweeeee meu povo!!!!

Tenho que confessar que este post não era planejado, e deveria ser lançado nessa presente data a parte 6, parte essa que é finalmente a criação do nosso primeiro serviço utilizando o framework SAP Gateway.

Entretanto, nos últimos posts eu venho falando de muitas novas palavras, e uma em especial tem sido o alvo de maior dúvida entre os leitores: URL, URI e URN.

E de verdade URL é algo que realmente todos profissionais que se dizem desenvolvedores de verdade devem entender, e se tratando de uma série de posts relacionado aos fundamentos básicos da Web, nada mais justo que entendamos sobre, aliás precisamos fazer valer o nome da série Zero-to-Hero.

Recurso

Porém antes de iniciarmos a nossa viagem sobre URLs, é preciso saber sobre o que elas se tratam, e no geral o que um URL visa é endereçar um recurso, que pode ser um serviço, uma imagem, um arquivo ou um qualquer coisa do tipo. Como vimos em posts passados, o objetivo de uma requisição HTTP é sempre acessar um recurso, e todo recurso é identificado pelo que chamamos de: Uniform Resource Identifier (URI).

O endereço de um recurso é mapeado na maioria das vezes por um Uniform Resource Locator (URL — Perceba que estamos falando de um localizador e não de uma localização, por isso se trata de o URL no masculino), e esta é a forma mais comum de localizar uma URI, isto mesmo o URL nada mais é que o localizador baseado no endereço de uma URI.

Existe também o Uniform Resource Name (URN) que soa uma pouco complexo, mas no fundo nada mais é que um tipo de identificador para uma URI mas em um namespace, ou seja é um localizador também mas que desta vez é baseado no nome da URI.

A vantagem do URN comparado a utilização do URL, é que quando é movido o conteúdo de um determinado recurso para um outro espaço, seja um novo site ou apenas uma pasta diferente mas no mesmo espaço, o URL simplesmente para de funcionar, entretanto o URN por localizar o nome do recurso continua funcionando. Um exemplo de URN:

urn:def://bar8-sap-gateway-zero-to-hero-verbos-http

Comparado ao URL:

https://bar8.com.br/sap-gateway-zero-to-hero-verbos-http

Mas o mais importante é ter é o seguinte:

mais em: https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn

URI

Muito engraçado escrever sobre URI ou URL em especial, quem sabe chamar de link ou endereço, independente de como você chame existe uma grande diferença entre saber sobre URLs como usuário, e saber sobre URLs como um desenvolvedor.

Hoje não podemos mais afirmar que um URL começa com http:// e termina com .com.br, pois os tempos mudaram bastante, mas em boa parte dos casos ainda temos essa referência, então vamos dissecar do que é composta um URL:

<esquema>://<usuário>:<senha>@<host>:<porta>/<caminho>;<parâmetros>?<query>#<fragmento>

Vish… Mas não assusta ainda não, porque não é sempre que você terá uma URL assim, mas aqui o foco é ser um desenvolvedor descente né! Então vamos entender

1. Esquema ou Protocolo: Este é o responsável por especificar o protocolo que será utilizado para acessar o recurso que faz referencia no resto da URL. Os exemplos para protocolos que podem ser utilizado na área do esquema são: http, https, ftp, file, mailto, ssh, tel, urn. O padrão dentro de uma URL para um esquema é iniciando sempre com uma letra e separado com dois pontos (:), e ai você pode se perguntar sobre o //, e simples, o // faz parte do próxima parte da URL;
2. Usuário, Senha: Estes são membros da parte de "autoridade" da URL. Não é muito comum informar o nome do usuário e a senha na URL, mas quem utiliza SSH ou apenas trabalha com GitHub por exemplo, já viu isso algumas vezes. O usuário e senha é requerido quando se faz necessário alguma autenticação para acesso ao recurso, e sua notação é simples, tendo sempre o usuário e senha separado por dois pontos (:), e a utilização de um arroba ("@”) para indicar o inicio do host. Uma outra forma muitos comum na utilização de usuário e senha na URL é quando precisamos acessar uma URL FTP;
3. Host: Também conhecido como domínio, sem dúvida o trecho mais familiar para todos, esse componente também é membro da parte de autoridade da URL. Uma informação importante é que podemos acessar um host informando um endereço de IP, quando utilizamos um nome de domínio (que no caso são 99,9% das vezes), o nome nada mais é do que um alias para o IP que será resolvido via DNS;
4. Porta: E fechando os membros honorários da parte de autoridade temos a porta. Como costumamos dizer é com essa informação na URL que dizemos ao servidor onde que a aplicação que estamos prestes a conectar está "ouvindo";
5. Caminho: A partir do momento que inserimos uma barra (/) passamos a informar ao servidor, onde a nossa aplicação está situada. É possível inserir componentes dentro de cada caminho desde que seja utilizado ponto e virgula (;), como no exemplo abaixo:

https://bar8.com.br/zero-to-hero-verbos;parametro=GET/index.html

6. Parâmetros: São utilizados como no exemplo acima, mas muito mais utilizado em query strings. Na necessidade de múltiplos parâmetros utilizamos o ponto e virgula como (;)separador.

7. Query: Quando começarmos a utilizar o SAP Gateway, e desejarmos filtrar uma pesquisa durante uma requisição GET, são as queries que irão nos ajudar. Sabemos que uma query foi iniciada quando na URL é utilizado o ponto de interrogação (?), a partir dai sabemos que estamos especificando algo para a aplicação que está prestes a ser requisitada. E aliado ao separador ponto e virgula (;), ou mais comum no dia a dia o símbolo & podemos realizar múltiplas queries em uma requisição.

https://bar8.com.br/zero-to-hero-verbos/servico/?param=bar&param=8
https://bar8.com.br/zero-to-hero-verbos/servico/?param=bar;param=8

8. Fragmento: Muito comum utilizar este componente quando necessitamos navegar por trechos específicos na página HTML. Com este recurso é possível criar componentes como âncoras em sua página, e então aliado ao símbolo hashtag (#) é possível ao carregar o HTML navegar direto para determinado trecho. No exemplo abaixo, poderia ter inserido âncoras na minha página como referência, então acessando o link abaixo, após o HTML ser carregado você seria levado diretamente ao trecho do post que falo sobre o verbo POST:

https://bar8.com.br/zero-to-hero-verbos#POST

Então agora que conhecemos mais sobre os aspectos que compõem uma URL, vamos a algumas observações importantes.

URL Absoluta e Relativa

Uma coisa que todos que trabalham no ambiente web precisam saber é que cada byte conta. Por isso até mesmo se podemos economizar no tamanho da URL vamos economizar.

Em termos práticos a URL Absoluta contém todas as informações necessárias à localização de um recurso, isso significa que ela terá todos aspectos possíveis de uma URL como mencionado anteriormente, tornando a quantidade de texto (em consequência bytes) maior. Como é possível ver no exemplo abaixo:

<script src="http://www.bar8.com.br/js/script.js"></script>

No entanto a URL Relativa localiza um recurso usando uma URL absoluta como ponto inicial. Em geral, uma URL relativa consiste apenas no Caminho e, opcionalmente, no Recurso.

Entretanto, uma experiência pessoal mas que algum tempo depois descobri que existia uma documentação sobre o assunto, os sistemas devem usar sempre que possível URLs relativas para acessar seus próprios recursos como imagens, CSS, scripts, etc. Isso pois a portabilidade fica muito mais simples quando necessário. Abaixo é possível dar uma conferida na documentação que me referi anteriormente:

ISO/IEC 9126 - Wikipédia, a enciclopédia livre

Temos três tipos de URL relativa, e são elas:

• URL relativa ao lugar em que o arquivo atual está — Abaixo temos dois exemplos de URL Relativa, a primeira está acessando um arquivo CSS no mesmo diretório, e a segunda está acessando o arquivo CSS três níveis a partir do diretório atual:

<a href="main-branding-base.css">estilo</a>
<a href="../../assets/main-branding-base.css">estilo</a> 

• URL relativa ao protocolo atual — Neste exemplo estamos acessando um outro arquivo a partir da raiz do site:

<a href="//bar8.com.br/sap-gateway-zero-to-hero.html">Link</a>

O interessante desde exemplo é que neste caso somos capazes a acessar uma URL sem nos preocupar com o esquema (protocolo). Este caso é muito usado para manter a compatibilidade no uso de HTTPS ou HTTP.

• URL relativa a raiz— Quando estamos trabalhando com arquivos de uso global:

<a href="/main-branding-base.css">estilo</a>

No meu dia a dia as formas que utilizo mais é um misto de relativo ao arquivo com relativo à raiz, sendo relativo à raiz para coisas globais, e relativo ao arquivo atual para coisas que podem mudar de nível.

Um pouco mais sobre Query

Este recurso realmente é fantástico, entretanto é necessário tomar alguns cuidados, pois caso você não controle os caracteres que estão sendo informados em sua URL, você poderá ter uma triste surpresa recebendo uma URL Injection. Este termo é dado quando alguém tenta atacar o seu serviço ou site através da inserção de algum código malicioso utilizando a URL para isso.

Como disse no post anterior, agora estamos na web e já que você decidiu sair do cercadinho chamado SAP é melhor você estar preparado.

Para lidar com a URL Injection é importante você ter conhecimento dos caracteres especiais que são utilizados, pois conhecendo cada caracter você será capaz de se previnir desse tipo de ataque.

Caracteres Especiais

Antes de sair utilizando qualquer caracter em suas URLs por favor o mínimo que você deve fazer é respeitar o trabalho de Tim Berners-Lee, Roy Fielding, Larry Masinter, and Mark McCahill, e então a melhor forma de respeitar é lendo suas RFCs que irei deixar os links mais abaixo. Existe sim um padrão e que deve ser seguido. Os caracteres especiais são separados em alguns grupos:

• Seguros: Caracteres alfanuméricos [0-9a-zA-Z] (se você não sabe o que isso significa deveria dar uma lida em: Regex), e os seguintes caracteres:

"$" | "-" | "_" | "." | "+" | "!" | "*" | "'" | "( )") | ","

• Reservados:

“;” | “/” | “?” | “:” | “@” | “&” | “=” | “+” | “$” | “,”

• Não seguros: Além dos caracteres abaixo, espaços também são classificados como caracteres não seguros:

" | "< >" | "#" | "%" | "{}" | "|" | "\" | "^" | "~" | "[]" | "`" 

Para maiores detalhes sobre o porque de cada classificação recomendo fortemente a leitura da seguinte RFC:

RFC1738: Uniform Resource Locators (URL)

#Curiosidades

• Um esquema para ser oficial precisa estar registrado na Internet Assigned Numbers Authority (IANA), entretanto existem esquemas que não são oficiais, e um exemplo pode ser o SVN.

E é isso ai, não deixe de conferir as referências abaixo, e se curtiu o post não deixe de participar comentando, compartilhando ou simplesmente segurando esse botão de aplausos para mostrar que é esse tipo de conteúdo que você deseja ter por aqui. Muito obrigado e até mais!

#Bar8Indica

RFC3986: Uniform Resource Identifier (URI): Generic Syntax

RFC1738: Uniform Resource Locators (URL)

#LeiaTambém

SAP Gateway Zero-to-Hero — Pt.1

SAP Gateway Zero-to-Hero — Pt.2

SAP Gateway Zero-to-Hero — Pt.3

SAP Gateway Zero-to-Hero — Pt.4

SAP Gateway Zero-to-Hero — Pt.5