De acordo com a especificação HTTP / 1.1:

O POSTmétodo é 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-URInoRequest-Line

Em outras palavras, POSTé usado para criar .

O PUTmétodo solicita que a entidade fechada seja armazenada sob o fornecido Request-URI. Se o Request-URIrefere-se a um recurso já existente, a entidade fechada deve ser considerada como uma versão modificada do que reside no servidor de origem. Se Request-URInão apontar para um recurso existente e esse URI puder ser definido como um novo recurso pelo agente solicitante, o servidor de origem poderá criar o recurso com esse URI. "

Ou seja, PUTé usado para criar ou substituir .

Então, qual deles deve ser usado para criar um recurso? Ou é preciso apoiar os dois?

No geral:

PUT e POST podem ser usados ​​para criar.

Você precisa perguntar "para o que você está executando a ação?" para distinguir o que você deve usar. Vamos supor que você esteja criando uma API para fazer perguntas. Se você deseja usar o POST, faça isso com uma lista de perguntas. Se você quiser usar o PUT, faça isso com uma pergunta específica.

Podem ser usados ​​ótimos, portanto, qual deles devo usar no meu design RESTful:

Você não precisa oferecer suporte a PUT e POST.

O que é usado fica a seu critério. Mas lembre-se de usar o correto, dependendo do objeto que você está referenciando na solicitação.

Algumas considerações:

• Você nomeia seus objetos de URL que você cria explicitamente ou deixa o servidor decidir? Se você os nomear, use PUT. Se você deixar o servidor decidir, use o POST.
• PUT é idempotente; portanto, se você colocar um objeto duas vezes, ele não terá efeito. Esta é uma boa propriedade, então eu usaria PUT quando possível.
• Você pode atualizar ou criar um recurso com PUT com o mesmo URL de objeto
• Com o POST, você pode receber 2 solicitações ao mesmo tempo, fazendo modificações em uma URL, e elas podem atualizar diferentes partes do objeto.

Um exemplo:

Escrevi o seguinte como parte de outra resposta no SO sobre isso :

POSTAR:

Usado para modificar e atualizar um recurso

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Observe que o seguinte é um erro:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

Se o URL ainda não estiver criado, você não deve usar o POST para criá-lo enquanto especifica o nome. Isso deve resultar em um erro 'recurso não encontrado', porque <new_question>ainda não existe. Você deve COLOCAR o <new_question> recurso no servidor primeiro.

Você pode fazer algo assim para criar recursos usando o POST:

POST /questions HTTP/1.1
Host: www.example.com/

Observe que, nesse caso, o nome do recurso não é especificado, o novo caminho da URL dos objetos será retornado a você.

COLOCAR:

Usado para criar um recurso ou substituí-lo. Enquanto você especifica os recursos, novo URL.

Para um novo recurso:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

Para substituir um recurso existente:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

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 createdou replacedcom o estado definido pela representação incluída na carga útil da mensagem de solicitação.

Você pode encontrar afirmações na web que dizem

• POST deve ser usado para criar um recurso e PUT deve ser usado para modificar um
• PUT deve ser usado para criar um recurso e POST deve ser usado para modificar um

Nenhum dos dois está certo.

Melhor é escolher entre PUT e POST com base na idempotência da ação.

PUT implica colocar um recurso - substituindo completamente o que estiver disponível no URL fornecido por algo diferente. Por definição, um PUT é idempotente. Faça quantas vezes quiser e o resultado será o mesmo. x=5é idempotente. Você pode COLOCAR um recurso se ele existe anteriormente ou não (por exemplo, para Criar ou Atualizar)!

O POST atualiza um recurso, adiciona um recurso subsidiário ou causa uma alteração. Um POST não é idempotente, da maneira que x++não é idempotente.

Por esse argumento, PUT é para criar quando você souber o URL da coisa que criará. O POST pode ser usado para criar quando você souber o URL da "fábrica" ​​ou gerente da categoria de itens que deseja criar.

tão:

POST /expense-report

ou:

PUT  /expense-report/10929

• POST para uma URL cria um recurso filho em uma URL definida pelo servidor .
• COLOCAR em uma URL cria / substitui o recurso por inteiro na URL definida pelo cliente .
• PATCH para um URL atualiza parte do recurso naquele URL definido pelo cliente.

A especificação relevante para PUT e POST é RFC 2616 §9.5ff.

O POST cria um recurso filho ; portanto, o POST /itemscria recursos que residem no /itemsrecurso. Por exemplo. /items/1. Enviar o mesmo pacote de postagem duas vezes criará dois recursos.

PUT é para criar ou substituir um recurso em uma URL conhecida pelo cliente .

Portanto: PUT é apenas um candidato para CREATE onde o cliente já conhece o URL antes que o recurso seja criado. Por exemplo. /blogs/nigel/entry/when_to_use_post_vs_putcomo o título é usado como a chave do recurso

PUT substitui o recurso no URL conhecido, se ele já existir, portanto, enviar a mesma solicitação duas vezes não terá efeito. Em outras palavras, as chamadas para PUT são idempotentes .

O RFC é assim:

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,

