Este post foi extraido de uma apostila de um curso que ministrei em 2007, eu queria passar este texto para um colega novo do trabalho e não tinha o texto disponível, então resolvi publicar isto aqui no blog que vai ser útil para mim e pode ajudar mais alguem também
PROTOCOLO://[USUARIO[:SENHA]@]ENDERECO_SERVIDOR/CAMINHO_NO_SERVIDOR?parametro=valor&outro_parametro=outro_valor#ancoraNaPagina
Por exemplo:
http://www.google.com/search?q=ruby+on+rails
onde:
Como uma URL não pode conter espaços os espaços são substituídos pelo sinal “+”, isto se chama codificar o parâmetro.
Como uma URL não aceita nenhum caractere com código ASCII maior que 127, qualquer caractere nesta categoria precisa ser codificado. Esta codificação consiste em substituir os caracteres por um “%” mais 2 dígitos numéricos representando o código ASCII em hexadecimal do caractere desejado, como na tabela a baixo:
| Caractere | Código Hexadecimal |
| $ | 24 |
| & | 26 |
| + | 2B |
| , | 2C |
| / | 2F |
| : | 3A |
| ; | 3B |
| = | 3D |
| ? | 3F |
| @ | 40 |
| Espaço | 20 |
| “ | 22 |
| < | 3C |
| > | 3E |
| # | 23 |
| % | 25 |
| { | 7B |
| } | 7D |
| | | 7C |
| \ | 5C |
| ^ | 5E |
| ~ | 7E |
| [ | 5B |
| ] | 5D |
| ` | 60 |
Alguns destes caracteres são aceitáveis em uma URL, mas em algumas situações precisam ser codificados, como por exemplo o # que pode ser utilizado no final de uma URL para indicar ao browser qual parte da página mostrar, quando não for utilizado para este fim, deve ser codificado para evitar confusões.
Cabeçalhos HTTP são uma forma de passar parâmetros extras, além da URL do browser para o servidor. Normalmente, estes parâmetros são utilizados para informar ao servidor as capacidades do browser e preferências do usuário, mas podem também ser utilizados para trocar dados adicionais além dos informados pelo usuário (que podem ser passados pela URL).
Os cabeçalhos HTTP são enviados com o seguinte formato, logo depois da URL e antes da primeira linha em branco na requisição:
nome: valor
O valor dos cabeçalhos deve ser codificados utilizando a mesma tabela de conversão das URLs.
O usuário digita no browser a URL: http://www.google.com/search?q=ruby+on+rails
O browser abre uma conexão TCP/IP na porta 80 (padrão) do servidor www.google.com e envia o seguinte texto:
GET http://www.google.com/search?q=ruby+rails HTTP/1.0 User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35 i686) <Linha em branco no final>
O Servidor Responde:
HTTP/1.0 200 OK Cache-Control: private Content-Type: text/html; charset=ISO-8859-1 Set-Cookie: PREF=ID=059bd3c506c56f82:TM=1189888548:LM=1189888548:S=hV0hCZi26b1SuRY7; expires=Mon, 14-Sep-2009 20:35:48 GMT; path=/; domain=.google.com Server: gws Date: Sat, 15 Sep 2007 20:35:48 GMT Connection: Close <html><head> <Resto do HTML da página>
O método GET é utilizado para buscar o conteúdo de uma URL e o conteúdo retornado para a mesma URL deve ser sempre o mesmo. Isso facilita que o browser possa guardar páginas em cache por algum tempo para melhorar a experiência do usuário.
O método POST é utilizado para enviar dados para o servidor. Esse método não possui a obrigatoriedade de ter sempre o mesmo resultado para os mesmos dados enviados.
O método PUT é utilizado para criar recursos no servidor. Ele possui a característica do método GET, de ter a mesma resposta para o mesmo conteúdo enviado.
Este método é utilizado para remover recursos do servidor.
O método HEAD serve para solicitar ao servidor apenas o cabeçalho do conteúdo com os headers, para que o cliente decida se precisa requisitar o conteúdo completo ou não.
Os métodos mais utilizados pela maioria das aplicações são o GET para buscar dados e o POST para enviar dados. Os métodos PUT e DELETE raramente são suportados por uma aplicação, mas são bastante úteis quando se deseja implementar Web Services seguindo o padrão REST. Alguns outros protocolos utilizam métodos adicionais e até definem alguns novos, como por exemplo o protocolo WebDav.
Os códigos de resposta HTTP possuem 4 famílias básicas que serão apresentadas abaixo. Mais informações sobre estes códigos de resposta podem ser encontradas nesta URL: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Como o protocolo HTTP não mantém estado portanto, cada request é independente. Para solucionar este problema os cookies podem informar ao servidor quem é o cliente que está acessando o recurso.
Segue uma lista de alguns cabeçalhos bastante utilizados.
Bom, acho que era isto, claro que isto não é tudo sobre formação de URLs e sobre o protocolo HTTP, mas já é um bom começo.