De acordo com o HTTP/1.1 Spec:
O método **
POST
*** é utilizado para solicitar que o servidor de origem aceite a entidade incluída no pedido como um novo subordinado do recurso identificado pelo "Request-URI" no "Request-Line".
Em outras palavras, POST
é usado para **criar***.
O método **
PUT
*** solicita que a entidade incluída seja armazenada sob o "Request-URI" fornecido. Se oRequest-URI
refere-se a um recurso já existente, a entidade em anexo DEVERÁ ser considerada como uma versão modificada da que reside no servidor de origem. Se oRequest-URI
não apontar para um recurso existente, e que o URI é capaz de ser definido como um novo recurso pelo agente usuário solicitante, o servidor de origem pode criar o recurso com esse URI."
Ou seja, PUT
é usado para **criar ou atualizar***.
Então, qual deles deve ser usado para criar um recurso? Ou é preciso apoiar ambos?
Overtudo:
Tanto o PUT como o POST podem ser usados para criar.
Você tem que perguntar "para que você está executando a ação?" para distinguir o que você deveria estar usando. Vamos assumir que você está desenhando um API para fazer perguntas. Se você quiser usar o POST então você faria isso para uma lista de perguntas. Se você quiser usar PUT então você faria isso para uma pergunta em particular.
Grandes ambos podem ser usados, portanto qual deles devo usar no meu desenho RESTful:
Você não precisa apoiar tanto o PUT como o POST.
O que é usado é deixado a seu critério. Mas lembre-se apenas de usar o direito, dependendo do objeto que você está referenciando no pedido.
Algumas considerações:
Um exemplo:
Eu escrevi o seguinte como parte de outra resposta em SO sobre isso:
POST:
Utilizado para modificar e atualizar um recurso
PÓS /Perguntas/&questões_existentes> HTTP/1.1 Host: www.example.com/
Note que o seguinte é um erro:
PÓS /Perguntas/
HTTP/1.1 Anfitrião: www.example.com/ Se a URL ainda não tiver sido criada, você não deve estar usando o POST para criá-lo enquanto especifica o nome. Isto deve resultar num erro 'recurso não encontrado'. porque
<new_question>
não existe ainda. Você deve PUT a<new_question>
. recurso no servidor primeiro.Você poderia fazer algo como isto para criar um recurso usando o POST:
PÓS / perguntas HTTP/1.1 Anfitrião: www.example.com/
Note que, neste caso, o recurso nome não é especificado, os novos objetos O caminho URL seria devolvido a você.
PUT:
Usado para criar um recurso, ou sobregravá-la. Enquanto você especifica o recursos novo URL.
Para um novo recurso:
PUT /questions/
HTTP/1.1 Anfitrião: www.example.com/ Para sobregravar um recurso existente:
PUT /questions/
HTTP/1.1 Host: www.example.com/
Use POST para criar, e PUT para atualizar. É assim que o Ruby on Rails está fazendo, de qualquer forma.
PUT /items/1 #=> update
POST /items #=> create
REST é um conceito muito de alto nível. Na verdade, ele nem sequer menciona HTTP!
Se você tem alguma dúvida sobre como implementar o REST no HTTP, você pode sempre dar uma olhada na especificação [Atom Publication Protocol (AtomPub)][1]. AtomPub é um padrão para escrever serviços web RESTful com HTTP que foi desenvolvido por muitas luminárias HTTP e REST, com algumas contribuições de Roy Fielding, o inventor do REST e (co-)inventor do próprio HTTP.
Na verdade, você pode até ser capaz de usar o AtomPub diretamente. Embora tenha saído da comunidade de blogs, ele não é de forma alguma restrito a blogs: é um protocolo genérico para REST interagindo com coleções arbitrárias (aninhadas) de recursos arbitrários via HTTP. Se você pode representar sua aplicação como uma coleção aninhada de recursos, então você pode simplesmente usar AtomPub e não se preocupar se deve usar PUT ou POST, quais Códigos de Status HTTP a retornar e todos esses detalhes.
Isto é o que o AtomPub tem a dizer sobre a criação de recursos (seção 9.2):
Para adicionar membros a uma Coleção, os clientes enviam pedidos POST para a URI da Coleção.