Nota: PUT tem sido usado principalmente para atualizar recursos (substituindo-os por inteiro), mas recentemente há um movimento no sentido de usar PATCH para atualizar recursos existentes, pois PUT especifica que ele substitui todo o recurso. RFC 5789.

Atualização 2018 : Existe um caso que pode ser feito para evitar o PUT. Consulte "REST sem PUT"

Com a técnica "REST sem PUT", a idéia é que os consumidores sejam forçados a postar novos recursos de solicitação 'substantivo'. Conforme discutido anteriormente, alterar o endereço de correspondência de um cliente é um POST para um novo recurso "ChangeOfAddress", não uma PUT de um recurso de "Cliente" com um valor de campo de endereço de correspondência diferente.

extraído do REST API Design - Modelagem de Recursos por Prakash Subramaniam do Thoughtworks

Isso força a API a evitar problemas de transição de estado com vários clientes que atualizam um único recurso e corresponde melhor à fonte de eventos e ao CQRS. Quando o trabalho é concluído de forma assíncrona, POST a transformação e aguardando sua aplicação parece apropriada.

Resumo:

Crio:

Pode ser realizado com PUT ou POST da seguinte maneira:

COLOCAR

Cria O novo recurso com newResourceId como o identificador, sob os recursos / URI, ou coleta .

PUT /resources/<newResourceId> HTTP/1.1 

POSTAR

Cria um novo recurso no URI / resources ou coleção . Normalmente, o identificador é retornado pelo servidor.

POST /resources HTTP/1.1

Atualizar:

Só pode ser executado com PUT da seguinte maneira:

COLOCAR

Atualiza o recurso com o existenteResourceId como o identificador, no / resources URI, ou coleção .

PUT /resources/<existingResourceId> HTTP/1.1

Explicação:

Ao lidar com REST e URI como geral, você tem genérico à esquerda e específico à direita . Os genéricos geralmente são chamados de coleções e os itens mais específicos podem ser chamados de recurso . Observe que um recurso pode conter uma coleção .

Exemplos:

<- genérico - específico ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

Quando você usa o POST, está sempre se referindo a uma coleção ; portanto, sempre que você diz:

POST /users HTTP/1.1

você está postando um novo usuário na coleção de usuários .

Se você continuar e tentar algo como isto:

POST /users/john HTTP/1.1

ele vai trabalhar, mas semanticamente você está dizendo que você deseja adicionar um recurso para o john coleção sob a usuários coleção .

Depois de usar o PUT, você está se referindo a um recurso ou item único, possivelmente dentro de uma coleção . Então, quando você diz:

PUT /users/john HTTP/1.1

você está informando à atualização do servidor ou cria, se não existir, o recurso john na coleção de usuários .

Especificação:

Deixe-me destacar algumas partes importantes das especificações:

POSTAR

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

Portanto, cria um novo recurso em uma coleção .

COLOCAR

O método PUT solicita que a entidade fechada seja armazenada no URI de solicitação fornecido. Se o pedido de URI refere-se a um recurso já existente , a entidade fechada deve ser considerada como uma versão modificada do que reside no servidor de origem. Se o Request-URI não apontar para um recurso existente e esse URI puder ser definido como um novo recurso pelo agente solicitante, o servidor de origem poderá criar o recurso com esse URI. "

Portanto, crie ou atualize com base na existência do recurso .

Referência:

• Especificação HTTP / 1.1
• Wikipedia - REST
• Identificadores uniformes de recursos (URI): sintaxe genérica e semântica

POST significa "criar novo", como em "Aqui está a entrada para criar um usuário, crie para mim".

PUT significa "inserir, substituir se já existir", como em "Aqui estão os dados para o usuário 5".

Você POSTpode acessar example.com/users, como ainda não conhece URLo usuário, deseja que o servidor o crie.

Você PUTpode example.com/users/id desde que deseja substituir / criar um usuário específico .

POSTAR duas vezes com os mesmos dados significa criar dois usuários idênticos com IDs diferentes. Colocar duas vezes com os mesmos dados cria o usuário primeiro e atualiza-o para o mesmo estado na segunda vez (sem alterações). Como você termina com o mesmo estado depois de PUTnão importa quantas vezes você o executa, diz-se que é "igualmente potente" todas as vezes - idempotente. Isso é útil para tentar novamente solicitações automaticamente. Chega de 'você tem certeza de que deseja reenviar' ao pressionar o botão Voltar no navegador.

Um conselho geral é usar POSTquando você precisar que o servidor esteja no controle da URLgeração de seus recursos. Use de PUToutra forma. Prefere PUT mais POST.

Eu gostaria de adicionar meu conselho "pragmático". Use PUT quando souber o "id" pelo qual o objeto que você está salvando pode ser recuperado. O uso de PUT não funcionará muito bem se você precisar, digamos, de um ID gerado pelo banco de dados a ser retornado para que você faça pesquisas ou atualizações futuras.

Portanto: para salvar um usuário existente ou aquele em que o cliente gera o ID e foi verificado que o ID é exclusivo:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

Caso contrário, use POST para criar inicialmente o objeto e PUT para atualizar o objeto:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

Use POST para criar e PUT para atualizar. É assim que Ruby on Rails está fazendo isso, de qualquer maneira.

PUT    /items/1      #=> update
POST   /items        #=> create

