HTTP define diferentes formas de interagir com o servidor, e existem 4 métodos básicos, a saber: GET, POST, PUT e DELETE. O nome completo da URL é um descritor de recursos, podemos pensar assim: um endereço de URL, usado para descrever um recurso em uma rede, e GET, POST, PUT, DELETE em HTTP corresponde às quatro operações de verificar, modificar, adicionar e excluir esse recurso. Neste ponto, você deve ter uma compreensão geral: GET geralmente é usado para obter/consultar informações de recursos, enquanto POST é geralmente usado para atualizar informações de recursos.
1. De acordo com a especificação HTTP, o GET é usado para recuperação de informações e deve ser seguro e idempotente.
(1). A chamada segurança significa que a operação é usada para obter informações, e não para modificá-las. Em outras palavras, pedidos GET geralmente não devem ter efeitos colaterais. Ou seja, ele só obtém informações de recursos, assim como a consulta de banco de dados, e não modifica, adiciona dados ou afeta o estado do recurso.
* Nota: O significado de segurança aqui refere-se apenas a informações não modificadas.
(2). idempotente significa que múltiplas requisições para a mesma URL devem retornar o mesmo resultado.
No entanto, na prática, as duas regulamentações acima não são tão rigorosas. Exemplos de citação de artigos de outras pessoas: Por exemplo, a página inicial de um site de notícias é constantemente atualizada. Embora a segunda solicitação retorne um lote diferente de notícias, a operação ainda é considerada segura e idempotente porque sempre retorna as notícias atuais. Fundamentalmente, se o objetivo é que, ao abrir um link, um usuário possa ter confiança de que o recurso não foi alterado do ponto de vista dele.
2. De acordo com a especificação HTTP, POST representa uma requisição que pode modificar um recurso no servidor. Continuando a citar o exemplo acima: Notícias ainda Considere o site como exemplo, os leitores devem postar seus próprios comentários sobre as notícias, porque os recursos do site mudam após o comentário ser enviado ou os recursos modificados.
O acima discute aproximadamente alguns dos princípios de GET e POST na especificação HTTP. No entanto, muitas pessoas não seguem a especificação HTTP ao realmente fazê-lo, o que pode levar a várias razões para esse problema, como:
1. Muitas pessoas usam o GET para atualizar recursos porque precisam ir ao FORM para usar o POST, o que pode ser um pouco problemático.
2. A operação de adicionar, excluir, modificar e checar recursos pode ser realmente realizada via GET/POST, sem a necessidade de usar PUT e DELETE.
3. Outra é que os primeiros designers de frameworks Web MVC não tratavam conscientemente e projetavam URLs como recursos abstratos, então um problema sério é que o framework tradicional Web MVC basicamente suporta apenas dois métodos HTTP, GET e POST, mas não suporta métodos PUT e DELETE.
* Uma breve explicação do MVC: MVC existia originalmente no programa Desktop, M refere-se ao modelo de dados, V à interface do usuário e C ao controlador. O objetivo de usar MVC é separar o código de implementação de M e V, para que o mesmo programa possa usar representações diferentes.
Os 3 pontos acima normalmente descrevem o estilo antigo (sem a adesão estrita à especificação HTTP); com o desenvolvimento da arquitetura, agora existe o REST (Transferência de Estado Representacional), um novo estilo que suporta a especificação HTTP.
Depois de falar sobre o problema principal, vamos analisar a diferença entre GET e POST em relação ao fenômeno superficial:
1. Os dados da requisição GET serão anexados à URL (ou seja, os dados são colocados no cabeçalho do protocolo HTTP), e o ? Divida a URL e transmita os dados, e os parâmetros são conectados por &, por exemplo: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Se os dados forem letras ou números em inglês, envie como são; se for um espaço, converta para +; se for em chinês/outros caracteres, então criptografe diretamente a cadeia com BASE64 para obter uma amostra como: %E4%BD%A0%E5%A5%BD, onde XX em %XX é o ASCII representado pelo símbolo em hexadecimal.
O POST coloca os dados enviados no corpo do pacote HTTP.
2. "O máximo de dados submetidos pelo método GET pode ser apenas 1024 bytes, teoricamente não há limite para o POST, e uma grande quantidade de dados pode ser transferida, até 80KB no IIS4 e 100KB no IIS5??!
A frase acima foi redirecionada de outros artigos, na verdade, é errado e impreciso dizer isso:
(1). Primeiramente, "os dados enviados pelo método GET só podem ter no máximo 1024 bytes", porque o GET envia dados via URL, então a quantidade de dados que pode ser enviada pelo GET está diretamente relacionada ao comprimento da URL. Na verdade, não há limite máximo de parâmetros para URLs, e a especificação do protocolo HTTP não limita o comprimento das URLs. Esse limite é uma limitação imposta por um navegador e servidor específicos. O limite do IE para o comprimento de URL é de 2083 bytes (2K+35). Para outros navegadores como Netscape, Firefox, etc., não há limite teórico de comprimento, e seu limite depende do suporte do sistema operacional.
Note que isso limita o comprimento total da URL, não apenas o valor do seu parâmetro e o comprimento dos dados. [Veja Ref. 5]
(2). Teoricamente, o POST não possui limite de tamanho, e a especificação do protocolo HTTP não possui limite de tamanho, e é impreciso dizer que "há um limite de tamanho de 80K/100K para dados POST", e não há limite para dados POST, e é o poder de processamento do manipulador do servidor que desempenha um papel limitante.
Para programas ASP, o objeto Request possui um limite de comprimento de dados de 100K ao processar cada campo de formulário. Mas com o Request.BinaryRead não existe essa limitação.
Além disso, para o IIS 6.0, a Microsoft aumentou as restrições por razões de segurança. Também precisamos prestar atenção a:
1). O IIS 6.0 tem como padrão um máximo de 200 KB de dados ASP POST, e o limite é de 100 KB por campo de formulário.
2). O tamanho padrão dos arquivos de upload do IIS 6.0 é 4MB.
3). O IIS 6.0 tem como padrão um cabeçalho máximo de requisição de 16KB.
Essas limitações não estavam disponíveis antes do IIS 6.0. [Veja Ref. 5]
Então, os 80K e 100K acima podem ser apenas os valores padrão (nota: ainda não confirmei os parâmetros do IIS4 e IIS5), mas você definitivamente pode configurá-los você mesmo. Como os valores padrão desses parâmetros são diferentes em cada versão do IIS, consulte o documento de configuração relevante do IIS para mais detalhes.
3. No ASP, o servidor usa Request.QueryString para obter o parâmetro de requisição GET e Request.Form para obter o parâmetro de requisição POST. No JSP, use request.getParameter(\"XXXX\") para obtê-lo, embora também exista um método request.getQueryString() no jsp, mas é mais difícil de usar, por exemplo: envie um test.jsp?name=hyddd&password=hyddd, e use request.getQueryString() para obter :name= hyddd&password=hyddd。 No PHP, você pode usar $_GET e $_POST para obter dados do GET e POST, respectivamente, enquanto o $_REQUEST pode obter dados tanto de requisições GET quanto POST. Vale notar que existem perigos ocultos em usar request em JSP e $_REQUEST em PHP, que serão resumidos em um artigo na próxima vez.
4.POST é mais seguro que o GET. Nota: A segurança mencionada aqui não é o mesmo conceito da "segurança" mencionada no GET acima. Por exemplo, se você enviar dados pelo GET, seu nome de usuário e senha aparecerão em texto simples na URL, porque (1) a página de login pode estar armazenada em cache pelo navegador, (2) outras pessoas verão o histórico do navegador, para que outros possam obter sua conta e senha Ataque de falsificação.
Resumindo, Get é uma solicitação para solicitar dados do servidor, enquanto Post é uma solicitação para enviar dados ao servidor, no FORM, Método é padrão para "GET"; essencialmente, GET e POST são apenas mecanismos de envio diferentes, não um pega e envia!
|
Publicado em 06/12/2014 10:54:55
|
|
|
Publicado em 07/12/2014 17:24:18
