#1 — Voltando ao Básico…URL.
Olá Dev’s. Tranquilo?, aqui enquanto não der 404 tá de boa.
Continuando a série baseada nos estudos básicos do universo … anteriormente falamos sobre Recursos, agora vamos tentar entender a topologia básica de uma URL(RFC 1738).
Vamos pressupor a seguinte URL(uniforme resource locator):
Ela representa um recurso específico na internet, isto é, através dela posso interagir com a web. Como já falei no artigo anterior:
“Um documento(json,xml,doc,pdf etc etc…),uma página HTML, um vídeo, uma foto, basicamente o que pode ser endereçado e nomeado na rede.”
Podemos dividir o endereçamento em 3 partes:
1 — O “http” que vem antes do “://” é chamado de URL Scheme, ele informa como acessar o recurso, nesse caso em particular, está comunicando ao browser que ele deve utilizar o hypertext transfer protocol( ou http =) ). Masssss poderia também ser FTP (RFC 959 — transferência de arquivos ) ou mailto (RFC 2368 — endereçamento de email).
Tudo que vai depois do “://” é específico do scheme, como por exemplo: Uma URL http padrão não é compatível com uma URL mailto padrão, e vice e versa.
2 — “meuexemplo.com” é o Hostname, ele diz ao browser qual o nome do computador que está guardando o recurso. O computador utiliza o DNS(RFC 1035 — Domain Name System) pra traduzir o meuexemplo.com em um endereço de rede(afinal, ninguém quer ficar digitando número de ip(RFC 791, só pra registrar).
3 — “/computadores/1234/” esse trecho é conhecido como URL path, o host “meuexemplo.com” deve reconhecer o caminho desse recurso específico e responder apropriadamente ao cliente.
Massss “isso quer dizer que se eu acessar, (www.meuexemplo.com/computadores/1234/) exatamente, eu vou ter um único recurso (arquivo)?”. Pois bem … sim, pode ser um caminho para um arquivo único tipo, meupc.jpg ou meupc.png ou não ...ele mais comumente pode ser uma página HTML com vários recursos atrelados (ex: css, js, dados do banco de dados e etc). recursos podem ser dinâmicos e assumir mutiplas representações(*spoiler*) meus xuxuzis(plural geneticamente modificado de xuxu).
Explicado o básico … continuemos …
Portas, Query strings e Fragmentos.
Bem, agora sabemos que uma URL tem hostname e path, observe a nossa url seguinte:
http://www.meuexemplo.com:80/
Aquele numerozinho colocado ali capirotisticamente(sim! acabei de criar essa palavra), é conhecido como Porta. Na prática já é padrão nos navegadores a porta 8080/tcp, então não precisa estar explicita toda vez que você digitar uma url. A menos que por algum motivo você esteja utilizando uma porta diferente(o que na vida de dev, não é algo tão raro assim).
Agora temos a seguinte URL:
Tudo o que vem depois do “?” É conhecido como Query string (ou só query para os íntimos). Elas são basicamente usadas para a passagem de informação no formato “chave-Valor” para o servidor.(no exemplo acima eu quero que o motor de busca do bing me traga os resultados referentes a computadores).
Eeeee se eu quiser passar mais de um parâmetro para o servidor? simples!, utilize o “&” entre cada “chave-valor” como no exemplo abaixo:
http://www.meuexemplo.com/computadores?cor=branco&marca=hp
As query strings terão um importantíssimo papel quando formos falar sobre REST e API’s (*Spoiler*).
E pra finalizar …
Observe esta URL:
http://stackoverflow.com/questions/153735/what-are-rfcs/153841#153841
A informação depois do “#”, é conhecida como Fragmento, entretanto, ele é um pedaço de informação bem diferente dos outros, enquanto todos os outros elementos que eu citei acima são processados pelo servidor, o fragmento é processado pelo cliente.(wooow!!). Ele é utilizado pra marcar determinada sessão do recurso, o exemplo mais básico, é ele marcando um elemento HTML numa página, pelo seu element ID(como no caso acima “#153841” é referente a um comentário, em específico na thread “what-are-rfcs” no “stackoverflow”).
Resumindo tudo …
Se formos juntar tudo o que foi visto até agora, montamos uma visão sobre a URL da seguinte forma:
<scheme>://<hostname>:<port>/<path>?<query>#<fragment>
Por hora é isso!! No próximo artigo, vamos dar uma volta em URL Encoding, Media Type e Contente Type.
Até a próxima =)
“Acredite nos métodos, tecnologias vão e vem.”
Referências: What Every Web Developer Should Know About HTTP
