Quando você usa o POST e quando usa o GET?


343

Pelo que posso entender, há três categorias:

  1. Nunca use GETe usePOST
  2. Nunca use POSTe useGET
  3. Não importa qual você usa.

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


11
Na verdade, isso não é verdade. GET e POST são visíveis na mesma medida, se você verificar os cabeçalhos enviados pelo seu navegador, você verá uma lista de pares chave-valor que você postar
Velimir Tchatchevsky


11
Não há uma maneira padrão de codificar mais do que pares nome -> valor em cadeias de consulta, portanto, a menos que suas solicitações sejam muito básicas (ou seja, sem matrizes ou estruturas de dados aninhadas), você deve considerar apenas o POST, que fornece um campo de corpo que pode ser usado com os formatos de codificação (JSON, XML etc).
themihai

Respostas:


376

Use POSTpara ações destrutivas, como criação (sei da ironia), edição e exclusão, porque você não pode POSTexecutar uma ação na barra de endereços do seu navegador. Use GETquando for seguro para permitir que uma pessoa chame uma ação. Então, um URL como:

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

Deve levá-lo a uma página de confirmação, em vez de simplesmente excluir o item. É muito mais fácil evitar acidentes dessa maneira.

POSTtambém é mais seguro do que GET, porque você não está colando informações em um URL. Portanto, usar GETo methodformulário HTML para coletar uma senha ou outras informações confidenciais não é a melhor idéia.

Uma nota final: POSTpode transmitir uma quantidade maior de informações que GET. O 'POST' não possui restrições de tamanho para os dados transmitidos, enquanto o 'GET' é limitado a 2048 caracteres.


82
As respostas às solicitações GET podem ser alteradas. As respostas aos POSTs não devem.
Mkeller

31
Como as informações coladas no URL não as tornam mais seguras? (Aliás, sou um daqueles que acredita que uma falsa sensação de segurança é mais perigosa do que não ter segurança nenhuma).
ePharaoh

42
@ePharaoh: impede que as pessoas leiam senhas olhando por cima do ombro do usuário na barra de endereços.
Quentin

35
@ePharaoh: "Expor um pouco menos de dados a um observador casual" provavelmente seria uma formulação melhor do que "mais segura" - os URLs podem acabar em muitos lugares, como logs, referenciadores e caches. Está claro, certo, isso não aumenta a segurança - mas limita as piores práticas inseguras (Veja também: thedailywtf.com/Articles/The_Spider_of_Doom.aspx )
Piskvor deixou a construção de

24
@ David Dorward: Ou por ele é nome mais comum: ataque ombro
Idan K

206

Em resumo

  • Use GETpara safe andidempotentsolicitações
  • Use POSTpara neither safe nor idempotentsolicitações

Em detalhes Há um local apropriado para cada um. Mesmo se você não seguir os princípios RESTful , muito poderá ser obtido com a aprendizagem sobre o REST e como funciona uma abordagem orientada a recursos.

Um aplicativo RESTful irá use GETspara operações que são ambas safe and idempotent.

Uma safeoperação é uma operação not change the datasolicitada.

Uma idempotentoperação é aquela em que o resultado be the samenão importa quantas vezes você o solicite.

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

Um aplicativo RESTful será usado PUTspara operações que são not safe but idempotent.

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

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

A POSTseria 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 NOVA pergunta SO (embora em alguns modelos 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 lá :)

Discussão

