DWEB 01.5 Estrutura de uma URL (Esquema, Host, Porta, Path, Query String)

A URL é, talvez, a peça da web com a qual usuários comuns mais convivem sem prestar atenção. Para um desenvolvedor front-end, contudo, ela é um instrumento de trabalho. Você vai ler URLs, escrever URLs, modificar URLs e depurar problemas de URL várias vezes por semana — possivelmente por dia. Saber separar mentalmente cada uma de suas partes é uma habilidade básica, comparável a saber ler um endereço postal: rua, número, complemento, bairro, cidade, CEP. Cada um desses elementos serve a um propósito, e quem entende isso comete menos erros e diagnostica mais rápido.

O que é uma URL?

URL significa Uniform Resource Locator, ou Localizador Uniforme de Recursos. Em português simples: um endereço que aponta para um recurso na web. Esse recurso pode ser uma página HTML, uma imagem, um arquivo PDF, um vídeo, uma planilha de dados, uma resposta de API — qualquer coisa que possa ser pedida e respondida via HTTP.

A URL foi padronizada pelo mesmo conjunto de propostas que originou a World Wide Web, no início dos anos 1990. A ideia central era simples e poderosa: cada recurso da web teria um endereço único, escrito sempre da mesma forma, que qualquer navegador (ou programa) saberia interpretar.

Anatomia de uma URL

Veja, abaixo, uma URL completa, com todas as partes possíveis presentes:

https://usuario:senha@www.exemplo.com.br:443/produtos/categoria/123?cor=azul&tamanho=m#descricao

Pode parecer assustador, mas cada parte tem nome e função. Vamos separar:

Parte	Trecho do exemplo	Função
Esquema	https	Indica o protocolo a usar
Separador	://	Marca o fim do esquema
Userinfo (raro)	usuario:senha@	Credenciais de acesso (uso desaconselhado hoje)
Host	www.exemplo.com.br	Nome do domínio do servidor
Porta	:443	Porta do servidor (opcional, padrão pelo esquema)
Path (caminho)	/produtos/categoria/123	Caminho do recurso dentro do servidor
Query string	?cor=azul&tamanho=m	Parâmetros adicionais
Fragmento	#descricao	Identifica um ponto dentro do recurso

Vamos olhar cada uma com mais calma.

Esquema

O esquema indica o protocolo que será usado para acessar o recurso. Os esquemas mais comuns na web são:

• http — protocolo HTTP comum, sem criptografia.
• https — protocolo HTTP com criptografia TLS (HTTPS).
• ftp — File Transfer Protocol, raro em navegadores modernos.
• mailto — abre o cliente de e-mail para enviar uma mensagem (ex.: mailto:contato@exemplo.com.br).
• tel — em dispositivos móveis, inicia uma chamada telefônica (ex.: tel:+5511999999999).
• file — aponta para um arquivo local na máquina do usuário.

No dia a dia do desenvolvedor front-end, https é o padrão. Sites profissionais não devem mais usar http puro, salvo em casos muito específicos.

Host

O host é o nome do servidor que vai responder a requisição — em essência, o nome de domínio que o DNS vai traduzir em um IP, conforme vimos no Tópico 1.4. Pode aparecer como:

• Um nome completo: www.leaoeducacao.com.br
• Apenas o domínio: leaoeducacao.com.br
• Um subdomínio: blog.leaoeducacao.com.br
• Um endereço IP literal: 203.0.113.42 (válido, mas raro em sites públicos)
• O nome especial localhost (que significa “meu próprio computador”, muito usado em desenvolvimento)

Porta

A porta é um número que indica o “canal” específico no servidor por onde a comunicação deve passar. Pense no servidor como um prédio com vários andares: cada serviço diferente roda em uma porta diferente. Os números mais usados na web são:

• 80 — porta padrão do HTTP.
• 443 — porta padrão do HTTPS.
• 3000, 5173, 8080, 8000 — comuns em ambientes de desenvolvimento local.

Como 80 e 443 são padrão para HTTP e HTTPS, na prática você quase nunca digita a porta em URLs do dia a dia — ela fica implícita. Mas, quando você está desenvolvendo localmente em uma porta diferente, ela aparece, e você precisa entendê-la. Por exemplo: http://localhost:3000/ significa “meu próprio computador, na porta 3000, sem HTTPS”.

Path (caminho)

O path é a parte que indica qual recurso específico dentro do servidor está sendo pedido. Funciona de modo semelhante a um caminho de arquivos em um computador. Exemplos:

• / — a raiz, ou seja, a página principal do site.
• /produtos — a página da seção de produtos.
• /produtos/categoria/123 — um produto específico dentro de uma categoria.
• /sobre/equipe — uma página interna.

É importante perceber que o path não precisa, hoje em dia, corresponder a uma pasta real no servidor. Em sites antigos, era assim — havia arquivos .html em pastas físicas. Em aplicações modernas, o path é interpretado pelo back-end, que decide o que devolver com base nele. Mesmo assim, a sintaxe do path mantém a estrutura de pastas para facilitar a leitura.

Query string (parâmetros de consulta)

Depois do path, pode vir uma query string — uma lista de pares “chave=valor” que servem para passar informações adicionais ao servidor. A query string começa com ? e cada par é separado por &. Exemplos:

