Pergunta

Pelo que pude perceber, existem três categorias:

  1. Nunca use GET E use POST
  2. Nunca use POST E use GET
  3. Não importa qual você usa.

Estou correto ao assumir esses três casos?Em caso afirmativo, quais são alguns exemplos de cada caso?

Foi útil?

Solução

Usar POST para ações destrutivas como criação (estou ciente da ironia), edição e exclusão, porque você não pode acertar um POST ação na barra de endereço do seu navegador.Usar GET quando é seguro permitir que uma pessoa execute uma ação.Portanto, um URL como:

http://myblog.org/admin/posts/delete/357

Deve levar você a uma página de confirmação, em vez de simplesmente excluir o item.É muito mais fácil evitar acidentes desta forma.

POST também é mais seguro do que GET, porque você não está inserindo informações em um URL.E assim usando GET Enquanto o method pois um formulário HTML que coleta uma senha ou outras informações confidenciais não é a melhor ideia.

Uma nota final: POST pode transmitir uma quantidade maior de informações do que GET.'POST' não tem restrições de tamanho para dados transmitidos, enquanto 'GET' é limitado a 2.048 caracteres.

Outras dicas

Em resumo

  • Usar GET para safe andidempotent solicitações de
  • Usar POST para neither safe nor idempotent solicitações de

Em detalhesExiste um lugar adequado para cada um.Mesmo se você não seguir Repousante princípios, muito pode ser ganho aprendendo sobre REST e como funciona uma abordagem orientada a recursos.

Uma aplicação RESTful irá use GETs para operações que sejam ao mesmo tempo safe and idempotent.

A safe operação é uma operação que faz not change the data Requeridos.

Um idempotent operação é aquela em que o resultado será be the same não importa quantas vezes você solicite.

É lógico que, como os GETs são usados ​​para seguro operações, elas também são automaticamente idempotente.Normalmente, um GET é usado para recuperar um recurso (uma pergunta e suas respostas associadas no estouro de pilha, por exemplo) ou uma coleção de recursos.

Um aplicativo RESTful usará PUTs para operações que sejam not safe but idempotent.

Eu sei que a pergunta era sobre GET e POST, mas voltarei ao POST em um segundo.

Normalmente, um PUT é usado para editar um recurso (editar uma pergunta ou uma resposta no estouro de pilha, por exemplo).

A POST seria usado para qualquer operação que seja neither safe or idempotent.

Normalmente, um POST seria usado para criar um novo recurso, por exemplo, criando uma pergunta NEW SO (embora em alguns designs um PUT também fosse usado para isso).

Se você executar o POST duas vezes, acabará criando DUAS novas perguntas.

Há também uma operação DELETE, mas acho que posso deixar isso aí :)

Discussão

Em termos práticos, os navegadores modernos normalmente suportam apenas GET e POST de forma confiável (você pode executar todas essas operações por meio de chamadas javascript, mas em termos de inserir dados em formulários e pressionar enviar, geralmente você tem as duas opções).Em um aplicativo RESTful, o POST geralmente será substituído para fornecer também as chamadas PUT e DELETE.

Mas, mesmo que você não esteja seguindo os princípios RESTful, pode ser útil pensar em termos de usar GET para recuperar/visualizar informações e POST para criar/editar informações.

Você nunca deve usar GET para uma operação que altere dados.Se um mecanismo de pesquisa rastrear um link para sua operação maligna ou os favoritos do cliente, isso poderá significar um grande problema.

Use GET se você não se importa que a solicitação seja repetida (isto é, não muda de estado).

Use POST se a operação alterar o estado do sistema.

Versão curta

PEGAR:Geralmente usado para solicitações de pesquisa enviadas ou qualquer solicitação em que você deseja que o usuário consiga acessar a página exata novamente.

Vantagens do GET:

  • URLs podem ser marcados com segurança.
  • As páginas podem ser recarregadas com segurança.

Desvantagens do GET:

PUBLICAR:Usado para solicitações de maior segurança onde os dados podem ser usados ​​para alterar um banco de dados ou uma página que você não deseja que alguém marque como favorita.

