Respostas:
HTTP PUT:
PUT coloca um arquivo ou recurso em um URI específico e exatamente nesse URI. Se já houver um arquivo ou recurso nesse URI, o PUT substituirá esse arquivo ou recurso. Se não houver arquivo ou recurso, o PUT cria um. PUT é idempotente , mas paradoxalmente as respostas PUT não são armazenáveis em cache.
POST HTTP:
O POST envia dados para um URI específico e espera que o recurso nesse URI lide com a solicitação. O servidor da Web neste momento pode determinar o que fazer com os dados no contexto do recurso especificado. O método POST não é idempotente , no entanto, as respostas POST são armazenáveis em cache, desde que o servidor defina os cabeçalhos de controle de cache e expira apropriados.
O HTTP RFC oficial especifica POST para:
Localização HTTP 1.1 RFC para POST
Diferença entre POST e PUT:
A própria RFC explica a principal diferença:
A diferença fundamental entre as solicitações POST e PUT é refletida no significado diferente do Request-URI. O URI em uma solicitação POST identifica o recurso que manipulará a entidade fechada. Esse recurso pode ser um processo de aceitação de dados, um gateway para outro protocolo ou uma entidade separada que aceita anotações. Por outro lado, o URI em uma solicitação PUT identifica a entidade anexada à solicitação - o agente do usuário sabe qual URI se destina e o servidor NÃO DEVE tentar aplicar a solicitação a algum outro recurso. Se o servidor desejar que a solicitação seja aplicada a um URI diferente, DEVE enviar uma resposta 301 (Movida permanentemente); o agente do usuário PODE então tomar sua própria decisão sobre se deve ou não redirecionar a solicitação.
Além disso, e de forma um pouco mais concisa, a Seção 4.3.4 da RFC 7231 PUT afirma (grifo nosso),
4.3.4 COLOCAR
O método PUT solicita que o estado do recurso de destino seja
createdoureplacedcom o estado definido pela representação incluída na carga útil da mensagem de solicitação.
Usando o método correto, não relacionado à parte:
Um benefício do REST ROA x SOAP é que, ao usar o HTTP REST ROA, ele incentiva o uso adequado dos verbos / métodos HTTP. Assim, por exemplo, você usaria apenas PUT quando desejar criar um recurso naquele local exato. E você nunca usaria GET para criar ou modificar um recurso.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Então, uma implementação do PUT que se recusa a criar um recurso, se não presente, seria correta, certo? Se sim, isso acontece na prática? Ou implementações geralmente também criam no PUT?
Apenas semântica.
Um HTTP PUTdeve aceitar o corpo da solicitação e armazená-lo no recurso identificado pelo URI.
Um HTTP POSTé mais geral. É suposto iniciar uma ação no servidor. Essa ação pode ser armazenar o corpo da solicitação no recurso identificado pelo URI, ou um URI diferente ou uma ação diferente.
PUT é como um upload de arquivo. Uma colocação em um URI afeta exatamente esse URI. Um POST para um URI pode ter qualquer efeito.
Para dar exemplos de recursos no estilo REST:
"POST / books" com várias informações de livros pode criar um novo livro e responder com a nova URL que identifica esse livro: "/ books / 5".
"PUT / books / 5" teria que criar um novo livro com o ID 5 ou substituir o livro existente pelo ID 5.
No estilo sem recurso, o POST pode ser usado para praticamente qualquer coisa que tenha um efeito colateral. Uma outra diferença é que o PUT deve ser idempotente - vários PUTs dos mesmos dados para o mesmo URL devem ser bons, onde vários POSTs podem criar vários objetos ou qualquer que seja sua ação do POST.
PUT é um método para "carregar" coisas para um URI específico ou substituir o que já está nesse URI.
POST, por outro lado, é uma maneira de enviar dados RELACIONADOS a um determinado URI.
Consulte o HTTP RFC
Tanto quanto eu sei, PUT é usado principalmente para atualizar os registros.
POST - Para criar documento ou qualquer outro recurso
PUT - Para atualizar o documento criado ou qualquer outro recurso.
Mas para deixar claro que o PUT geralmente 'substitui' o registro existente, se ele estiver lá, e cria, se não estiver lá.
Outros já postaram respostas excelentes, eu só queria acrescentar que na maioria dos idiomas, estruturas e casos de uso você estará lidando com o POST com muito mais frequência do que o PUT. Até o ponto em que PUT, DELETE etc. são basicamente perguntas triviais.
Consulte: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Ultimamente, tenho ficado bastante irritado com um equívoco popular dos desenvolvedores da Web de que um POST é usado para criar um recurso e um PUT é usado para atualizar / alterar um.
Se você der uma olhada na página 55 da RFC 2616 (“Hypertext Transfer Protocol - HTTP / 1.1”), Seção 9.6 (“PUT”), você verá o que é realmente a PUT:
O método PUT solicita que a entidade fechada seja armazenada no URI de solicitação fornecido.
Há também um parágrafo útil para explicar a diferença entre POST e PUT:
A diferença fundamental entre as solicitações POST e PUT é refletida no significado diferente do Request-URI. O URI em uma solicitação POST identifica o recurso que manipulará a entidade fechada. Esse recurso pode ser um processo de aceitação de dados, um gateway para outro protocolo ou uma entidade separada que aceita anotações. Por outro lado, o URI em uma solicitação PUT identifica a entidade anexada à solicitação - o agente do usuário sabe qual URI se destina e o servidor NÃO DEVE tentar aplicar a solicitação a algum outro recurso.
Ele não menciona nada sobre a diferença entre atualizar / criar, porque não é disso que se trata. É sobre a diferença entre isso:
obj.set_attribute(value) # A POST request.
E isto:
obj.attribute = value # A PUT request.
Então, por favor, pare a propagação desse equívoco popular. Leia seus RFCs.
Um POST é considerado um método do tipo fábrica. Você inclui dados para criar o que deseja e o que quer que esteja do outro lado, sabe o que fazer com ele. Um PUT é usado para atualizar os dados existentes em um determinado URL ou para criar algo novo quando você sabe qual será o URI e ele ainda não existe (em oposição a um POST que criará algo e retornará um URL para se necessário).
O REST solicita que os desenvolvedores usem métodos HTTP explicitamente e de maneira consistente com a definição do protocolo. Esse princípio básico de design do REST estabelece um mapeamento individual entre operações de criação, leitura, atualização e exclusão (CRUD) e métodos HTTP. De acordo com este mapeamento:
• Para criar um recurso no servidor, use POST.
• Para recuperar um recurso, use GET.
• Para alterar o estado de um recurso ou atualizá-lo, use PUT.
• Para remover ou excluir um recurso, use DELETE.
Mais informações: Serviços da Web RESTful: Noções básicas da IBM
Deve ser bastante simples quando usar um ou outro, mas formulações complexas são uma fonte de confusão para muitos de nós.
Use PUTquando desejar modificar um recurso singular que já faz parte da coleção de recursos. PUTsubstitui o recurso na sua totalidade. Exemplo:PUT /resources/:resourceId
Nota lateral: use PATCHse você deseja atualizar uma parte do recurso.
POSTquando desejar adicionar um recurso filho a uma coleção de recursos. POST => /resourcesPUTpara operações UPDATE .POSTpara operações CREATE .GET / company / reports => Obter todos os relatórios
GET / company / reports / {id} => Obter as informações do relatório identificadas por "id"
POST / company / reports => Criar um novo relatório
PUT / company / reports / {id} => Atualizar o informações do relatório identificadas por "id"
PATCH / empresa / relatórios / {id} => Atualize uma parte das informações do relatório identificadas por "id"
DELETE / empresa / relatórios / {id} => Excluir relatório por "id"
A diferença entre POST e PUT é que PUT é idempotente, ou seja, chamar a mesma solicitação PUT várias vezes sempre produzirá o mesmo resultado (sem efeito colateral), enquanto, por outro lado, chamar uma solicitação POST repetidamente pode ter ( adicionais) efeitos colaterais da criação do mesmo recurso várias vezes.
GET : Solicitações usando GET apenas recuperam dados, ou seja, solicitam uma representação do recurso especificado
POST: Envia dados ao servidor para criar um recurso. O tipo do corpo da solicitação é indicado pelo cabeçalho Content-Type. Muitas vezes, causa uma alteração no estado ou efeitos colaterais no servidor
PUT : Cria um novo recurso ou substitui uma representação do recurso de destino pela carga útil da solicitação
PATCH : É usado para aplicar modificações parciais a um recurso
DELETE : Exclui o recurso especificado
TRACE : Executa um teste de loop de mensagem ao longo do caminho para o recurso de destino, fornecendo um mecanismo de depuração útil
OPTIONS : É usado para descrever as opções de comunicação do recurso de destino, o cliente pode especificar uma URL para o método OPTIONS ou um asterisco (*) para se referir a todo o servidor.
HEAD : Solicita uma resposta idêntica à de uma solicitação GET, mas sem o corpo da resposta
CONNECT : Estabelece um túnel para o servidor identificado pelo recurso de destino, pode ser usado para acessar sites que usam SSL (HTTPS)
Uso REST-ful
POST é usado para criar um novo recurso e, em seguida, retorna o recurso URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Essa chamada pode criar um novo livro e devolvê-lo URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT é usado para substituir um recurso, se esse recurso existir, basta atualizá-lo, mas se esse recurso não existir, crie-o,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
Com PUTnós sabemos o identificador de recurso, mas POSTretornará o novo identificador de recurso
Uso não REST-cheio
POST é usado para iniciar uma ação no lado do servidor, essa ação pode ou não criar um recurso, mas essa ação terá efeitos colaterais sempre que mudará algo no servidor
PUT é usado para colocar ou substituir conteúdo literal em um URL específico
Outra diferença nos estilos REST-ful e não REST-ful
POST é Operação Não Idempotente: Causará algumas alterações se executadas várias vezes com a mesma solicitação.
PUT é Operação Idempotente: Não terá efeitos colaterais se executado várias vezes com a mesma solicitação.
Vale ressaltar que POSTestá sujeito a alguns ataques comuns de falsificação de solicitação entre sites (CSRF) enquanto PUTnão estiver.
O CSRF abaixo nãoPUT é possível quando a vítima visita attackersite.com.
O efeito do ataque é que a vítima acidentalmente exclui um usuário só porque ele (a vítima) foi logado como adminem target.site.com, antes de visitar attackersite.com:
Solicitação normal (os cookies são enviados): ( PUTnão é um valor de atributo suportado)
Código em attackersite.com:
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
Solicitação XHR (os cookies são enviados): ( PUTacionaria uma solicitação de comprovação, cuja resposta impediria o navegador de solicitar a deleteUserpágina)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
Em palavras simples, você pode dizer:
1.HTTP Get: É usado para obter um ou mais itens
2.HTTP Post: É usado para criar um item
Put HTT: É usado para atualizar um item
Patch 4.HTTP: É usado para atualizar parcialmente um item
5.HTTP Delete: É usado para excluir um item
Na verdade, não há diferença além do título. Na verdade, há uma diferença básica entre GET e os outros. Com um método "GET" -Request, você envia os dados na linha de endereço de URL, que são separados primeiro por um ponto de interrogação e depois com um sinal de &.
Mas com um método de solicitação "POST", você não pode passar dados pela URL, mas precisa passar os dados como um objeto no chamado "corpo" da solicitação. No lado do servidor, você deve ler o corpo do conteúdo recebido para obter os dados enviados. Mas, por outro lado, não há possibilidade de enviar conteúdo no corpo, quando você envia uma solicitação "GET".
A alegação de que "GET" é apenas para obter dados e "POST" é para postar dados, está absolutamente errada. Ninguém pode impedir que você crie um novo conteúdo, exclua o conteúdo existente, edite o conteúdo existente ou faça o que for necessário no back-end, com base nos dados enviados pela solicitação "GET" ou pela solicitação "POST". E ninguém pode impedir que você codifique o back-end de uma maneira que, com uma solicitação "POST", o cliente solicite alguns dados.
Com uma solicitação, independentemente do método usado, você chama um URL e envia ou não envia alguns dados para especificar, quais informações você deseja passar ao servidor para lidar com sua solicitação e, em seguida, o cliente recebe uma resposta de o servidor. Os dados podem conter o que você deseja enviar, o back-end pode fazer o que quiser com os dados e a resposta pode conter qualquer informação que você queira colocar lá.
Existem apenas esses dois métodos básicos. GET e POST. Mas é a estrutura deles, que os torna diferentes e não o que você codifica no back-end. No back-end, você pode codificar o que quiser, com os dados recebidos. Porém, com a solicitação "POST", é necessário enviar / recuperar os dados no corpo e não na linha de endereço da URL, e com uma solicitação "GET", você deve enviar / recuperar dados na linha de endereço da URL e não em o corpo. Isso é tudo.
Todos os outros métodos, como "PUT", "DELETE" e assim por diante, têm a mesma estrutura que "POST".
O método POST é usado principalmente, se você deseja ocultar um pouco o conteúdo, porque, o que quer que você escreva na linha de endereço da URL, ele será salvo no cache e um método GET é o mesmo que escrever uma linha de endereço da URL com dados. Portanto, se você deseja enviar dados confidenciais, que nem sempre são necessariamente nome de usuário e senha, mas, por exemplo, alguns IDs ou hashes, que você não deseja que sejam mostrados na linha de endereço da URL, use o método POST .
Além disso, o comprimento da linha de endereço da URL é limitado a 1024 símbolos, enquanto o método "POST" não é restrito. Portanto, se você tiver uma quantidade maior de dados, poderá não conseguir enviá-los com uma solicitação GET, mas precisará usar a solicitação POST. Portanto, este também é outro ponto positivo da solicitação POST.
Mas lidar com a solicitação GET é muito mais fácil, quando você não tem texto complicado para enviar. Caso contrário, e este é outro ponto positivo do método POST, é que, com o método GET, você precisa codificar o texto por URL, para poder enviar alguns símbolos dentro do texto ou até mesmo espaços. Mas com um método POST, você não tem restrições e seu conteúdo não precisa ser alterado ou manipulado de forma alguma.
PUT e POST são métodos de repouso.
PUT - Se fizermos a mesma solicitação duas vezes usando PUT usando os mesmos parâmetros nas duas vezes, a segunda solicitação não terá efeito. É por isso que o PUT geralmente é usado para o cenário Update, chamando Update mais de uma vez com os mesmos parâmetros não faz nada além da chamada inicial, portanto, o PUT é idempotente.
O POST não é idempotente; por exemplo, o Create criará duas entradas separadas no destino, portanto, ele não é idempotente; portanto, CREATE é amplamente utilizado no POST.
Fazer a mesma chamada usando POST com os mesmos parâmetros todas as vezes fará com que duas coisas diferentes aconteçam, daí o motivo pelo qual o POST é comumente usado no cenário Criar