Ambos são usados ​​para transmissão de dados entre cliente e servidor, mas há diferenças sutis entre eles, que são:

Analogia:

• PUT, ou seja, pegue e coloque onde estava.
• POST como correio enviar no pós escritório.

Mídia Social / Analogia de Rede:

• Postar nas mídias sociais: quando postamos uma mensagem, ela cria uma nova postagem.
• Coloque (ou seja, edite) a mensagem que já publicamos.

REST é um muito conceito de alto nível. De fato, nem sequer menciona HTTP!

Se você tiver alguma dúvida sobre como implementar o REST no HTTP, sempre poderá dar uma olhada na especificação do Atom Publication Protocol (AtomPub) . O AtomPub é um padrão para a criação de serviços da Web RESTful com HTTP, desenvolvido por muitos especialistas em HTTP e REST, com algumas informações de Roy Fielding, o inventor do REST e (co) inventor do próprio HTTP.

De fato, você pode até usar o AtomPub diretamente. Embora tenha saído da comunidade de blogs, não é de forma alguma restrito aos blogs: é um protocolo genérico para interagir RESTfully com coleções arbitrárias (aninhadas) de recursos arbitrários via HTTP. Se você puder representar seu aplicativo como uma coleção aninhada de recursos, poderá usar o AtomPub e não se preocupar em usar PUT ou POST, quais códigos de status HTTP retornar e todos esses detalhes.

Isto é o que AtomPub tem a dizer sobre criação de recursos (seção 9.2):

Para adicionar membros a uma coleção, os clientes enviam solicitações POST ao URI da coleção.

A decisão de usar PUT ou POST para criar um recurso em um servidor com uma API HTTP + REST é baseada em quem possui a estrutura de URL. Tendo o cliente conhecido ou participando da definição, a estrutura da URL é um acoplamento desnecessário semelhante aos acoplamentos indesejáveis ​​que surgiram da SOA. Escapar de tipos de acoplamentos é o motivo pelo qual o REST é tão popular. Portanto, o método adequado a ser usado é o POST. Há exceções a essa regra e elas ocorrem quando o cliente deseja manter o controle sobre a estrutura de localização dos recursos que implanta. Isso é raro e provavelmente significa que algo mais está errado.

Neste ponto, algumas pessoas argumentam que, se URLs RESTful são usadas, o cliente conhece a URL do recurso e, portanto, uma PUT é aceitável. Afinal, é por isso que os URLs canônicos, normalizados, do Ruby on Rails e do Django são importantes, veja a API do Twitter ... blá blá blá. Essas pessoas precisam entender que não existe um URL repousante e que o próprio Roy Fielding afirma que :

Uma API REST não deve definir nomes ou hierarquias de recursos fixos (um acoplamento óbvio de cliente e servidor). Os servidores devem ter liberdade para controlar seu próprio espaço para nome. Em vez disso, permita que os servidores instruam os clientes sobre como criar URIs apropriados, como é feito em formulários HTML e modelos de URI, definindo essas instruções nos tipos de mídia e nas relações de vínculo. [Falha aqui implica que os clientes estão assumindo uma estrutura de recursos devido a informações fora da banda, como um padrão específico de domínio, que é o equivalente orientado a dados ao acoplamento funcional da RPC].

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

A idéia de um URL RESTful é na verdade uma violação do REST, pois o servidor é responsável pela estrutura da URL e deve estar livre para decidir como usá-lo para evitar o acoplamento. Se isso confunde você lê sobre o significado da autodescoberta no design da API.

O uso do POST para criar recursos vem com uma consideração de design, porque o POST não é idempotente. Isso significa que repetir um POST várias vezes não garante o mesmo comportamento todas as vezes. Isso assusta as pessoas a usar o PUT para criar recursos quando não deveriam. Eles sabem que está errado (POST é para CREATE), mas o fazem de qualquer maneira porque não sabem como resolver esse problema. Essa preocupação é demonstrada na seguinte situação:

1. O cliente POST um novo recurso para o servidor.
2. O servidor processa a solicitação e envia uma resposta.
3. O cliente nunca recebe a resposta.
4. O servidor não sabe que o cliente não recebeu a resposta.
5. O cliente não possui uma URL para o recurso (portanto, PUT não é uma opção) e repete o POST.
6. O POST não é idempotente e o servidor…

O passo 6 é onde as pessoas geralmente ficam confusas sobre o que fazer. No entanto, não há razão para criar um kludge para resolver esse problema. Em vez disso, o HTTP pode ser usado conforme especificado na RFC 2616 e o servidor responde:

10.4.10 409 Conflito

A solicitação não pôde ser concluída devido a um conflito com o estado atual do recurso. Esse código é permitido apenas em situações em que se espera que o usuário possa resolver o conflito e reenviar a solicitação. O corpo da resposta DEVE incluir o suficiente

informações para o usuário reconhecer a origem do conflito. Idealmente, a entidade de resposta incluiria informações suficientes para que o usuário ou agente do usuário corrija o problema; no entanto, isso pode não ser possível e não é necessário.

