Pergunta

Ambos parecem estar enviando dados para o servidor dentro do corpo, de modo que os torna diferentes?

Foi útil?

Solução

HTTP PUT:

PUT coloca um arquivo ou recurso em um determinado URI, e exatamente nesse URI. Se já existe um arquivo ou recurso em que URI, substitui colocar esse arquivo ou recurso. Se não houver nenhum arquivo ou recurso lá, PUT cria um. PUT é idempotent , mas respostas paradoxalmente PUT não são armazenáveis .

HTTP 1.1 localização RFC para PUT

HTTP POST:

POST envia os dados para um determinado URI e espera que o recurso a esse URI para manipular a solicitação. O servidor web neste momento pode determinar o que fazer com os dados no contexto do recurso especificado. O método POST não é idempotent , no entanto, respostas POST < em> são em cache, desde que o servidor define o apropriado cache-Control e Expira cabeçalhos.

O HTTP RFC oficial especifica POST a ser:

  • Anotação dos recursos existentes;
  • enviar uma mensagem para uma lista de discussão, newsgroup, lista de discussão, ou grupo similar de artigos;
  • Fornecer um bloco de dados, como o resultado de apresentar uma forma, a um processo de tratamento de dados;
  • Estendendo um banco de dados através de uma operação de acréscimo.

HTTP 1.1 localização RFC para POST

Diferença entre POST e PUT:

O próprio RFC explica a diferença principal:

A diferença fundamental entre a solicitações POST e PUT se reflete na o significado diferente da Solicitar-URI. O URI em uma solicitação POST identifica o recurso que a vontade lidar com a entidade fechada. Este recurso pode ser uma data-aceitando processo, uma porta de entrada para algum outro protocolo, ou uma entidade separada que aceita anotações. Em contraste, o URI em uma solicitação PUT identifica o entidade fechada com o pedido - o agente do usuário sabe o URI é pretendido e a MUST servidor NÃO tentar aplicar a solicitação para alguns outro recurso. Se os desejos de servidor que o pedido de ser aplicado a uma diferente URI, ele deve enviar uma resposta 301 (movido permanentemente); o agente usuário pode então fazer a sua própria decisão sobre se deve ou não para redirecionar a solicitação.

Usando o método certo, sem relação de lado:

Uma das vantagens de RESTO ROA vs SOAP é que, ao usar HTTP RESTO ROA, incentiva a uso adequado dos verbos de HTTP / métodos. Assim, por exemplo, você só iria usar PUT quando você quer criar um recurso naquele local exato. E você nunca iria usar GET para criar ou modificar um recurso.

Outras dicas

Somente semântica.

Um HTTP PUT é suposto para aceitar o corpo do pedido, e depois armazená que no recurso identificado pelo URI.

Um HTTP POST é mais geral. Supõe-se para iniciar uma ação no servidor. Essa ação pode ser para armazenar o corpo da solicitação no recurso identificado pelo URI, ou poderia ser um URI diferente, ou poderia ser uma ação diferente.

PUT é como um upload de arquivo. A put a um URI afeta exatamente isso URI. Um POST a um URI poderia ter qualquer efeito.

Para dar exemplos de recursos REST estilo:

"POST / livros", com um monte de informações sobre o livro pode criar um novo livro, e responder com o novo URL identificar esse livro:. "/ Livros / 5"

"PUT / livros / 5" teria que criar um novo livro com o id de 5, ou substituir o livro existente com ID 5.

Em estilo não-recurso, POST pode ser usado para praticamente qualquer coisa que tenha um efeito colateral. Uma outra diferença é que PUT deve ser idempotentes -. Vários TUP dos mesmos dados para o mesmo URL deve estar bem, wheras várias postagens pode criar vários objetos ou o que seja sua ação POST faz

PUT se entende como um método para o material "upload" para um determinado URI, ou substituir o que já está em que URI.

POST, por outro lado, é uma forma de enviar os dados relacionados a um determinado URI.

Consulte o HTTP RFC

Tanto quanto eu sei, PUT é usado principalmente para atualizar os registros.

  1. POST - Para criar documento ou qualquer outro recurso

  2. PUT -. Para atualizar o documento criado ou qualquer outro recurso

Mas, para ser claro sobre o que PUT normalmente 'substitui' o registro existente se ele está lá e cria se não lá ..

Outros já postou excelentes respostas, eu só queria acrescentar que, com a maioria das linguagens, frameworks e casos de uso que você estará lidando com POST muito, muito mais frequentemente do que PUT. Até o ponto onde PUT, DELETE, etc. são basicamente trivia perguntas.

  1. get : recupera dados do servidor. Não deve ter nenhum outro efeito.
  2. POST : envia dados para o servidor para a criação de uma nova entidade. Muitas vezes usado quando o upload de um arquivo ou enviar um formulário web.
  3. PUT :. Semelhante ao POST, mas usado para substituir uma entidade existente
  4. PATCH :. Semelhante ao PUT, mas usado para atualizar apenas determinados campos dentro de uma entidade existente
  5. Excluir :. Remove os dados do servidor
  6. TRACE : Fornece uma maneira de testar o servidor recebe. Ele simplesmente retorna o que foi enviado.
  7. Opções : permite que um cliente para obter informações sobre os métodos de solicitação suportados por um serviço. O cabeçalho de resposta relevante é Permitir com métodos suportados. Também é usado em CORS como solicitação prévia para informar servidor sobre o método de pedido real e perguntar sobre os cabeçalhos personalizados.
  8. CABEÇA :. Retorna apenas os cabeçalhos de resposta
  9. Conectar : utilizado pelo navegador quando ele sabe que fala a um proxy eo URI final começa com https: //. A intenção do CONNECT é permitir end end-to-criptografada sessão TLS, por isso os dados são ilegíveis para um proxy.