Vantagens do POST:

  • Os pares nome-valor não são exibidos no URL.(Segurança += 1)
  • Um número ilimitado de pares nome-valor pode ser passado via POST. Referência.

Desvantagens do POST:

  • A página que usou dados POST não pode ser marcada.(Se você desejar.)

Versão mais longa

Diretamente do Protocolo de transferência de hipertexto - HTTP/1.1:

9.3 OBTER

O método GET significa recuperar qualquer informação (na forma de uma entidade) identificada pelo Request-URI.Se o Request-URI se referir a um processo de produção de dados, são os dados produzidos que devem ser retornados como a entidade na resposta e não o texto fonte do processo, a menos que esse texto seja a saída do processo.

A semântica do método GET muda para um "GET condicional" se a mensagem de solicitação incluir um campo de cabeçalho If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ou If-Range.Um método GET condicional solicita que a entidade seja transferida apenas sob as circunstâncias descritas pelo(s) campo(s) de cabeçalho condicional.O método GET condicional destina-se a reduzir o uso desnecessário da rede, permitindo que entidades em cache sejam atualizadas sem a necessidade de múltiplas solicitações ou transferência de dados já mantidos pelo cliente.

A semântica do método GET muda para um "GET parcial" se a mensagem de solicitação incluir um campo de cabeçalho Range.Um GET parcial solicita que apenas parte da entidade seja transferida, conforme descrito na seção 14.35.O método GET parcial destina-se a reduzir o uso desnecessário da rede, permitindo que entidades parcialmente recuperadas sejam concluídas sem transferir dados já mantidos pelo cliente.

A resposta a uma solicitação GET pode ser armazenada em cache se e somente se atender aos requisitos de cache HTTP descritos na seção 13.

Consulte a seção 15.1.3 para considerações de segurança quando usado para formulários.

9.5 POSTAGEM

O método de postagem é usado para solicitar que o servidor de origem aceite a entidade anexada na solicitação como um novo subordinado do recurso identificado pela solicitação-URI na linha de solicitação.O POST foi projetado para permitir um método uniforme para cobrir as seguintes funções:

  • Anotação de recursos existentes;

  • Publicar uma mensagem para um quadro de avisos, grupo de notícias, lista de discussão ou grupo semelhante de artigos;

  • Fornecer um bloco de dados, como resultado do envio de um formulário, a um processo de manuseio de dados;

  • Estendendo um banco de dados por meio de uma operação de acréscimo.

A função real executada pelo método de postagem é determinada pelo servidor e geralmente depende da solicitação-URI.A entidade postada está subordinada a esse URI da mesma maneira que um arquivo está subordinado a um diretório que o contém, um artigo de notícias é subordinado a um grupo de notícias no qual é publicado ou um registro é subordinado a um banco de dados.

A ação realizada pelo método POST pode não resultar em um recurso que pode ser identificado por um URI.Nesse caso, 200 (OK) ou 204 (sem conteúdo) é o status de resposta apropriado, dependendo se a resposta inclui ou não uma entidade que descreva o resultado.

A primeira coisa importante é o significado de GET versus POST:

  • GET deve ser usado para ...pegar...alguma informação de o servidor,
  • enquanto POST deve ser usado para enviar algumas informações para o servidor.


Depois disso, algumas coisas que podem ser observadas:

  • Usando GET, seus usuários podem usar o botão "voltar" em seus navegadores e marcar páginas como favoritos
  • Há um limite no tamanho dos parâmetros que você pode passar como GET (2 KB para algumas versões do Internet Explorer, se não me engano) ;o limite é muito maior para POST e geralmente depende da configuração do servidor.


De qualquer forma, não acho que poderíamos “viver” sem GET :pense em quantos URLs você está usando com parâmetros na string de consulta todos os dias - sem GET, todos eles não funcionariam ;-)

Além da diferença nas restrições de comprimento em muitos navegadores da web, há também uma diferença semântica.Supõe-se que os GETs sejam "seguros", pois são operações somente leitura que não alteram o estado do servidor.Os POSTs normalmente mudam de estado e emitem avisos sobre o reenvio.Os rastreadores da web dos mecanismos de pesquisa podem fazer GETs, mas nunca devem fazer POSTs.

