As RFCs (Request for Comments - Pedido/Requisição para Comentários), na esmagadora maioria dos casos, são somente sugestões e não regras obrigatórias.

URI é um termo genérico, é uma forma generalizada de denominar tanto URLs quanto URNs. As RFCs aconselham chamar tudo de URI para evitar confusão, apesar de que todo mundo chama de URL.

URI (Uniform Resource Identifier - Identificador Uniforme de Recurso) é a sequência de caracteres colocada na barra de endereço do navegador e/ou digitada numa linha de comando.

URL (Uniform Resource Locator - Localizador Uniforme de Recurso), grosso modo, é um link para um site (https://www.vivaolinux.com.br).

URN (Uniform Resource Name - Nome Uniforme de Recurso), por exemplo, pode ser um endereço de e-mail quando tem "mailto:" antes (mailto:John.Doe@example.com).

E tanto o URL quanto o URN são URIs.

O URL e o URN diferem, basicamente e antes de outras coisas, na sintaxe, na forma como são escritos, mas os dois são URIs.

No URL absoluto sempre aparece o protocolo (htttp, ftp, gopher, etc), no URL abreviado e no URN nem sempre aparece o protocolo.

Formato básico de um URL: http://www.ietf.org/rfc/rfc2396.txt

Formato básico de um URN: urn:oasis:names:specification:docbook:dtd:xml:4.1.2

E, como vimos, temos o URL abreviado que, de http://info.cern.ch/hypertext/WWW/Addressing/URL/URI_Overview.html, o URL abreviado é /hypertext/WWW/Addressing/URL/URI_Overview.html.

O que, por dedução, daria para considerar um endereço de e-mail (John.Doe@example.com) como um URN abreviado, apesar de nenhuma RFC citar.

Um URN é um nome com escopo global que não implica um local, pois tem o mesmo significado em todos os lugares.

A coisa parece confusa, pois envolve conceitos, nomes e coisas reais, mas é só abstrair (decompor em partes) e partir de onde se está para daí então fazer as comparações, por exemplo, o conceito de "non-networked" citado antes: o computador em relação a uma rede interna e a um recurso buscado dentro dele mesmo é "non-networked" e a rede interna em relação a uma rede externa é "non-networked" e uma rede externa em relação a "world wide web" como um todo é "non-networked".

Para fins de entendimento, "Solicitação" é o URI, é a sequência completa de caracteres e "Requisição" é a Request-URI. A Request-URI está dentro do URI e a query string está dentro da Request-URI.

No URI: https://www.vivaolinux.com.br/busca/?cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster

A Request-URI é a parte: "/busca/?cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster".

A query string é a parte após o sinal de interrogação: "cx=partner-pub-3535276187000580%3A4725058203&cof=FORID%3A10&ie=ISO-8859-1&q=Buckminster".

Tecnicamente (rfc1737):

Um URN identifica um recurso ou unidade de informação. Pode identificar, por exemplo, conteúdo, uma apresentação específica de conteúdo intelectual; tudo o que uma autoridade de atribuição de nomes determina é distintamente entidade nomeável.

Um URL identifica o local ou um contêiner para uma instância de um recurso. Um recurso identificado por um URN pode residir em um ou mais locais a qualquer momento; um URL pode mover-se ou pode não estar disponível. É claro que nem todos os recursos irão se mover durante suas vidas, e nem todos os recursos, embora identificáveis e identificados por um URN serão instanciados a qualquer tempo.

Como tal, um URL identifica um local onde um recurso pode residir, ou um contêiner, distinto do próprio recurso identificado pelo URN.

Exemplo: mailto:John.Doe@example.com; tem-se o esquema mailto, o identificador John.Doe e o localizador example.com. Segundo a rfc2368, pode se considerar "example.com" como o URL do URN.

Em todo e qulquer URI (a sequência de caracteres digitadas na barra do navegador ou outro lugar) que tenha, por exemplo, "example.com" (localizador), tenha o protocolo e tenha ou não tenha um nome/identificador (John.doe) é um URL.

Um URC (citado no corpo do artigo) é um conjunto de informações de meta-nível sobre um recurso. Alguns exemplos de tais meta-informações são: proprietário, codificação, restrições de acesso (talvez para casos específicos), custo, etc.

De onde conclui-se que um URI pode ser somente um URL ou um URN, como pode ser formado por um URL dentro de um URN ou por um URN dentro de um URL.

URI é um termo genérico, é uma forma generalizada de denominar tanto URLs quanto URNs.

URL e URN são distintos entre si, pois aquele é um Localizador (no sentido de identificador de local do recurso) e este é um Nome (no sentido de identificador de nome do recurso).

Recurso, no caso, pode ser qualquer coisa que acessamos/abrimos/baixamos/instalamos/instanciamos/etc, dentro do computador isolado (non-networked) ou em rede.

Lembrando que "non-networked" em questão de URI é um conceito genérico que parte de onde se está, por exemplo, "non-networked" pode ser um acesso a uma pasta da rede interna em comparação a uma rede externa, bem como pode ser um acesso a uma pasta no próprio computador em relação a qualquer rede.

Em questão de segurança o melhor é sempre utilizar HTTPS (SSL/TLS, o TLS é uma versão avançada do SSL) tanto com GET quanto com POST ou qualquer outro método e atualizar para a versão 2 do HTTP (HTTP/2), apear de que tem alguns recursos e navegadores que ainda não suportam, mas nesse caso, a escolha entre http/1.1 ou http/2 é automática para cada recurso.

GET (Pegar):

Acrescenta dados de formulário ao URL em pares nome/valor.

O comprimento de um URL é limitado (cerca de 2.000 caracteres, depende do navegador).

Como a requisição GET é montada via URL ela possui um tamanho limitado de mensagem que pode ser enviada.

Não confunda o tamanho total do URL com o tamanho da string de requisição, posto que esta (string de requisição) está geralmente dentro daquele (URL).

Só pode ser usado para enviar dados ASCII.

Nunca use GET para enviar dados confidenciais!

Útil para envios de formulários onde um usuário deseja marcar o resultado.

GET é melhor para dados não seguros, como strings de consulta sem dados confidenciais, aliás, o Google usa bastante o GET em suas pesquisas, pois é mais rápido.

Utiliza o método Stack para passar as variáveis de formulário.

Um "hiperlink" que aponta para uma "action" será sempre GET.

A RFC 2616, "Protocolo de Transferência de Hipertexto – HTTP/1.1", não especifica nenhum requisito para o comprimento do URL.

Dependendo do navegador, quando exceder o limite a página exibe um erro ou não exibe mais o URL.

Pode-se aumentar o tamanho da requisição GET, mas, para tanto, terá de mexer nas configurações da linguagem utilizada, do servidor web (Apache, Nginx, IIS, etc) e no código deverá ser configurado.

Lembrando que o tamanho do URL é uma coisa e a Request-URI com os dados é outra.

Lembrando também que o tamanho da Request-URI ou somente URI (linha completa na barra de endereços) é limitado pelo navegador e/ou pelo servidor web utilizado, ou seja, pelos desenvolvedores de cada.

Nos testes os limites encontrados são os seguintes:

• Edge: aceita 62.877 caracteres, exibe 10.104;
• Chrome: aceita 62.877 caracteres, exibe 10.115;
• Firefox: 61.960 caracteres, exibe 31.733;
• Ópera: 22.628 caracteres, exibe 10.231;
• Safari: 253.864 caracteres (o Safari não sei se aceita mais caracteres, pois parei de testar nesse limite), exibe 6.370.

Deixo bem claro que esses limites não representam exatamente os limites do GET, pois tem outros fatores envolvidos, mas dão uma boa idéia.

POST (Publicar):

Acrescenta dados do formulário dentro do corpo da solicitação HTTP (os dados não são mostrados no URI).

Não tem limitações de tamanho.

Podem ser enviadas imagens, etc.

O navegador enviará os dados ao servidor web para serem processados (exemplo, adicionar dados a um banco de dados e/ou enviar informações confidenciais, como senhas);

Os envios de formulários com POST não podem ser marcados como favoritos; a página pode ser marcada como favorita, mas ficará sem o POST anexado, pois ele só funcionará quando for feita outra requisição.

Utilizado para enviar dados para o servidor, para atualizar ou criar um novo recurso.

Utiliza o método Heap para passar as variáveis de formulário.

Em relação aos testes com o tempo das requisições coloquei basicamente os códigos sem analisar profundamente as saídas, mas realizei vários testes e você pode fazer e/ou incrementar os códigos, caso quiser.

Uma conclusão segura é que o POST é o mais rápido, porém, em se tratando de poucos dados (aproximadamente <= 2MB) a diferença de desempenho e velocidade praticamente não existe entre GET e POST, sendo que algumas vezes o GET foi mais rápido, pois ainda que o tamanho dos dados enviados seja o determinante, não depende somente do tamanho dos dados enviados, mas também da banda do cliente e do servidor, da conexão, etc.

Caso você for um programador, usar URIs extremamente longos geralmente são um erro. Mantendo os URIs com menos de 2.000 caracteres, funcionará em praticamente qualquer combinação de software cliente e servidor.

Com GET o tamanho máximo da solicitação depende do lado do servidor e também do lado do cliente (no caso, o navegador). Use 2.000 caracteres ou menos para o GET; caso necessitar aumentar esse limite, aumente para um máximo de 8.000 caracteres, como sugerido na RFC 9110 (8.000 octetos), lembrando que 1 Byte tem oito bits (um octeto) e para formar um caractere é necessário 1 Byte, então 8.000 octetos são 8.000 mil caracteres.

Referências

• Universal Resource Identifiers in WWW: https://www.rfc-editor.org/rfc/rfc1630
• Functional Recommendations for Internet Resource Locators: https://www.rfc-editor.org/rfc/rfc1736
• Functional Requirements for Uniform Resource Names: https://www.rfc-editor.org/rfc/rfc1737
• URN Syntax: https://www.rfc-editor.org/rfc/rfc2141
• The mailto URL scheme: https://www.rfc-editor.org/rfc/rfc2368
• Uniform Resource Identifiers (URI): Generic Syntax: https://www.rfc-editor.org/rfc/rfc2396
• Hypertext Transfer Protocol -- HTTP/1.1: https://www.rfc-editor.org/rfc/rfc2616
• Report from the Joint W3C/IETF URI: https://www.rfc-editor.org/rfc/rfc3305
• Uniform Resource Identifier (URI): Generic Syntax: https://www.rfc-editor.org/rfc/rfc3986
• Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content: https://www.rfc-editor.org/rfc/rfc7231
• HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110
• HTTP/2: https://datatracker.ietf.org/doc/html/rfc9113
• Status Code Registration: https://www.rfc-editor.org/rfc/rfc9110#name-status-code-registration
• O que é HTTP, Request, GET, POST, Response, 200, 404? | Blog da TreinaWeb
• PHP: hrtime - Manual
• PHP: Suporte ao método PUT - Manual
• PHP: $_SERVER - Manual
• PUTting data fields with PHP cURL | LornaJane
• Bloquear request methods de HTTP
• GET, POST, PUT e DELETE · Desenvolvimento Distribuído com Java EE
• HTML form method Attribute
• Just a moment...