Qual é a diferença entre um POST e um PUT HTTP REQUEST?

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

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, PUT replaceá esse arquivo ou recurso. Se não houver arquivo ou recurso, o PUT criará um. PUT é idempotente , mas paradoxalmente as respostas PUT não são armazenáveis ​​em cache.

Local de HTTP 1.1 RFC para PUT

HTTP POST:

O POST envia dados para um URI específico e espera que o recurso nesse URI manipule a solicitação. O servidor da Web neste ponto 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 podem ser armazenadas em cache, desde que o servidor configure os headers Cache-Control e Expires apropriados.

O RFC HTTP oficial especifica que o POST seja:

  • Anotação de resources existentes;
  • Postar uma mensagem em um quadro de avisos, newsgroup, lista de discussão ou grupo similar de artigos;
  • Fornecer um bloco de dados, como o resultado do envio de um formulário, para um processo de manipulação de dados;
  • Estendendo um database por meio de uma operação de acréscimo.

Local de HTTP 1.1 RFC para POST

Diferença entre POST e PUT:

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

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 incluída. Esse recurso pode ser um processo de aceitação de dados, um gateway para algum outro protocolo ou uma entidade separada que aceita annotations. Em contraste, o URI em uma solicitação PUT identifica a entidade anexada à solicitação – o agente do usuário sabe o que é o URI e o servidor NÃO DEVE tentar aplicar a solicitação a algum outro recurso. Se o servidor desejar que o pedido seja aplicado a um URI diferente, ele DEVE enviar uma resposta 301 (Moved Permanently); o agente do usuário pode, então, tomar sua própria decisão sobre redirect ou não o pedido.

Usando o método certo, não relacionado:

Um benefício do REST ROA versus SOAP é que, ao usar HTTP REST ROA, ele encoraja o uso adequado dos verbos / methods HTTP. Por exemplo, você só usaria PUT quando quiser criar um recurso nesse local exato. E você nunca usaria GET para criar ou modificar um recurso.

Apenas semântica.

Um HTTP PUT deve aceitar o corpo da solicitação e, em seguida, 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 pode ser um URI diferente ou pode ser uma ação diferente.

PUT é como um upload de arquivo. Um put para um URI afeta exatamente esse URI. Um POST para um URI pode ter algum efeito.

Para dar exemplos de resources no estilo REST:

“POST / books” com várias informações de livros pode criar um novo livro e responder com o novo URL que identifica esse livro: “/ books / 5”.

“PUT / books / 5” teria que criar um novo livro com o id de 5 ou replace o livro existente por ID 5.

No estilo sem resources, o POST pode ser usado para praticamente qualquer coisa que tenha um efeito colateral. Uma outra diferença é que PUT deve ser idempotente – vários PUTs dos mesmos dados para o mesmo URL devem ser bons, pois vários POSTs podem criar vários objects ou qualquer que seja sua ação POST.

1) GET: – Usado quando o cliente está solicitando um recurso no servidor da Web.

2) HEAD: – Usado quando o cliente está solicitando algumas informações sobre um recurso, mas não solicitando o recurso em si.

3) POST: – Usado quando o cliente está enviando informações ou dados para o servidor – por exemplo, preenchendo um formulário on-line (ou seja, envia uma grande quantidade de dados complexos para o servidor da Web).

4) PUT: – Usado quando o cliente está enviando um documento de substituição ou carregando um novo documento para o servidor Web sob o URL de solicitação.

5) DELETE: – Usado quando o cliente está tentando excluir um documento do servidor da Web, identificado pelo URL de solicitação.

6) TRACE: – Usado quando o cliente está solicitando os proxies disponíveis ou servidores intermediários alterando a solicitação para se anunciar.

7) OPÇÕES: – Usado quando o cliente deseja determinar outros methods disponíveis para recuperar ou processar um documento no servidor da Web.

8) CONNECT: – Usado quando o cliente deseja estabelecer uma conexão transparente com um host remoto, geralmente para facilitar a comunicação criptografada por SSL (HTTPS) por meio de um proxy HTTP.