Use GET se quiser ler dados sem alterar o estado e use POST se quiser atualizar o estado no servidor.

Minha regra geral é usar Get quando você estiver fazendo solicitações ao servidor que não irão alterar o estado.As postagens são reservadas para solicitações ao servidor que alteram o estado.

Uma diferença prática é que navegadores e servidores web têm um limite no número de caracteres que podem existir em uma URL.É diferente de aplicativo para aplicativo, mas certamente é possível acertar se você tiver textareaestá em seus formulários.

Outra pegadinha com GETs – eles são indexados por mecanismos de busca e outros sistemas automáticos.O Google já teve um produto que pré-buscava links na página que você estava visualizando, para que eles carregassem mais rápido se você clicasse nesses links.Isso causou principal estragos em sites que tinham links como delete.php?id=1 - as pessoas perderam seus sites inteiros.

Use GET quando quiser que o URL reflita o estado da página.Isto é útil para visualizar páginas geradas dinamicamente, como as vistas aqui.Um POST deve ser usado em um formulário para enviar dados, como quando clico no botão "Postar sua resposta".Ele também produz uma URL mais limpa, pois não gera uma sequência de parâmetros após o caminho.

Como os GETs são puramente URLs, eles podem ser armazenados em cache pelo navegador da Web e podem ser melhor usados ​​para coisas como imagens geradas de forma consistente.(Definir um prazo de validade)

Um exemplo da página gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET pode produzir um desempenho ligeiramente melhor, alguns servidores web gravam o conteúdo do POST em um arquivo temporário antes de invocar o manipulador.

Outra coisa a considerar é o limite de tamanho.GETs são limitados pelo tamanho da URL, 1.024 bytes pelo padrão, embora os navegadores possam suportar mais.

A transferência de mais dados do que isso deve usar um POST para obter melhor compatibilidade do navegador.

Mesmo menos que esse limite é um problema, como escreveu outro postador, qualquer coisa na URL pode acabar em outras partes da interface do navegador, como o histórico.

Não há nada que você não possa fazer por si só.A questão é que você não está suposto para modificar o estado do servidor em um HTTP GET.Os proxies HTTP assumem que, como HTTP GET não modifica o estado, não faz diferença se um usuário invoca HTTP GET uma vez ou 1000 vezes.Usando essas informações, eles presumem que é seguro retornar uma versão em cache do primeiro HTTP GET.Se você quebrar a especificação HTTP, você corre o risco de quebrar o cliente HTTP e os proxies em estado selvagem.Não faça isso :)

Isso aborda o conceito de REST e como a web foi planejada para ser usada.Há um excelente podcast na rádio Engenharia de Software que dá uma palestra aprofundada sobre o uso de Get e Post.

Get é usado para extrair dados do servidor, onde uma ação de atualização não deveria ser necessária.A ideia é que você possa usar a mesma solicitação GET repetidamente e ter as mesmas informações retornadas.A URL contém as informações get na string de consulta, porque foi criada para poder ser facilmente enviada para outros sistemas e as pessoas gostam de um endereço de onde encontrar algo.

Post deve ser usado (pelo menos pela arquitetura REST na qual a web é baseada) para enviar informações ao servidor/dizer ao servidor para executar uma ação.Exemplos como:Atualize esses dados, crie este registro.

1.3 Lista de verificação rápida para escolher HTTP GET ou POST

Use GET se:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Use POST se:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Fonte.

não vejo problema em usar get, porém, eu o uso para coisas simples onde faz sentido manter as coisas na string de consulta.

Usá-lo para atualizar o estado - como um GET de delete.php?id=5 excluir uma página é muito arriscado.As pessoas descobriram isso quando o acelerador da web do Google começou a pré-buscar URLs nas páginas - ele acertou todos os links de 'exclusão' e apagou os dados das pessoas.A mesma coisa pode acontecer com os spiders dos mecanismos de pesquisa.

POST pode mover grandes dados, enquanto GET não.