• ?busca=caneca — uma busca por “caneca”.
• ?cor=azul&tamanho=m — filtros aplicados em uma listagem.
• ?pagina=2 — paginação.
• ?utm_source=newsletter&utm_campaign=natal2026 — parâmetros de marketing.

A query string é, no fundo, uma forma padronizada de o navegador “perguntar” algo ao servidor sem mudar o path. É muito comum em buscas, filtros, paginação e em parâmetros de rastreamento (os famosos UTM).

Fragmento

O fragmento começa com # e indica uma posição específica dentro do recurso. Ele não é enviado ao servidor: fica apenas no navegador. Seu uso clássico é levar a página a uma seção específica:

• https://exemplo.com.br/manual#instalacao — abre o manual e rola a página até o trecho marcado como instalacao.

Em aplicações web modernas, o fragmento também é usado por algumas técnicas de roteamento no front-end (você verá isso em frameworks como React, Angular ou Vue, em cursos posteriores).

Codificação de caracteres na URL

URLs têm restrições quanto aos caracteres que aceitam diretamente. Espaços, acentos, símbolos especiais e caracteres não-ASCII precisam ser codificados (encoded) em um formato chamado percent-encoding: o caractere é representado pelo seu código em hexadecimal precedido de %. Exemplos:

• Espaço vira %20 (ou, em algumas situações, +).
• ã vira %C3%A3.
• ?, & e # precisam ser escapados quando aparecem como dados (e não como separadores).

Quando você vê uma URL “estranha” com %20, %E7 ou %C3%A9, é porque algum caractere especial foi codificado. Navegadores, formulários e bibliotecas costumam fazer isso automaticamente — mas, quando você for construir URLs no código, precisará lembrar que existe essa regra.

Caminhos absolutos e relativos

URLs podem ser absolutas ou relativas:

• Uma URL absoluta começa do esquema: https://www.exemplo.com.br/produtos/123. Funciona em qualquer contexto, porque traz todas as informações.
• Uma URL relativa depende do contexto da página em que está. Por exemplo, dentro de uma página em https://www.exemplo.com.br/blog/post-1, um link escrito como /sobre aponta para https://www.exemplo.com.br/sobre, e um link outro-post aponta para https://www.exemplo.com.br/blog/outro-post. As URLs relativas são especialmente úteis dentro de um mesmo site, porque você não precisa repetir o esquema e o host em todos os links.

Você usará as duas formas em HTML, com frequência. Voltaremos a esse assunto na Aula 02.

Caso ilustrativo: lendo URLs como detetive

Imagine que você foi contratado para auditar a página de busca de uma loja online. Você abre o site e faz uma busca por “tênis preto tamanho 40”. O navegador exibe, na barra de endereço:

https://www.loja-exemplo.com.br/busca?q=t%C3%AAnis+preto&filtro=cor%3Apreto%26tamanho%3A40&pagina=1

Olhando essa URL com os olhos treinados que estamos construindo aqui, você pode imediatamente concluir:

• O site usa HTTPS — bom.
• O host é www.loja-exemplo.com.br.
• O recurso pedido está no path /busca.
• Os parâmetros são: q (a consulta de busca, t%C3%AAnis+preto, que decodificado é “tênis preto”), filtro (uma combinação codificada de cor e tamanho) e pagina (que vale 1).
• Não há porta, fragmento, nem userinfo.

Com cinco segundos de leitura, você já tem hipóteses sobre como a aplicação está organizada — e isso é exatamente o que torna um desenvolvedor mais rápido na hora de investigar problemas e construir soluções.

Caso ilustrativo, criado para fins didáticos.

Momento de aplicação prática

Escolha três sites que você usa com frequência (uma loja, um portal de notícias e uma rede social, por exemplo). Em cada um, navegue por dentro do site (clique em menus, faça buscas, abra produtos ou perfis) e observe a URL na barra de endereço. Para cada uma das URLs que aparecerem, tente identificar:

1. Qual é o esquema?
2. Qual é o host?
3. Qual é o path?
4. Há query string? Quais são as chaves e os valores?
5. Há fragmento?

Esse exercício, feito por uma semana com regularidade, treina o olho. Em pouco tempo, você passa a “ver” URLs como mapas, e não como sequências aleatórias de caracteres.

Armadilha comum

URLs não podem conter espaços nem caracteres especiais sem codificação. Um erro comum em iniciantes é colocar, dentro de um link em HTML, algo como arquivo de relatório.pdf. O navegador, em geral, vai conseguir consertar para arquivo%20de%20relat%C3%B3rio.pdf, mas nem sempre. O conselho profissional é simples: mantenha nomes de arquivos e segmentos de path em minúsculas, sem acentos e usando hífen no lugar de espaço — por exemplo, relatorio-de-vendas.pdf. Essa regrinha evita uma classe inteira de bugs e melhora, de quebra, a indexação em mecanismos de busca.

O que vem a seguir

Já entendemos como o endereço de um recurso é montado. Falta entender o que o navegador faz nesse endereço: ele pode pedir o recurso (leitura), enviar dados novos (criação), atualizar dados existentes (edição), apagar (remoção). Cada uma dessas intenções é expressa por um método HTTP diferente. É o próximo tópico, e é a base do diálogo que toda aplicação web faz com seu servidor.