É provável que os conflitos ocorram em resposta a uma solicitação PUT. Por exemplo, se o controle de versão estava sendo usado e a entidade que estava sendo PUT incluía alterações em um recurso que entra em conflito com aquelas feitas por uma solicitação anterior (de terceiros), o servidor pode usar a resposta 409 para indicar que não pode concluir a solicitação . Nesse caso, a entidade de resposta provavelmente conteria uma lista das diferenças entre as duas versões em um formato definido pela resposta Content-Type.

Responder com um código de status 409 Conflict é o recurso correto porque :

• Executar um POST de dados com um ID que corresponda a um recurso já existente no sistema é "um conflito com o estado atual do recurso".
• Como a parte importante é que o cliente entenda que o servidor possui o recurso e tome as medidas apropriadas. Essa é uma "situação (s) em que se espera que o usuário consiga resolver o conflito e reenviar a solicitação".
• Uma resposta que contenha a URL do recurso com o ID conflitante e as pré-condições apropriadas para o recurso forneceria "informações suficientes para que o usuário ou o agente do usuário corrija o problema", que é o caso ideal para a RFC 2616.

Atualização baseada no lançamento do RFC 7231 para substituir 2616

O RFC 7231 foi projetado para substituir 2616 e na Seção 4.3.3 descreve a seguinte resposta possível para um POST

Se o resultado do processamento de um POST seria equivalente a uma representação de um recurso existente, um servidor de origem PODE redirecionar o agente do usuário para esse recurso enviando uma resposta 303 (Consulte Outros) com o identificador do recurso existente no campo Localização. Isso tem os benefícios de fornecer ao agente do usuário um identificador de recurso e transferir a representação por meio de um método mais passível de armazenamento em cache compartilhado, embora ao custo de uma solicitação extra se o agente do usuário ainda não tiver a representação em cache.

Agora pode ser tentador simplesmente retornar um 303 no caso de um POST ser repetido. No entanto, o oposto é verdadeiro. Retornar um 303 só faria sentido se várias solicitações de criação (criando recursos diferentes) retornassem o mesmo conteúdo. Um exemplo seria um "obrigado por enviar sua mensagem de solicitação" que o cliente não precisa baixar novamente a cada vez. A RFC 7231 ainda mantém na seção 4.2.2 que o POST não deve ser idempotente e continua mantendo que o POST deve ser usado para criação.

Para mais informações sobre isso, leia este artigo .

Eu gosto deste conselho, da definição de PUT da RFC 2616 :

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 incluída na 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.

Isso combina com os outros conselhos aqui, que PUT é melhor aplicado a recursos que já têm um nome e POST é bom para criar um novo objeto em um recurso existente (e deixar que o servidor o nomeie).

Eu interpreto isso e os requisitos de idempotência no PUT, para dizer que:

• POST é bom para criar novos objetos em uma coleção (e create não precisa ser idempotente)
• PUT é bom para atualizar objetos existentes (e a atualização precisa ser idempotente)
• O POST também pode ser usado para atualizações não idempotentes de objetos existentes (especialmente, alterar parte de um objeto sem especificar a coisa toda - se você pensar sobre isso, criar um novo membro de uma coleção é realmente um caso especial desse tipo de atualização, da perspectiva da coleção)
• PUT também pode ser usado para criar se e somente se você permitir que o cliente nomeie o recurso. Mas como os clientes REST não devem fazer suposições sobre a estrutura da URL, isso é menos no espírito das coisas.

Em resumo:

PUT é idempotente, onde o estado do recurso será o mesmo se a mesma operação for executada uma vez ou várias vezes.

POST não é idempotente, onde o estado do recurso pode se tornar diferente se a operação for executada várias vezes em comparação com a execução de uma única vez.

Analogia com consulta ao banco de dados

PUT Você pode pensar em algo semelhante a "UPDATE STUDENT SET address =" abc "onde id =" 123 ";

POST Você pode pensar em algo como "INSERIR NO ALUNO (nome, endereço) VALORES (" abc "," xyzzz ");

O ID do aluno é gerado automaticamente.

Com PUT, se a mesma consulta for executada várias vezes ou uma vez, o estado da tabela STUDENT permanecerá o mesmo.

No caso do POST, se a mesma consulta for executada várias vezes, vários registros de Alunos serão criados no banco de dados e o estado do banco de dados será alterado a cada execução de uma consulta "INSERT".

NOTA: O PUT precisa de um local de recurso (já recurso) no qual a atualização precisa ocorrer, enquanto o POST não exige isso. Portanto, intuitivamente, o POST é destinado à criação de um novo recurso, enquanto o PUT é necessário para atualizar o recurso já existente.

Alguns podem sugerir que as atualizações possam ser realizadas com o POST. Não existe uma regra rígida qual usar para atualizações ou qual criar para criar. Novamente, essas são convenções e, intuitivamente, estou inclinado ao raciocínio acima mencionado e o sigo.

O POST é como postar uma carta em uma caixa de correio ou postar um email em uma fila de emails. PUT é como quando você coloca um objeto em um cubículo ou em um local em uma prateleira (ele tem um endereço conhecido).

Com o POST, você está postando no endereço da QUEUE ou COLLECTION. Com PUT, você está colocando no endereço do ITEM.