PUT é um método para “fazer upload” de um determinado URI, ou sobrescrever o que já está nesse URI.

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

  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 isso, normalmente PUT ‘Substitui’ o registro existente se ele está lá e cria se ele não está lá ..

De acordo com a RFC , a diferença entre PUT e POST está no URI de solicitação. O URI identificado pelo POST define a entidade que manipulará a solicitação POST. O URI na solicitação PUT inclui a entidade na solicitação. Portanto, POST /v1/coffees/orders significa criar um novo recurso e retornar um identificador para descrever o recurso. Em contraste, PUT /v1/coffees/orders/1234 significa atualizar um recurso identificado por ” 1234 ” se existir; caso contrário, crie um novo pedido e use o URI orders/1234 para identificá-lo.

PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.

Outros já postaram excelentes respostas, eu só queria acrescentar que, com a maioria das linguagens, frameworks e casos de uso, você estará lidando muito com o POST, com muito mais frequência do que o PUT. Ao ponto em que PUT, DELETE, etc. são basicamente perguntas triviais.

Um POST é considerado algo de um método de tipo de fábrica. Você inclui dados com ele para criar o que você quer e o que está do outro lado sabe o que fazer com ele. Um PUT é usado para atualizar 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).

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

Eu tenho ficado muito chateado ultimamente por um equívoco popular de desenvolvedores web 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 do RFC 2616 (“Hypertext Transfer Protocol – HTTP / 1.1”), Seção 9.6 (“PUT”), você verá para que serve o PUT:

O método PUT solicita que a entidade incluída seja armazenada na solicitação-URI fornecida.

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 incluída. Esse recurso pode ser um processo de aceitação de dados, um gateway para algum outro protocolo ou uma entidade separada que aceita annotations. Em contraste, o URI em uma solicitação PUT identifica a entidade anexada à solicitação – o agente do usuário sabe o que é o URI e o servidor NÃO DEVE tentar aplicar a solicitação a algum outro recurso.

Não menciona nada sobre a diferença entre atualizar / criar, porque não é sobre isso. É 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 deste equívoco popular. Leia seus RFCs.

REST solicita que os desenvolvedores usem os methods HTTP explicitamente e de maneira consistente com a definição do protocolo. Esse princípio básico de design REST estabelece um mapeamento um-para-um entre as operações de criação, leitura, atualização e exclusão (CRUD) e os methods 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: Os princípios básicos da IBM

A diferença entre PUT e POST é esta:

O cliente usa PUT quando está encarregado de decidir qual URI o novo recurso deve ter.

O cliente usa POST quando o servidor está encarregado de decidir qual URI o novo recurso deve ter.

  1. GET: Recupera dados do servidor. Não deve ter outro efeito.
  2. POST: Envia dados para o servidor para criar uma nova entidade. Geralmente usado ao fazer upload de um arquivo ou ao enviar um formulário da web.
  3. PUT: semelhante ao POST, mas usado para replace uma entidade existente.
  4. PATCH: Similar ao PUT, mas usado para atualizar apenas certos campos dentro de uma entidade existente.
  5. DELETE: Remove dados do servidor.
  6. TRACE: Fornece uma maneira de testar o que o servidor recebe. Ele simplesmente retorna o que foi enviado.
  7. OPÇÕES: Permite que um cliente obtenha informações sobre os methods de solicitação suportados por um serviço. O header de resposta relevante é Permitir com methods suportados. Também usado no CORS como solicitação de comprovação para informar o servidor sobre o método de solicitação real e perguntar sobre headers personalizados.
  8. CABEÇA: Retorna apenas os headers de resposta.
  9. CONNECT: Usado pelo navegador quando sabe que ele fala com um proxy e o URI final começa com https: //. A intenção do CONNECT é permitir a session TLS criptografada de ponta a ponta, para que os dados sejam ilegíveis para um proxy.