A POST é considerado uma espécie de método de tipo de fábrica. Você incluir dados com ele para criar o que você quer e tudo o que é do outro lado sabe o que fazer com ele. A PUT é usado para atualizar os dados existentes em um determinado URL, ou para criar algo novo quando você sabe o que o URI vai ser e ainda não existir (em oposição a um POST que irá criar algo e retornar uma URL para -lo se necessário).

Por favor, veja: http://zacharyvoase.com/2009/07/03/http -post-put-diff /

Eu fui ficando muito irritado recentemente por um equívoco popular por desenvolvedores web que um POST é usado para criar um recurso e um PUT é usado para atualização / mudança de um.

Se você der uma olhada na página 55 do RFC 2616 ( “Hypertext Transfer Protocol - HTTP / 1.1”), Seção 9.6 ( ‘PUT’), você verá o que PUT é realmente para:

Os pedidos método PUT que a entidade fechada ser armazenados sob o fornecido Request-URI.

Há também um parágrafo útil para explicar a diferença entre POST e PUT:

A diferença fundamental entre o POST e solicitações PUT se reflete na diferente significado da Request-URI. O URI em uma solicitação POST identifica o recurso que irá lidar com a entidade fechada. Esse recurso pode ser um processo de aceitação de dados, uma porta de entrada para algum outro protocolo, ou uma entidade separada que aceita anotações. Em contraste, a URI em uma solicitação PUT identifica a entidade fechada com o pedido -. O usuário agente sabe o URI se destina e o servidor não deve tentar aplicar a solicitação para algum outro recurso

Ele não menciona nada sobre a diferença entre a atualização / criação, porque não é isso que se trata. É sobre a diferença entre este:

obj.set_attribute(value) # A POST request.

E esta:

obj.attribute = value # A PUT request.

Então, por favor, parar a propagação deste equívoco popular. Leia seus RFCs.

RESTO pede aos desenvolvedores métodos usam HTTP explícita e de uma forma que é consistente com a definição de protocolo. Este princípio básico Design Resto estabelece um um-para-um mapeamento entre criar, ler, atualizar e excluir (CRUD) e HTTP métodos. De acordo com isso mapeamento:

• Para criar um recurso no servidor, use POST.

• Para recuperar um recurso, o uso GET.

• Para alterar o estado de um recurso ou para atualizá-lo, use PUT.

• Para remover ou excluir um recurso, use DELETE.

Mais informações: RESTful Web services: Os princípios básicos da IBM

A diferença entre POST e PUT é que PUT é idempotente, ou seja, chamando o mesmo pedido PUT várias vezes sempre produzem o mesmo resultado (isto é nenhum efeito colateral), enquanto, por outro lado, chamando um pedido POST repetidamente pode ter efeitos colaterais (adicionais) de criar o mesmo recurso várias vezes.

GET: Pedidos usando GET recuperar somente dados, que é ele solicita uma representação do recurso especificado

POST: Ele envia dados para o servidor para criar um recurso. O tipo do corpo do pedido é indicada pelo cabeçalho Content-Type. Que muitas vezes provoca uma mudança em efeitos estaduais ou secundários no servidor

PUT: Cria um novo recurso ou substitui uma representação do recurso de destino com o pedido carga útil

PATCH: Ele é usado para aplicar modificações parciais a um recurso

DELETE: Apaga o recurso especificado

TRACE: Ele executa um teste de mensagem em circuito fechado ao longo do caminho para o recurso alvo, fornecendo um mecanismo de depuração útil

OPTIONS:. Ele é usado para descrever as opções de comunicação para o recurso de destino, o cliente pode especificar um URL para o método de opções, ou um asterisco (*) para se referir a todo o servidor

HEAD: Ele pede uma resposta idêntica à de um pedido 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 o uso de SSL (HTTPS)

Seria pena mencionar que POST está sujeita a algum comum CSRF ataques enquanto PUT não é.

O CSRF abaixo são não é possível com PUT quando as visitas vítima attackersite.com:

pedido Normal (cookies são enviados): (PUT não é um valor de atributo suportado)

<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>

pedido XHR (cookies são enviados): (PUT iria desencadear um pedido de pré-voo)

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

Simplesmente

POST é usado para criar um recurso e o devolve a URI recurso EX

REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}

Esta chamada deve criar um novo livro e retorna esse livro URI

Response ..../books/5

PUT é utilizado para substituir um recurso, se esse recurso é existir então simplesmente atualizá-lo, mas não se esse recurso não existe, então criá-lo,

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

usando PUT iremos fornecer o identificador de recursos, mas POST retornará o novo recurso identificador

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