PUT é idempotente. Você pode enviar a solicitação 100 vezes e isso não importa. O POST não é idempotente. Se você enviar a solicitação 100 vezes, receberá 100 e-mails ou 100 cartas na sua caixa postal.

Uma regra geral: se você souber o ID ou nome do item, use PUT. Se você deseja que o ID ou nome do item seja atribuído pela parte receptora, use POST.

Nova resposta (agora que eu entendo melhor o REST):

PUT é apenas uma declaração de qual conteúdo o serviço deve, a partir de agora, usar para renderizar representações do recurso identificado pelo cliente; O POST é uma declaração de qual conteúdo o serviço deve, a partir de agora, conter (possivelmente duplicado), mas cabe ao servidor como identificar esse conteúdo.

PUT x(se xidentifica um recurso ): "Substitua o conteúdo do recurso identificado por xpelo meu conteúdo".

PUT x(se xnão identificar um recurso): "Crie um novo recurso contendo meu conteúdo e usex para identificá-lo."

POST x: "Armazene meu conteúdo e me forneça um identificador que eu possa usar para identificar um recurso (antigo ou novo) que contém esse conteúdo (possivelmente misturado com outro conteúdo). O referido recurso deve ser idêntico ou subordinado ao que é xidentificado". " o recurso de y é subordinado ao recurso de x " é tipicamente, mas não necessariamente implementado, tornando y um subcaminho de x (por exemplo, x = /fooe y = /foo/bar) e modificando a (s) representação (ões) do de x recurso para refletir a existência de um novo recurso, por exemplo, com um hiperlink para yrecurso e alguns metadados. Somente o último é realmente essencial para um bom design, pois os URLs são opacos no REST - você deve usar a hipermídia em em vez da construção de URL do lado do cliente para atravessar o serviço de qualquer maneira.

No REST, não existe um recurso que contenha "conteúdo". Refiro-me como "conteúdo" aos dados que o serviço usa para renderizar representações de forma consistente. Geralmente consiste em algumas linhas relacionadas em um banco de dados ou arquivo (por exemplo, um arquivo de imagem). Cabe ao serviço converter o conteúdo do usuário em algo que o serviço possa usar, por exemplo, converter uma carga JSON em instruções SQL.

Resposta original (pode ser mais fácil de ler) :

PUT /something(se /somethingjá existir): "Pegue o que tiver em/something e substitua pelo que eu lhe der."

PUT /something(se /somethingainda não existir): "Pegue o que eu lhe dou e coloque-o no /something".

POST /something: "Pegue o que eu lhe der e coloque-o em qualquer lugar que desejar /something, desde que você me dê o URL quando terminar."

Resposta curta:

Regra simples: use o POST para criar, use PUT para atualizar.

Resposta longa:

POSTAR:

• POST é usado para enviar dados ao servidor.
• Útil quando o URL do recurso é desconhecido

COLOCAR:

• PUT é usado para transferir o estado para o servidor
• Útil quando o URL de um recurso é conhecido

Resposta mais longa:

Para entendê-lo, precisamos questionar por que o PUT foi necessário, quais foram os problemas que o PUT estava tentando resolver que o POST não conseguiu.

Do ponto de vista da arquitetura REST, não há nada que importe. Poderíamos ter vivido sem o PUT também. Mas, do ponto de vista de um desenvolvedor de cliente, ele tornou sua vida muito mais simples.

Antes da PUT, os clientes não podiam saber diretamente a URL que o servidor gerou ou se tudo isso gerou alguma ou se os dados a serem enviados ao servidor já estão atualizados ou não. O PUT aliviou o desenvolvedor de todas essas dores de cabeça. PUT é idempotente, PUT lida com as condições da corrida e PUT permite que o cliente escolha o URL.

O Ruby on Rails 4.0 usará o método 'PATCH' em vez de PUT para fazer atualizações parciais.

A RFC 5789 diz sobre PATCH (desde 1995):

É necessário um novo método para melhorar a interoperabilidade e evitar erros. O método PUT já está definido para substituir um recurso por um novo corpo completo e não pode ser reutilizado para fazer alterações parciais. Caso contrário, proxies e caches, e até mesmo clientes e servidores, poderão ficar confusos quanto ao resultado da operação. O POST já está sendo usado, mas sem ampla interoperabilidade (por exemplo, não há uma maneira padrão de descobrir o suporte ao formato de patch). PATCH foi mencionado nas especificações HTTP anteriores, mas não completamente definido.

" Edge Rails: PATCH é o novo método HTTP primário para atualizações ", explica.

Correndo o risco de reafirmar o que já foi dito, parece importante lembrar que PUT implica que o cliente controla o que a URL acabará sendo ao criar um recurso. Portanto, parte da escolha entre PUT e POST será sobre o quanto você pode confiar no cliente para fornecer URL normalizada e correta, coerente com o esquema de URL.

Quando você não pode confiar totalmente no cliente para fazer a coisa certa, seria mais apropriado usar o POST para criar um novo item e, em seguida, enviar a URL de volta ao cliente na resposta.

De uma maneira muito simples, estou tomando o exemplo da linha do tempo do Facebook.

Caso 1: quando você publica algo em sua linha do tempo, é uma nova entrada. Portanto, nesse caso, eles usam o método POST porque o método POST é não-idempotente.