Em termos práticos, os navegadores da web modernos geralmente oferecem suporte apenas a GET e POST (você pode executar todas essas operações por meio de chamadas javascript, mas em termos de inserção de dados em formulários e pressionamento de envio, 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 uso de GET para recuperar / visualizar informações e POST para criar / editar informações.

Você nunca deve usar GET para uma operação que altera os dados. Se um mecanismo de pesquisa rastreia um link para sua operação maligna ou os favoritos do cliente, isso pode significar grandes problemas.


se você criar o recurso APIREST para o login de sua escolha, isso é seguro e é idempotente.
Jhonny lopez #

11
Uma obtenção segura não é automaticamente idempotente. O conjunto de resultados pode ser diferente com a mesma consulta não destrutiva.
RichieHH

11
Do jeito que você escreveu, algo como "GET currenttime" estaria errado porque não é idempotente (no sentido de que consultas repetidas podem produzir resultados diferentes); de fato, qualquer coisa consultada pode mudar com o tempo. Portanto, deve-se expressar a idempotência em termos de efeitos colaterais da própria consulta . Como apenas perguntar pela hora atual não tem efeitos colaterais , este é - como seria de esperar - um candidato perfeito para GET e não para o POST.
Hagen von Eitzen

79

Use GET se você não se importa que o pedido seja repetido (ou seja, ele não muda de estado).

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


11
Como um formulário altera o estado do sistema, por que o método padrão da tag de formulário HTML é GET?
precisa saber é

3
@ user248959 Uma caixa de pesquisa altera o estado visível? O padrão foi definido há muito tempo, provavelmente quase por acidente. Eu não mergulhei na história para saber se o POST era uma opção no momento em que as formas eram uma opção.
Douglas Leeder

@ziiweb Mesmo que a maioria dos casos de uso de <form> seja POST, é melhor definir o dafault como um GET "inofensivo". Isso pode parecer absurdo do ponto de vista de segurança quando leva a dados expostos em arquivos de log etc., mas é à prova de falhas com relação aos dados do servidor (o serviço não deve modificar dados em um GET). Suponho, seria definir o foco diferente hoje (de preferência por queda de qualquer padrão e fazendo methodobrigatório)
Hagen von Eitzen

Suponha que eu tenha um nó de extremidade que aceite um arquivo como entrada, faça algum processamento no arquivo (exemplo - extraia dados com base em regex) e retorne dados JSON; então, posso usar a solicitação GET para fazer upload de um arquivo no servidor. Ou devo usar a solicitação POST?
variável

67

Versão curta

GET: geralmente usado para solicitações de pesquisa enviadas ou qualquer solicitação em que você queira que o usuário possa acessar a página exata novamente.

Vantagens do GET:

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

Desvantagens do GET:

POST: Usado para solicitações de segurança mais alta, 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 favorito.

Vantagens do POST:

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

Desvantagens do POST:

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

Versão Longa

Diretamente do Hypertext Transfer Protocol - HTTP / 1.1 :

9.3 GET

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 de origem 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-Modified-Since, If-Match, If-None-Match ou If-Range. Um método GET condicional solicita que a entidade seja transferida apenas nas circunstâncias descritas pelos campos de cabeçalho condicional. O método GET condicional visa reduzir o uso desnecessário da rede, permitindo que as entidades em cache sejam atualizadas sem exigir várias solicitações ou transferir 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 tem como objetivo 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 é armazenável 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 POST

O método POST é usado para solicitar que o servidor de origem aceite a entidade incluída na solicitação como um novo subordinado do recurso identificado pelo Request-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;

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

  • Fornecer um bloco de dados, como o resultado do envio de um formulário, para um processo de manipulação de dados;

  • Estendendo um banco de dados através de uma operação de acréscimo.

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

A ação executada 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 de a resposta incluir ou não uma entidade que descreve o resultado.


2
"A página que usou os dados da postagem não pode ser marcada": bem, isso é uma vantagem, não? Você provavelmente não deseja que sua consulta de alteração de dados seja marcada.
Piskvor saiu do prédio

Suponho que, se todas as vezes que a postagem foi usada, você a estava usando para fins de segurança, isso seria uma vantagem. Geralmente é, mas existe esse limite de comprimento em GET. Talvez alguém esteja passando apenas uma tonelada de dados não relacionados à segurança e gostaria que a página fosse marcada? Quem sabe ...
Cimplicity

Em relação à desvantagem do GET, a saber: "As variáveis ​​são passadas através da URL como pares nome-valor", o MVC eliminaria esse problema devido ao roteamento e aos URLs amigáveis ​​resultantes?
MrBoJangles

@MrBoJangles: O uso de URLs legais não impede o risco de 'pessoa olhando por cima do ombro'. Nota lateral: o MVC não requer roteamento com URLs legais e o roteamento com URLs legais não exige MVC; às vezes são usados ​​juntos, mas também podem ser usados ​​separadamente.
Icktoofay 28/07/12

No mundo .NET, para todos os fins práticos, boa capacidade de URL = MVC. Suponho que você possa fazer algumas reescritas do IIS ou outras estranhas baseadas em código, mas são ainda menos agradáveis. MVC, escusado será dizer, para a vitória.
MrBoJangles 30/07/2012

28

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

  • GET deve ser usado para ... obter ... algumas informações do servidor,
  • enquanto o POST deve ser usado para enviar algumas informações ao servidor.


Depois disso, algumas coisas que podem ser observadas:

  • Usando GET, seus usuários podem usar o botão "voltar" no navegador e podem marcar páginas
  • 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 o POST e geralmente depende da configuração do servidor.


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


Bem, se todos usavam bonitas-urls em um estilo GET: http://example.com/var1/value1/var2/value2/var3/value3poderíamos 'tecnicamente' não tem GET mais ...
Tyler Carter

5
@ Chacha102 Exceto que você ainda precisa obter esse recurso. Quase todas as páginas, imagens, scripts etc. são carregadas em navegadores da Web usando GET.
21710 Ryan

3
@ Chacha102 - Mesmo os www.mypage.com/contact/usos GET internamente para algo comoindex.php?url=/contact/
Thiago Belém

11
Ênfase no limite de tamanho de GET! Além disso, os parâmetros GET estão incluídos nos marcadores, enquanto o POST não. E, o usuário pode atualizar uma página solicitada pelo GET, mas não uma solicitada pelo POST (sem um aviso sobre o reenvio das informações).
Ricket 15/02/10

12

Além da diferença de restrições de comprimento em muitos navegadores da web, também há uma diferença semântica. Os GETs devem ser "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 ao reenvio. Os rastreadores da Web dos mecanismos de pesquisa podem criar GETs, mas nunca devem fazer POSTs.

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


+1. Essa é a principal diferença conceitual do rfc, do qual tudo o mais se segue. w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
Frank Farmer

8

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


8

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

Outro problema com os GETs - eles são indexados pelos mecanismos de pesquisa e outros sistemas automáticos. O Google já teve um produto que buscava previamente os links na página que você estava visualizando, para que eles fossem mais rápidos de carregar se você clicasse nesses links. Isso causou grandes estragos em sites com links como delete.php?id=1- as pessoas perderam seus sites inteiros.


11
Seu servidor da web provavelmente também tem limites para isso.
Billy ONeal

Bem, há um limite para o POST também.
Chelmertz

11
Ótimo ponto, @ Billyilly, eu adicionei isso no @ chelmertz Sim, mas posso mudar isso se eu quiser, e é muito maior. POSTADO arquivos de 1 gigabyte para instâncias do Apache, por exemplo.
precisa

Entendo os URLs sendo indexados pelos mecanismos de pesquisa. Não entendo o que isso tem a ver com GET. Quero dizer, um URL não é apenas um URL?
Mel

11
Os motores de busca @Honey seguem os links. Os links fazem solicitações GET. Os mecanismos de pesquisa não enviam formulários (se o fizessem, você veria o Google se inscrevendo para uma conta em seu site a cada poucos dias) e, portanto, não solicita POST.
ceejayoz

7

Use GET quando quiser que o URL reflita o estado da página. Isso é ú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". Também produz um URL mais limpo, pois não gera uma sequência de parâmetros após o caminho.


6

Como os GETs são puramente URLs, eles podem ser armazenados em cache pelo navegador da Web e podem ser mais bem utilizados para coisas como imagens geradas de forma consistente. (Defina um tempo de expiração)

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

GET pode oferecer um desempenho marginalmente melhor, alguns servidores da Web gravam o conteúdo do POST em um arquivo temporário antes de chamar o manipulador.

Outra coisa a considerar é o limite de tamanho. Os GETs são limitados pelo tamanho da URL, 1024 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.

Ainda menos que esse limite é um problema, como outro autor escreveu, qualquer coisa no URL pode acabar em outras partes da interface do usuário do navegador, como o histórico.


4

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


Não são apenas os navegadores que contam com o GET como seguro e idempotente: aranhas de mecanismos de pesquisa e navegadores de pré-busca (como o quickfox) também contam com isso.
Frank Farmer

@ Gili, finalmente alguém com resposta correta. Estou realmente surpreso com quantas pessoas erraram. afirmativo!
Lubos Hasko

4

Isso aborda o conceito de REST e como a web era destinada a ser usada. Existe um excelente podcast no rádio de Engenharia de Software que oferece uma conversa aprofundada sobre o uso de Get e Post.

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

O Post deve ser usado (pelo menos pela arquitetura REST na qual a Web se baseia) para enviar informações ao servidor / dizer ao servidor para executar uma ação. Exemplos como: atualizar esses dados, criar este registro.


"Existe um excelente podcast no rádio de Engenharia de Software que oferece uma conversa aprofundada sobre o uso de Get e Post". Cadê?
yeeen

Eu adicionei um link para ele.
kemiller2002

Aqui está o link : se-radio.net/2008/05/episode-98-stefan-tilkov-on-rest Eu também editei o link acima, embora não possua direitos de edição e precise ser revisado por pares, etc.
MrBoJangles

Suponha que eu tenha um nó de extremidade que aceite um arquivo como entrada, faça algum processamento no arquivo (exemplo - extraia dados com base em regex) e retorne dados JSON; então, posso usar a solicitação GET para fazer upload de um arquivo no servidor. Ou devo usar a solicitação POST?
variável

4

1.3 Lista de verificação rápida para escolher HTTP GETouPOST

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 .


3

Eu não vejo um problema usando 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 delete.php?id=5para excluir uma página - é muito arriscado. As pessoas descobriram isso quando o acelerador da web do Google começou a buscar URLs nas páginas - ele atingiu todos os links de exclusão e eliminou os dados das pessoas. O mesmo pode acontecer com as aranhas dos mecanismos de pesquisa.



3

De RFC 2616 :

9.3 GET
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 de origem do processo, a menos que esse texto seja a saída do processo.


9.5 POST
O método POST é usado para solicitar que o servidor de origem aceite a entidade incluída na solicitação como um novo subordinado do recurso identificado pelo Request-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;
  • Postar uma mensagem em um quadro de avisos, grupo de notícias, lista de discussão ou grupo de artigos semelhante;
  • Fornecer um bloco de dados, como o resultado do envio de um formulário, para um processo de manipulação de dados;
  • Estendendo um banco de dados através de uma operação de acréscimo.

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

A ação executada 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 de a resposta incluir ou não uma entidade que descreve o resultado.


2

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 upload de arquivos.

Porém, não vejo um problema ao usar GET, eu o uso para coisas simples, nas quais faz sentido manter as coisas no QueryString.

O uso de GET também permitirá a vinculação a uma página específica, onde o POST não funcionaria.


Por que não podemos usar GET para upload de arquivos?
variável

1

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


1

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

PEGUE

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

e

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

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

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

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

e

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

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

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


1

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


1

Em w3schools.com :

O que é HTTP?

O HTTP (Hypertext Transfer Protocol) foi projetado para permitir a comunicação entre clientes e servidores.

O 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; o servidor retornará uma resposta para o 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: GET e POST

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

GET - Solicita dados de um recurso especificado POST - Envia dados a serem processados ​​para um recurso especificado

Aqui, distinguimos as principais diferenças:

insira a descrição da imagem aqui


11
Seria muito melhor para pesquisadores e leitores inserir o conteúdo da imagem na resposta. Além disso, a primeira parte da resposta realmente não ajuda a responder à pergunta.
Dave Schweisguth 13/03/16

Copie e cole a partir daqui - você deve citar sua fonte corretamente e a licença da fonte deve permitir a reutilização, o que não acho que o w3schools permita. Além disso, você realmente acha que isso acrescenta algo que não foi abordado nas outras 25 respostas?
Benjamin W.

1

Versão simples do POST GET PUT DELETE

  • use GET - quando desejar obter qualquer recurso, como Lista de dados, com base em qualquer ID ou Nome
  • use POST - quando quiser enviar dados para o servidor. lembre-se de que o POST é uma operação pesada, porque para a atualização, devemos usar PUT em vez do POST internamente. O POST criará um novo recurso
  • use PUT - quando você

4
"use PUT - quando você" Onde está o resto da frase?
Pang

É ótimo que alguém tenha gostado tanto das duas primeiras balas desta resposta que aparentemente a aprovou sem a última bala haha: '-)
pooley1994 6/06

0

Bem, uma coisa importante é que tudo o que você enviar GETserá exposto via URL. Em segundo lugar, como Ceejayoz diz, há um limite de caracteres para um URL.


0

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

Editar: devo esclarecer - para padrões de programação comuns. Geralmente, responder a um POST com uma página HTML reta é 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 Voltar.


2
O POST não requer 2 operações http.
Billy ONeal

3
post-redirect-get requer 2 operações: en.wikipedia.org/wiki/Post/Redirect/Get
cherouvim

11
O POST pode exigir 2 viagens de ida e volta ao servidor - um padrão comum é o POST com um expect: 100-continuecabeçalho e, em seguida, somente envia dados quando o servidor responder com a 100 CONTINUE.
Frank Farmer

Bom artigo cherouvim, eu nunca soube que o padrão tinha um nome.
Plynx

@cherouvim: O redirecionamento de postagem recebe, mas a postagem simples não. Você pode simplesmente obter o redirecionamento e obter os mesmos resultados. Não tem nada a ver com o protocolo usado pelo seu formulário para envio.
Billy ONeal

0

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

Gostaria de acrescentar que se pode adicionar coisas a um banco de dados com ações get e executar com uma postagem. Quando um script recebe uma postagem ou um get, ele pode fazer o que o autor deseja. Acredito que a falta de entendimento deriva da redação escolhida pelo livro ou de como você o lê.

Um autor de script deve usar postagens para alterar o banco de dados e usar get only para recuperação de informações.

As linguagens de script forneceram muitos meios para acessar a solicitação. Por exemplo, o PHP permite o uso de $_REQUESTpara recuperar uma postagem ou um get. Deve-se evitar isso em favor dos mais específicos $_GETou $_POST.

Na programação da web, há muito mais espaço para interpretação. Há o que se deve e o que se pode fazer, mas qual é o melhor geralmente está em debate. Felizmente, neste caso, não há ambiguidade. Você deve usar mensagens de alterar dados, e você deve usar get para recuperar informações.


0

Gorgapor, mod_rewriteainda utiliza frequentemente GET. Ele apenas permite traduzir um URL mais amigável em um URL com uma GETstring de consulta.


-1

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

Os servidores devem ter cuidado com a dependência dos comprimentos de URI acima de 255 bytes, porque algumas implementações antigas de cliente ou proxy podem não suportar adequadamente esses comprimentos

Especificamente, você deve construir o HTTP certo para o que é usado. Os HTTP GET não devem ter efeitos colaterais e podem ser atualizados e armazenados com segurança por proxies HTTP, etc.

Os POST HTTP são usados ​​quando você deseja enviar dados contra um recurso de URL.

Um exemplo típico para usar HTTP GET está em uma pesquisa, ou seja, Search? Query = my + query Um exemplo típico para usar um HTTP POST é enviar feedback para um formulário online.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.