Mas geralmente não se trata de uma falha do GET, mas sim de uma convenção se você deseja que seu site/webapp se comporte bem.

Dê uma olhada em http://www.w3.org/2001/tag/doc/whenToUseGet.html

De RFC 2616:

9.3 PEGAR
O método get significa recuperar qualquer informação (na forma de uma entidade) é identificada pelo solicitação-URI.Se a solicitação-URI se referir a um processo de produção de dados, são os dados produzidos que devem ser retornados como entidade na resposta e não no texto de origem do processo, a menos que esse texto seja a saída do processo.


9.5 PUBLICAR
O método de postagem é usado para solicitar que o servidor de origem aceite a entidade anexada na solicitação como um novo subordinado do recurso identificado pela solicitação-URI na linha de solicitação.O POST foi projetado para permitir um método uniforme para cobrir as seguintes funções:

  • Anotação de recursos existentes;
  • Publicar uma mensagem para um quadro de avisos, grupo de notícias, lista de discussão ou grupo semelhante de artigos;
  • Fornecer um bloco de dados, como resultado do envio de um formulário, a um processo de manuseio de dados;
  • Estendendo um banco de dados por meio de uma operação de acréscimo.

A função real executada pelo método de postagem é determinada pelo servidor e geralmente depende da solicitação-URI.A entidade postada está subordinada a esse URI da mesma maneira que um arquivo está subordinado a um diretório que o contém, um artigo de notícias é subordinado a um grupo de notícias no qual é publicado ou um registro é subordinado a um banco de dados.

A ação realizada pelo método POST pode não resultar em um recurso que pode ser identificado por um URI.Nesse caso, 200 (OK) ou 204 (sem conteúdo) é o status de resposta apropriado, dependendo se a resposta inclui ou não uma entidade que descreva o resultado.

Eu uso POST quando não quero que as pessoas vejam o QueryString ou quando o QueryString fica grande.Além disso, o POST é necessário para uploads de arquivos.

Não vejo problema em usar GET, eu o uso para coisas simples onde faz sentido manter as coisas no QueryString.

Usar GET também permitirá vincular a uma página específica onde o POST não funcionaria.

Versão simples de POST GET PUT DELETE

  • use GET - quando quiser obter qualquer recurso como lista de dados com base em qualquer ID ou nome
  • use POST - quando quiser enviar dados ao servidor.Lembre -se de que o post é uma operação de peso pesado, porque para a atualização que devemos usar em vez de postar postagem internamente criará um novo recurso
  • use PUT - quando você

A intenção original era que GET fosse usado para recuperar dados e POST fosse qualquer coisa.A regra geral que uso é que, se estou enviando algo de volta ao servidor, uso POST.Se estou apenas chamando um URL para recuperar dados, uso GET.

Leia o artigo sobre HTTP na Wikipedia.Ele explicará o que é o protocolo e o que ele faz:

PEGAR

Solicita uma representação do recurso especificado.Observe que GET não deve ser usado para operações que causem efeitos colaterais, como usá-lo para realizar ações em aplicativos da web.Uma razão para isso é que GET pode ser usado arbitrariamente por robôs ou rastreadores, que não precisam considerar os efeitos colaterais que uma solicitação deve causar.

e

PUBLICAREnvia dados a serem processados ​​(por exemplo, de um formulário HTML) para o recurso identificado.Os dados estão incluídos no corpo da solicitação.Isso pode resultar na criação de um novo recurso ou na atualização de recursos existentes ou em ambos.

O W3C possui um documento chamado URIs, endereçamento e uso de HTTP GET e POST isso explica quando usar o quê.Citando

1.3 Lista de verificação rápida para escolher HTTP GET ou POST

  • Use GET se:
    • A interação é mais como uma pergunta (ou seja, é uma operação segura, como uma consulta, operação de leitura ou pesquisa).

e

  • Use POST se:
    • A interação é mais como uma ordem, ou
    • A interação altera o estado do recurso de uma maneira que o usuário perceberia (por exemplo, uma assinatura de um serviço) ou o usuário seria responsabilizado pelos resultados da interação.