Caso 2: se seu amigo comentar sua postagem pela primeira vez, isso também criará uma nova entrada no banco de dados para que o método POST seja usado.

Caso 3: se o seu amigo editar o comentário dele, nesse caso, ele possui um ID de comentário, para atualizar um comentário existente em vez de criar uma nova entrada no banco de dados. Portanto, para esse tipo de operação, use o método PUT porque é idempotente. *

Em uma única linha, use o POST para adicionar uma nova entrada no banco de dados e PUT para atualizar algo no banco de dados.

A consideração mais importante é a confiabilidade . Se uma mensagem POST for perdida, o estado do sistema é indefinido. A recuperação automática é impossível. Para mensagens PUT, o estado é indefinido apenas até a primeira tentativa bem-sucedida.

Por exemplo, pode não ser uma boa ideia criar transações com cartão de crédito com o POST.

Se você tiver URIs gerados automaticamente em seu recurso, ainda poderá usar PUT passando um URI gerado (apontando para um recurso vazio) para o cliente.

Algumas outras considerações:

• O POST invalida cópias em cache de todo o recurso que contém (melhor consistência)
• As respostas PUT não são armazenáveis ​​em cache, enquanto as respostas POST são (Exigir local de conteúdo e expiração)
• O PUT é menos suportado, por exemplo, Java ME, navegadores mais antigos, firewalls

Os leitores novos deste tópico ficarão impressionados com a interminável discussão sobre o que você deve fazer e a relativa ausência de lições da experiência. O fato de o REST ser "preferido" em relação ao SOAP é, suponho, um aprendizado de alto nível com a experiência, mas, por Deus, devemos ter progredido a partir daí? É 2016. A dissertação de Roy foi em 2000. O que desenvolvemos? Foi divertido? Foi fácil integrar? Suportar? Ele suportará o surgimento de smartphones e conexões móveis esquisitas?

Segundo ME, as redes da vida real não são confiáveis. Solicita tempo limite. As conexões são redefinidas. As redes ficam inoperantes por horas ou dias por vez. Os trens entram em túneis com usuários móveis a bordo. Para qualquer solicitação (como ocasionalmente reconhecido em toda essa discussão), a solicitação pode cair na água a caminho ou a resposta pode cair na água no caminho de volta. Nessas condições, emitir solicitações PUT, POST e DELETE diretamente contra recursos substantivos sempre me pareceu um pouco brutal e ingênuo.

O HTTP não faz nada para garantir a conclusão confiável da solicitação-resposta, e isso é ótimo porque esse é o trabalho dos aplicativos que reconhecem a rede. Ao desenvolver esse aplicativo, você pode percorrer os aros para usar PUT em vez do POST e, em seguida, mais aros para dar um certo tipo de erro no servidor se detectar solicitações duplicadas. De volta ao cliente, você precisa pular etapas para interpretar esses erros, buscar novamente, revalidar e republicar.

Ou você pode fazer o seguinte : considere suas solicitações inseguras como recursos efêmeros para um único usuário (vamos chamá-los de ações). Os clientes solicitam uma nova "ação" em um recurso substantivo com um POST vazio para o recurso. O POST será usado apenas para isso. Uma vez em posse do URI da ação recém-criada com segurança, o cliente coloca a solicitação insegura no URI da ação, não no recurso de destino . Resolver a ação e atualizar o recurso "real" é o trabalho da sua API e é aqui dissociado da rede não confiável.

O servidor faz o negócio, retorna a resposta e a armazena na URI de ação acordada . Se algo der errado, o cliente repetirá a solicitação (comportamento natural!) E, se o servidor já a tiver visto, repetirá a resposta armazenada e não fará mais nada .

Você identificará rapidamente a semelhança com as promessas: criamos e devolvemos o espaço reservado para o resultado antes de fazer qualquer coisa. Também como uma promessa, uma ação pode ter sucesso ou falhar uma vez, mas seu resultado pode ser buscado repetidamente.

O melhor de tudo é que damos aos aplicativos de envio e recebimento a chance de vincular a ação identificada exclusivamente à exclusividade em seus respectivos ambientes. E podemos começar a exigir e impor !, comportamento responsável dos clientes: repita suas solicitações o quanto quiser, mas não gere uma nova ação até que você possua um resultado definitivo da existente.

Como tal, numerosos problemas espinhosos desaparecem. Solicitações de inserção repetidas não criarão duplicatas e não criaremos o recurso real até que possuamos os dados. (as colunas do banco de dados podem permanecer não anuláveis). Solicitações de atualização repetidas não atingem estados incompatíveis e não substituem as alterações subseqüentes. Os clientes podem (re) buscar e processar sem problemas a confirmação original por qualquer motivo (falha do cliente, falta de resposta etc.).

Solicitações de exclusão sucessivas podem ver e processar a confirmação original, sem ocorrer um erro 404. Se as coisas demorarem mais do que o esperado, podemos responder provisoriamente e temos um local onde o cliente pode verificar novamente o resultado definitivo. A parte mais legal desse padrão é sua propriedade Kung-Fu (Panda). Tomamos uma fraqueza, a propensão para os clientes repetirem uma solicitação sempre que não entenderem a resposta e a transformarem em uma força :-)

Antes de me dizer que isso não é RESTful, considere as inúmeras maneiras pelas quais os princípios REST são respeitados. Os clientes não constroem URLs. A API permanece detectável, embora com uma pequena alteração na semântica. Os verbos HTTP são usados ​​adequadamente. Se você acha que essa é uma grande mudança para implementar, posso dizer por experiência que não é.

Se você acha que terá enormes quantidades de dados para armazenar, vamos falar sobre volumes: uma confirmação típica de atualização é uma fração de um kilobyte. Atualmente, o HTTP oferece um ou dois minutos para responder definitivamente. Mesmo que você armazene ações apenas por uma semana, os clientes terão muitas chances de alcançá-los. Se você tiver volumes muito altos, convém um armazenamento de valores-chave dedicado compatível com ácido ou uma solução na memória.

Além das diferenças sugeridas por outros, quero adicionar mais uma.

No método POST , você pode enviar parâmetros de corpo emform-data

No método PUT , você deve enviar parâmetros de corpo emx-www-form-urlencoded

Cabeçalho Content-Type:application/x-www-form-urlencoded

De acordo com isso, você não pode enviar arquivos ou dados de várias partes no método PUT

EDITAR

O tipo de conteúdo "application / x-www-form-urlencoded" é ineficiente para enviar grandes quantidades de dados binários ou texto contendo caracteres não ASCII. O tipo de conteúdo "dados de várias partes / formulário" deve ser usado para enviar formulários que contêm arquivos, dados não ASCII e dados binários.

O que significa que se você tiver que enviar

arquivos, dados não ASCII e dados binários

você deve usar o método POST

Sempre parece haver alguma confusão sobre quando usar o HTTP POST versus o método HTTP PUT para serviços REST. A maioria dos desenvolvedores tentará associar operações CRUD diretamente aos métodos HTTP. Argumentarei que isso não está correto e não se pode simplesmente associar os conceitos CRUD aos métodos HTTP. Isso é:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

É verdade que o R (etrieve) e D (elete) das operações CRUD podem ser mapeados diretamente para os métodos HTTP GET e DELETE, respectivamente. No entanto, a confusão está nas operações C (reate) e U (atualização). Em alguns casos, é possível usar o PUT para criar, enquanto em outros casos um POST será necessário. A ambiguidade está na definição de um método HTTP PUT versus um método HTTP POST.

De acordo com as especificações do HTTP 1.1, os métodos GET, HEAD, DELETE e PUT devem ser idempotentes e o método POST não é idempotente. Isso significa que uma operação é idempotente se puder ser executada em um recurso uma ou várias vezes e sempre retornar o mesmo estado desse recurso. Enquanto uma operação não idempotente pode retornar um estado modificado do recurso de uma solicitação para outra. Portanto, em uma operação não idempotente, não há garantia de que alguém receberá o mesmo estado de um recurso.

Com base na definição idempotente acima, minha opinião sobre o método HTTP PUT versus o método HTTP POST para serviços REST é: Use o método HTTP PUT quando:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

Nos dois casos, essas operações podem ser executadas várias vezes com os mesmos resultados. Esse é o recurso não será alterado solicitando a operação mais de uma vez. Portanto, uma verdadeira operação idempotente. Use o método HTTP POST quando:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

Conclusão

Não correlacione e mapeie diretamente operações CRUD para métodos HTTP para serviços REST. O uso de um método HTTP PUT versus um método HTTP POST deve ser baseado no aspecto idempotente dessa operação. Ou seja, se a operação for idempotente, use o método HTTP PUT. Se a operação não for idempotente, use o método HTTP POST.

o servidor de origem pode criar o recurso com esse URI

Então você usa POST e provavelmente, mas não é necessário, PUT para criação de recursos. Você não precisa apoiar os dois. Para mim, o POST é perfeitamente suficiente. Portanto, é uma decisão de design.

Como sua cotação mencionou, você usa PUT para criar um recurso não atribuído a um IRI e deseja criar um recurso de qualquer maneira. Por exemplo, PUT /users/123/passwordgeralmente substitui a senha antiga por uma nova, mas você pode usá-la para criar uma senha se ela ainda não existir (por exemplo, por usuários registrados recentemente ou restaurando usuários banidos).

Vou pousar com o seguinte:

PUT refere-se a um recurso identificado pelo URI. Nesse caso, você está atualizando. É a parte dos três verbos que se referem aos recursos - excluir e começar a ser os outros dois.

O POST é basicamente uma mensagem de forma livre, com seu significado sendo definido como "fora da banda". Se a mensagem puder ser interpretada como adicionando um recurso a um diretório, tudo bem, mas basicamente você precisa entender a mensagem que está enviando (postando) para saber o que acontecerá com o recurso.

Como PUT, GET e DELETE se referem a um recurso, eles também são, por definição, idempotentes.

O POST pode executar as outras três funções, mas a semântica da solicitação será perdida nos intermediários, como caches e proxies. Isso também se aplica ao fornecimento de segurança no recurso, pois o URI de uma postagem não indica necessariamente o recurso ao qual está sendo aplicado (pode ser).