No entanto, antes da decisão final de usar HTTP GET ou POST, considere também considerações sobre dados confidenciais e considerações práticas.

Um exemplo prático seria sempre que você envia um formulário HTML.Você especifica publicar ou pegar para a ação do formulário.O PHP preencherá $_GET e $_POST de acordo.

Em PHP, POST o limite de dados geralmente é definido pelo seu php.ini. GET é limitado pelas configurações do servidor/navegador, acredito - geralmente em torno 255 bytes.

De w3schools. com:

O que é HTTP?

O Protocolo de Transferência de Hipertexto (HTTP) foi projetado para permitir comunicações entre clientes e servidores.

HTTP funciona como um protocolo de solicitação-resposta entre um cliente e um servidor.

Um navegador da Web pode ser o cliente e um aplicativo em um computador que hospeda um site pode ser o servidor.

Exemplo:Um cliente (navegador) envia uma solicitação HTTP ao servidor;então o servidor retorna uma resposta ao cliente.A resposta contém informações de status sobre a solicitação e também pode conter o conteúdo solicitado.

Dois métodos de solicitação HTTP:OBTER e POSTAR

Dois métodos comumente usados ​​para uma resposta de solicitação entre um cliente e servidor são:OBTER e POSTAR.

Get - solicita dados de um post de recursos especificado - envia dados a serem processados ​​para um recurso especificado

Aqui distinguimos as principais diferenças:

enter image description here

Bem, uma coisa importante é qualquer coisa que você envie GET será exposto por meio do URL.Em segundo lugar, como diz Ceejayoz, há um limite de caracteres para um URL.

Outra diferença é que o POST geralmente requer duas operações HTTP, enquanto o GET requer apenas uma.

Editar:Devo esclarecer – para padrões de programação comuns.Geralmente, respondendo a uma postagem com uma página da web html direta é um design questionável por vários motivos, um dos quais é o irritante "Você deve reenviar este formulário, deseja fazê -lo?" ao pressionar o botão traseiro.

Conforme respondido por outros, há um limite no tamanho do URL com get e os arquivos podem ser enviados apenas com postagem.

Eu gostaria de adicionar esse pode adicione coisas a um banco de dados com um get e execute ações com uma postagem.Quando um script recebe uma postagem ou um get, ele pode fazer o que o autor desejar.Acredito que a falta de compreensão vem do texto que o livro escolheu ou de como você o lê.

Um autor de roteiro deve use posts para alterar o banco de dados e use get apenas para recuperação de informações.

As linguagens de script fornecem muitos meios de acessar a solicitação.Por exemplo, PHP permite o uso de $_REQUEST para recuperar uma postagem ou um get.Deve-se evitar isso em favor de uma abordagem mais específica $_GET ou $_POST.

Na programação web, há muito mais espaço para interpretação.Há o que deve e qual pode fazer, mas qual é o melhor é muitas vezes motivo de debate.Felizmente, neste caso, não há ambigüidade.Você deve use postagens para alterar dados e você deve use get para recuperar informações.

Gorgapor, mod_rewrite ainda utiliza frequentemente GET.Apenas permite traduzir uma URL mais amigável em uma URL com um GET cadeia de consulta.

Os dados HTTP Post não têm um limite especificado na quantidade de dados, enquanto navegadores diferentes têm limites diferentes para GETs.A RFC 2068 afirma:

Os servidores devem ser cautelosos sobre dependendo dos comprimentos dos URI acima de 255 bytes, porque algumas implementações de cliente ou proxy mais velhas podem não suportar adequadamente esses comprimentos

Especificamente, você deve usar as construções HTTP corretas para a finalidade em que são usadas.HTTP GETs não devem ter efeitos colaterais e podem ser atualizados e armazenados com segurança por Proxies HTTP, etc.

HTTP POSTs são usados ​​quando você deseja enviar dados para um recurso de URL.

Um exemplo típico de uso de HTTP GET está em uma pesquisa, ou seja,Pesquisar? Query = My+Consulta Um exemplo típico para o uso de uma postagem HTTP está enviando feedback para um formulário on -line.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top