Um PUT não precisa ser uma criação; o serviço poderá ter erro se o recurso ainda não estiver criado, mas atualizá-lo. Ou vice-versa - ele pode criar o recurso, mas não permitir atualizações. A única coisa necessária sobre o PUT é que ele aponta para um recurso específico e sua carga útil é a representação desse recurso. Uma PUT bem-sucedida significa (exceto interferência) que um GET recuperaria o mesmo recurso.

Editar: Mais uma coisa - um PUT pode criar, mas, se o fizer, o ID deve ser um ID natural - também conhecido como endereço de email. Dessa forma, quando você coloca duas vezes, o segundo put é uma atualização do primeiro. Isso o torna idempotente .

Se o ID for gerado (um novo ID de funcionário, por exemplo), o segundo PUT com a mesma URL criará um novo registro, o que viola a regra de idempotência. Nesse caso, o verbo seria POST e a mensagem (não recurso) seria criar um recurso usando os valores definidos nesta mensagem.

A semântica deve ser diferente, pois "PUT", como "GET", deve ser idempotente - o que significa que você pode solicitar exatamente o mesmo PUT várias vezes e o resultado será como se você a executasse apenas uma vez.

Descreverei as convenções que considero mais utilizadas e mais úteis:

Quando você coloca um recurso em um URL específico, o que acontece é que ele deve ser salvo nesse URL ou algo nesse sentido.

Quando você posta para um recurso em um URL específico, geralmente está postando uma informação relacionada a esse URL. Isso implica que o recurso no URL já existe.

Por exemplo, quando você deseja criar um novo fluxo, você pode COLOCÁ-lo em algum URL. Mas quando você deseja POSTAR uma mensagem em um fluxo existente, você POST na URL.

Quanto à modificação das propriedades do fluxo, você pode fazer isso com PUT ou POST. Basicamente, use apenas "PUT" quando a operação for idempotente - caso contrário, use POST.

Observe, no entanto, que nem todos os navegadores modernos oferecem suporte a verbos HTTP que não sejam GET ou POST.

Na maioria das vezes, você os usará assim:

• POSTAR um recurso em uma coleção
• COLOCAR um recurso identificado pela coleção /: id

Por exemplo:

• POST / itens
• PUT / itens / 1234

Nos dois casos, o corpo da solicitação contém os dados para o recurso a ser criado ou atualizado. Deveria ser óbvio pelos nomes das rotas que o POST não é idempotente (se você chamá-lo 3 vezes, ele criará 3 objetos), mas PUT é idempotente (se você chamá-lo 3 vezes o resultado é o mesmo). PUT é frequentemente usado para operação "upsert" (criar ou atualizar), mas você sempre pode retornar um erro 404 se desejar usá-lo apenas para modificar.

Observe que o POST "cria" um novo elemento na coleção e PUT "substitui" um elemento em uma determinada URL, mas é uma prática muito comum usar o PUT para modificações parciais, ou seja, usá-lo apenas para atualizar os recursos existentes e modifique apenas os campos incluídos no corpo (ignorando os outros campos). Tecnicamente, isso está incorreto. Se você deseja ser purista de REST, o PUT deve substituir todo o recurso e você deve usar PATCH para a atualização parcial. Pessoalmente, não me importo tanto quanto o comportamento é claro e consistente em todos os pontos de extremidade da API.

Lembre-se de que REST é um conjunto de convenções e diretrizes para manter sua API simples. Se você terminar com uma solução alternativa complicada apenas para marcar a caixa "RESTfull", estará derrotando o objetivo;)

Embora exista provavelmente uma maneira agnóstica de descrevê-las, parece estar em conflito com várias declarações de respostas a sites.

Sejamos claros e diretos aqui. Se você é um desenvolvedor .NET trabalhando com API da Web, os fatos são (da documentação da API da Microsoft), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -api-that-support-crud-operations :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

Claro que você "pode" usar o "POST" para atualizar, mas basta seguir as convenções estabelecidas para você com sua estrutura fornecida. No meu caso, é .NET / Web API, então PUT é para UPDATE, não há debate.

Espero que isso ajude os desenvolvedores da Microsoft que leem todos os comentários nos links dos sites Amazon e Sun / Java.

Aqui está uma regra simples:

Colocar em um URL deve ser usado para atualizar ou criar o recurso que pode ser localizado nesse URL.

O POST para uma URL deve ser usado para atualizar ou criar um recurso localizado em outra URL ("subordinada") ou que não seja localizável via HTTP.

Se você estiver familiarizado com as operações do banco de dados, existem

1. Selecione
2. Inserir
3. Atualizar
4. Excluir
5. Mesclar (atualize se já existir, ou insira)

Eu uso PUTpara Mesclar e atualizo como operações e uso POSTpara Inserções.

Na prática, o POST funciona bem para criar recursos. A URL do recurso recém-criado deve ser retornada no cabeçalho de resposta do local. PUT deve ser usado para atualizar completamente um recurso. Por favor, entenda que essas são as práticas recomendadas ao projetar uma API RESTful. A especificação HTTP, como tal, não restringe o uso de PUT / POST com algumas restrições para criar / atualizar recursos. Dê uma olhada em http://techoctave.com/c7/posts/71-twitter-rest-api-dissected que resume as melhores práticas.