Você pode encontrar asserçõ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 O POST deve ser usado para modificar um

Melhor é escolher entre PUT e POST baseado em idempotência da acção.

Colocar implica colocando um recurso-completamente substituindo o que está disponível na URL dada por uma coisa diferente. Por definição, um PUT é idempotente. Fá-lo quantas vezes quiseres, e o resultado é o mesmo. {[2] } é idempotente. Você pode colocar um recurso se ele existe anteriormente, ou não (eg, para criar, ou para atualizar)!

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

Por este argumento, PUT é para criar quando você sabe a URL da coisa que você vai criar. POST pode ser usado para criar quando você sabe o URL da "fábrica" ou gerente para a categoria de coisas que você deseja criar.

Então:

POST /expense-report

Ou:

PUT  /expense-report/10929

• O POST num URL cria um recurso-filho num URL definido peloservidor .
• Coloque num URL cria / substitui o recurso na sua totalidade no URL definido pelo CLIENTE .
• Alterar para um URL actualizações Parte do recurso Naquele URL definido pelo cliente.

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

O POST cria uma criança o recurso , por isso o POST to /items cria um recurso que vive sob o recurso /items. Exemplo. /items/1. Enviar o mesmo pacote de post duas vezes irá criar dois recursos.

PUT é para criar ou substituir um recurso num URL conhecido pelo cliente.

Portanto: PUT é apenas um candidato para criar onde o cliente já conhece a url antes do recurso ser criado. Exemplo. /blogs/nigel/entry/when_to_use_post_vs_put como o título é usado como chave de recursos

Colocar substitui o recurso na url conhecida se já existir, por isso enviar a mesma solicitação duas vezes não tem efeito. Em outras palavras, chamadas para colocar São idempotentes .

A RFC diz o seguinte:

A diferença fundamental entre os pedidos POST e PUT reflecte-se no significado diferente do pedido-URI. O URI em uma solicitação POST identifica o recurso que irá lidar com a entidade inclusa. Esse recurso pode ser um processo de aceitação de dados, um gateway para algum outro protocolo, ou uma entidade separada que aceita anotações. Em contraste, o URI em um pedido PUT identifica a entidade anexada ao pedido -- o agente do usuário sabe o que URI é pretendido e o servidor não deve tentar aplicar o pedido a algum outro recurso. Se o servidor desejar que o pedido seja aplicado a um URI diferente,

Nota: PUT tem sido usado principalmente para actualizar os recursos (substituindo-os nas suas entidades), mas recentemente há movimento para usando o PATCH para atualizar os recursos existentes, como PUT especifica que ele substitui todo o recurso. RFC 5789.

Resumo:

Criar:

Pode ser realizado com PUT ou POST da seguinte forma:

Colocar

Cria o novo recurso com o newResourceIdcomo identificador, sob o /resources URI, ou colecção.

PUT /resources/<newResourceId> HTTP/1.1 

Depois

Cria umnovo recurso sob o /resources URI, ou colecção. Normalmente, o identificador é devolvido pelo servidor.

POST /resources HTTP/1.1

Actualização:

Pode apenas ser realizado com PUT da seguinte forma:

Colocar

Actualiza o recurso com existingResourceId como identificador, sob o / resources URI, ou collection .

PUT /resources/<existingResourceId> HTTP/1.1

Explicação:

Ao lidar com o descanso e URI como geral, você tem Genérico na esquerda e específico na direita. O Os genéricos são normalmente chamados colecções e os mais itens específicos podem ser chamados recursos. Note que um recurso pode conter uma colecção .

Exemplos:

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 usa o POST, está semprea referir-se a uma colecção , por isso, sempre que diz:

POST /users HTTP/1.1

Você está postando um novo usuário para o utilizadores colecção.

POST /users/john HTTP/1.1

Assim que estiver a usar o PUT, está a referir-se a um recurso ou a um único item, possivelmente dentro de uma colecção . Então, quando dizes:

PUT /users/john HTTP/1.1

Spec:

Depois

A POST método é usado para solicitar que o servidor de origem aceitar a entidade entre o pedido como um novo subordinada para o recurso identificado pela URI de Solicitação no Linha Do Pedido

Referência:

• HTTP / 1. 1 Spec
• Wikipedia-REST
• identificadores de recursos uniformes (URI): genéricos Sintaxe e semântica

Então: para salvar um utilizador existente, ou um onde o cliente gera o id e foi verificado que o id é único:

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 o POST para criar inicialmente o objecto, e coloque para actualizar o objecto:

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

POST significa "criar novo" como em "aqui está a entrada para criar um usuário, criá-lo para mim".

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

Envias para example.com/users como você ainda não sabe a URL do usuário, você quer que o servidor A crie.

Example.com/users/id dado que deseja substituir / criar um utilizador específico.

Publicar duas vezes com os mesmos dados significa criar dois utilizadores idênticos com identidades diferentes. PUTing duas vezes com os mesmos dados cria o usuário o primeiro e atualiza-o para o mesmo estado da segunda vez (sem alterações). Uma vez que você acaba com o mesmo estado após um PUT não importa quantas vezes você executá - lo, diz-se ser "igualmente potente" cada vez-idempotente. Isto é útil para refazer automaticamente os pedidos. Acabou-se o 'tem a certeza que quer reenviar' quando carregar no botão de trás do navegador.

Um conselho geral é usar o POST quando necessita de servidor para estar no controle da geração de URL de seus recursos. Use colocar de outra forma. Prefiro colocar em cima do poste.

Use POST para criar, e coloque para atualizar. É assim que a Ruby on Rails faz.

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

O descanso é um conceito de alto nível Muito. Na verdade, nem sequer menciona HTTP!

Se tiver alguma dúvida sobre como implementar o descanso em HTTP, poderá sempre dar uma vista de olhos à especificação do Protocolo de publicação Atom (AtomPub) . AtomPub é um padrão para escrever webservices RESTful com HTTP que foi desenvolvido por muitas luminárias HTTP e REST, com alguma entrada de Roy Fielding, O inventor do descanso e (co-)inventor do próprio HTTP.

Na verdade, você pode até ser capaz de usar AtomPub diretamente. Embora tenha saído da comunidade de blogs, não se restringe de forma alguma à blogagem: é um protocolo genérico para interagir de forma duradoura 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 apenas usar AtomPub e não se preocupar se deve usar PUT ou POST, quais códigos de estado HTTP para retornar e todos esses detalhes.

Para adicionar membros a uma colecção, os clientes enviam pedidos de correio para a URI da colecçã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. Ter o cliente a conhecer, ou participar na definição, a estrutura URL é um acoplamento desnecessário semelhante aos acoplamentos indesejáveis que surgiram da SOA. Escapar tipos de acoplamentos é a razão pelo qual o descanso é tão popular. Portanto, O método correcto a usar é o POST.Existem excepções a esta regra e ocorrem quando o cliente deseja manter o controlo sobre a estrutura de localização dos recursos que utiliza. Isso é raro e provavelmente significa que algo mais está errado.

Neste ponto algumas pessoas irão argumentar que se RESTful-URL ' s são usados, o cliente sabe a URL do recurso e, portanto, uma PUT é aceitável. Afinal de contas, é por isso que o canônico, normalizado, Ruby on Rails, Django URLs são importantes, olhe para a API do Twitter ... blah blah blah. Essas pessoas precisam de entender que isso não existe. como um URL repousante e que o próprio Roy Fielding afirma que:

Uma API de descanso não deve definir nomes de recursos fixos ou hierarquias (uma Acoplamento óbvio do cliente e do servidor). Os servidores devem ter a liberdade para controlar o seu próprio espaço de nomes. Em vez disso, permitir aos servidores instruir clientes sobre como construir URIs apropriados, como é feito em HTML formulários e modelos URI, definindo essas instruções no meio tipos e relações de ligação. (Falha aqui implica que os clientes são assumindo uma estrutura de recursos devido à informação fora de banda, como uma norma específica do domínio, que é o equivalente orientado para os dados Acoplamento funcional da RPC].

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

A ideia de um RESTful-URL é, na verdade, uma violação do descanso, uma vez que o servidor está encarregado da estrutura de URL e deve ser livre para decidir como usá-lo para evitar Acoplamento. Se isto confunde você ler sobre o significado da auto-descoberta no design da API.

Usar o POST para criar recursos vem com uma consideração de design porque o POST não é idempotente. Isto significa que repetir um POST várias vezes não garante o mesmo comportamento de cada vez. Isto assusta as pessoas a usarem PUT para criar recursos quando não devem. eles sabem que é errado (POST é para criar) mas eles fazem isso de qualquer maneira porque eles não sabem como resolver este problema. Presente a preocupação é demonstrada na seguinte situação:

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

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 este problema. Em vez disso, o HTTP pode ser usado como especificado em RFC 2616 e o servidor responde:

10. 4. 10 409 conflito

O pedido não pôde ser completado devido a um conflito com a actual estado do recurso. Este código só é permitido em situações em que: espera-se que o utilizador possa conflito e volte a apresentar o pedido. O organismo de resposta deve incluir

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

É mais provável que ocorram conflitos em resposta a um pedido de venda. Para por exemplo, se a versão estava a ser usada e a entidade a ser colocada alterações incluídas a um recurso que entra em conflito com aqueles feitos por um pedido anterior (de terceiros), o servidor pode usar a resposta 409 para indicar que não pode completar o pedido. Neste caso, o a entidade de resposta conteria provavelmente uma lista das diferenças entre as duas versões em um formato definido pelo tipo de conteúdo de resposta.

Responder com um código de estado de 409 conflito é o recurso correcto porque:

• a efectuar uma publicação de dados com identificação o que corresponde a um recurso já no sistema é "um conflito com o estado atual do recurso."
• uma vez que a parte importante é que o cliente compreenda que o servidor tem o recurso e tome as medidas adequadas. Esta é uma " situação(s) em que se espera que o usuário possa ser capaz de resolver o conflito e voltar a apresentar o pedido."
• uma resposta que contém o URL do recurso com o ID em conflito e as pré-Condições apropriadas para o recurso seria fornecer "informações suficientes para o usuário ou agente de usuário corrigir o problema", que é o caso ideal para a RFC 2616.

Actualização com base no lançamento do RFC 7231 para substituir 2616

O RFC 7231 foi concebido para substituir 2616 e o ponto 4.3.3 de descreve a seguinte resposta possível para uma pós

Se o resultado do processamento de um POST for equivalente a representação de um recurso existente, um servidor de origem pode redireccionar usuario agente para esse recurso, enviando uma resposta 303 (ver outra) com o identificador do recurso existente no campo de localização. Presente tem os benefícios de fornecer ao agente de Utilizador um identificador de recursos e transferindo a representação através de um método mais acessível para cache compartilhado, embora ao custo de um pedido extra se o usuário o agente ainda não tem a representação em cache.

Agora pode ser tentador simplesmente devolver um 303 no caso de um POST ser repetido. No entanto, o oposto é verdade. Retornar um 303 só faria sentido se múltiplos pedidos de criação (criando diferentes recursos) retornassem o mesmo conteúdo. Um exemplo seria um "obrigado por enviar sua mensagem de pedido" que o cliente não precisa re-baixar cada vez. O RFC 7231 ainda mantém na secção 4.2.2 que o POST não deve ser idempotente e continua a manter que o POST deve ser usado para criar.

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

Ambos são usados para a transmissão de dados entre cliente e servidor, mas existem diferenças subtis entre eles, que são:

Analogia:

• colocar isto é tomar e colocar onde estava.
• correio como envio de correio correio serviço.

Gosto deste conselho, da definição de PUT da RFC 2616.:

A diferença fundamental entre o POST e o PUT é refletida no significado diferente do pedido-URI. O URI em uma solicitação POST identifica o recurso que irá lidar com a entidade inclusa. Esse recurso pode ser um processo de aceitação de dados, um gateway para algum outro protocolo, ou uma entidade separada que aceita anotações. Em contrapartida, o URI num pedido PUT identifica a entidade junto com o pedido -- o agente de usuário sabe o que o URI pretende e o servidor não deve tentar aplicar o pedido a algum outro recurso.

Este jibes com o outro conselho aqui, que PUT é melhor aplicado a recursos que já têm um nome, e POST é bom para criar um novo objeto sob um recurso existente (e deixar o nome do servidor dele).

• O POST é bom para criar novos objectos sob uma colecção (e criar não precisa de ser idempotente)
• colocar é bom para actualizar os objectos existentes (e a actualização tem de ser idempotente)
• O POST também pode ser usado para actualizações não-idempotentes de objectos existentes (especialmente, mudar parte de um objecto sem especificar tudo -- se pensar nisso, criar um novo membro de uma colecção é na verdade um caso especial deste tipo de actualização, do ponto de vista da colecção)
• colocar também pode ser usado para criar se e somente se você permitir que o cliente nomeie o recurso. Mas como os clientes de descanso não são supostos fazer suposições sobre a estrutura de URL, isto é menos no espírito pretendido das coisas.

Resumindo:

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

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

Analogia com pesquisa na base de Dados

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

POST você pode pensar em algo como " inserir nos valores do estudante(nome, endereço) ("abc", "xyzz");

O ID do estudante é gerado automaticamente.

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

Em caso de POST, se a mesma consulta é executada várias vezes, então vários registros de estudantes são criados na base de dados e o estado da base de dados muda em cada execução de uma "inserir" consulta.

Nota: colocar precisa de uma localização de recursos (já-recurso) sobre a qual a atualização precisa acontecer, enquanto POST não requer isso. Portanto, intuitivamente POST é destinado para a criação de um novo recurso, enquanto PUT é necessário para atualizar o recurso já existente.

alguns podem vir com que atualizações podem ser realizadas com POST. Não há nenhuma regra difícil qual usar para atualizações ou qual usar para criar. Novamente estas são convenções, e intuitivamente eu sou inclinado com o raciocínio acima mencionado e segui-lo.

O correio é como enviar uma carta para uma caixa de correio ou enviar um e-mail para uma fila de E-mail. PUT é como quando você coloca um objeto em um cubby hole ou um lugar em uma prateleira (ele tem um endereço conhecido).

Com o POST, você está postando para o endereço da fila ou coleção. Com PUT, vais colocar na morada do ITEM.

Uma regra geral: se conhece a identificação ou o nome do item, use PUT. Se você quiser que o id ou o nome do item seja atribuído pela Parte receptora, use POST.

Nova resposta (agora que eu entendo descanse melhor):

COLOCAR é apenas uma declaração de qual o conteúdo que o serviço deve, a partir de agora, use para compor representações do recurso identificado pelo cliente; POST é uma declaração de qual o conteúdo que o serviço deve, a partir de agora, contêm (possivelmente duplicados) mas é para o servidor como para identificar o conteúdo.

PUT x (se x identificar um recurso ): "substituir o conteúdo do recurso identificado por x com o meu conteúdo."

PUT x (se x não identificar um recurso): "crie um novo recurso contendo o Meu Conteúdo e use x para o identificar."

POST x: "armazene meu conteúdo e me dê um identificador que eu possa usar para identificar um recurso (antigo ou novo) contendo esse conteúdo (possivelmente misturado com outro conteúdo). Esse recurso deve ser idêntico ou subordinado ao que x identifica.""o recurso de y é subordinado a x ' s recurso" é normalmente, mas não necessariamente implementadas, tornando y um subcaminho de x (e.g. x = /foo e y = /foo/bar) e modificando a representação do(s) x's de recursos para reflectir a existência de um novo recurso, por exemplo, com um hiperlink para y's de recursos e alguns metadados. Só este último é realmente essencial para um bom design, uma vez que os URLs são opacos em repouso -- é suposto que use a hypermedia em vez do URL do lado do cliente construção para atravessar o serviço de qualquer maneira.

Resposta Original (pode ser mais fácil para ler):

PUT /something (Se /something já existe: "toma o que tiveres em /something e substitui - o pelo que eu te der."

PUT /something (Se /something ainda não existe): "pega no que te dou e coloca-o em /something."

POST /something: "pega no que te dou e coloca-o onde quiseres, desde que me dês a sua URL quando acabares."

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

A RFC 5789 diz sobre PATCH (desde 1995):

É necessário um novo método para melhorar a interoperabilidade e evitar erro. O método PUT já está definido para substituir um recurso com um corpo completamente novo, e não pode ser reutilizado para fazer alterações parciais. Caso contrário, proxies e caches, e até mesmo clientes e servidores, podem obter confuso quanto ao resultado do operacao. A publicação já é usada, mas sem uma interoperabilidade alargada (para um, não existe uma forma normal de discover patch format support). O PATCH foi mencionado no HTTP anterior especificações, mas não completamente definidas.

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

Resposta Curta:

Regra de ouro simples: Use o POST para criar, use o PUT para actualizar.

Resposta Longa:

Após:

• O POST é usado para enviar dados para o 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:

Antes de colocar, os clientes não podiam saber directamente a URL que o servidor gerava ou se tudo o que tinha gerado ou se os dados a serem enviados para o servidor já estavam actualizados ou não. Colocar aliviado o criador de todas estas dores de cabeça. PUT is idempotent, PUT handles race conditions, and PUT lets the client choose the URL.

, Em que o risco de reafirmar o que já foi dito, parece importante lembrar que COLOCAR implica que o cliente controla o que o URL vai acabar sendo, ao criar um recurso. Assim, parte da escolha entre COLOCAR e POST vai ser sobre o quanto você pode confiar que o cliente fornecer o correto, normalizado URL que são coerentes com o que o seu esquema de URL é.

A consideração mais importante é fiabilidade. Se uma mensagem de POST se perde o estado do sistema é indefinido. A recuperação automática é impossível. Para colocar mensagens, o estado é indefinido apenas até a primeira repetição bem sucedida.

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

Se por acaso tiver URI gerado automaticamente no seu recurso, ainda poderá usar o PUT passando um URI gerado (apontando para um URI vazio recurso) para o cliente.

Algumas outras considerações:

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

Caso 2: Se o seu amigo comentar no seu post pela primeira vez, isso também irá criar uma nova entrada na base de dados, de modo que o método de POST usado.

Numa única linha, use O POST para adicionar um novo item na base de dados e Coloque em actualizar algo na base de dados.

Parece haver sempre alguma confusão quanto a quando usar o HTTP POST versus o HTTP PUT method for REST services. A maioria dos desenvolvedores tentará associar as operações CRUD diretamente aos métodos HTTP. Eu vou argumentar que isso não é correto e não se pode simplesmente associar os conceitos CRUD aos métodos HTTP. Isto é:

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

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

De acordo com as especificações HTTP 1.1, os métodos GET, HEAD, DELETE e PUT devem ser idempotentes, e o método POST não é idempotente. Ou seja, uma operação é idempotente se pode ser realizada em um recurso uma ou várias vezes e devolve sempre o mesmo estado desse recurso. Considerando que uma operação não idempotente pode retornar um estado modificado do recurso de um pedido para outro. Assim, em uma operação não idempotente, não há garantia de que alguém receberá o mesmo estado de um recurso.

Baseado na definição de idempotente acima, a minha opinião sobre o uso do método PUT HTTP versus o uso do método POST HTTP para os Serviços de descanso é: Use o método de PUT HTTP 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).

Em ambos os casos, estas operações podem ser realizado várias vezes com os mesmos resultados. Este é o recurso não será alterado solicitando a operação mais de uma vez. Daí, uma verdadeira operação idempotente. Usar 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 directamente e mapeie as operações CRUD com os métodos HTTP para os Serviços de repouso. O uso de um método PUT HTTP versus um método POST HTTP deve ser baseado no aspecto idempotente dessa operação. Isto é, se a operação é idempotente, então use o Método de PUT HTTP. Se a operação não é idempotente, então 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 colocar para a criação de recursos. Não tens de apoiar os dois. Para mim, o POST é perfeitamente suficiente. Então é uma decisão de design.

Como a sua citação mencionou, você usa PUT para a criação de que não há nenhum recurso atribuído a um IRI, e você quer criar um recurso de qualquer maneira. Por exemplo, PUT /users/123/password normalmente substitui a senha antiga por uma nova, mas pode usá-la para crie uma senha se ela não existir já (por exemplo, por usuários recém registrados ou restaurando usuários proibidos).

Os leitores novos a este tópico serão impressionados pela discussão interminável sobre o que você deve fazer, e a relativa ausência de lições da experiência. O fato de que o descanso é "preferido" sobre o sabão é, eu suponho, uma aprendizagem de alto nível com a experiência, mas a bondade nós devemos ter progredido a partir daí? Estamos em 2016. A dissertação de Roy foi em 2000. O que desenvolvemos? Foi divertido? Foi fácil de integrar? Para apoiar? Será que ele vai lidar com a ascensão de smartphones e flaky mobile ligações?

HTTP não faz nada para garantir a conclusão confiável da resposta ao pedido, e isso é muito bom, porque este é o trabalho adequado de aplicações de rede consciente. Desenvolvendo tal aplicação, você pode saltar através de aros para usar PUT em vez de POST, em seguida, mais aros para dar um certo tipo de erro no servidor Se você detectar pedidos duplicados. De volta ao cliente, você então tem que saltar através de aros para interpretar estes erros,, revalidar e repostar.

Ou você pode fazer isso: considere seus pedidos inseguros como recursos de usuário único Efêmeros (vamos chamá-los de ações). Os clientes solicitam uma nova "ação" sobre um recurso substantivo com um POST vazio para o recurso. POST será usado apenas para isso. Uma vez na posse segura do URI da acção recentemente cunhada, o cliente coloca o pedido inseguro à acção URI, não o recurso alvo. Resolver a acção e actualizar o recurso "real" é adequadamente o trabalho da sua API, e está aqui dissociado da rede não confiável.

O servidor faz o negócio, devolve a resposta e armazena-a contra a acção acordada URI. Se algo correr mal, o cliente repete o pedido (comportamento natural!), e se o servidor já o viu, ele repete a resposta armazenada e não faz mais nada .

Você vai rapidamente detectar a semelhança com as promessas: nós criamos e devolvemos o substituto para o resultado antes de fazer alguma coisa. Também como uma promessa, uma ação pode ter sucesso ou falhar uma vez, mas seu resultado pode ser obtido repetidamente.

Os sucessivos pedidos de eliminação podem ver e processar a confirmação original, sem atingir um erro de 404. Se as coisas demorarem mais do que o esperado, podemos responder provisoriamente, e temos um lugar onde o cliente pode verificar o resultado definitivo. A parte mais bonita deste padrão é a sua propriedade Kung-Fu (Panda). Tomamos uma fraqueza, a propensão dos clientes para repetir um pedido sempre que eles não entendem a resposta, e transformá-la em uma força :-)

Se você acha que vai ter grandes quantidades de dados para armazenar, vamos falar de volumes: uma confirmação de atualização típica é uma fração de um kilobyte. O HTTP atualmente lhe dá um minuto ou dois para responder definitivamente. Mesmo que você só armazene ações por uma semana, os clientes têm ampla chance de alcançar. Se você tem volumes muito altos, você pode querer um acid-compliant key value store, ou uma solução em memória.

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

POST é basicamente uma mensagem de forma livre, com o seu significado sendo definido 'fora da banda'. Se a mensagem pode ser interpretada como adicionando um recurso a um diretório, isso seria OK, mas basicamente você precisa entender a mensagem que você está enviando (postar) para saber o que vai acontecer com o recurso.

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

POST pode executar as outras três funções, mas então a semântica do pedido será perdida nos intermediários tais como caches e proxies. Isto também se aplica ao fornecimento de segurança no recurso, uma vez que o URI de um post não indica necessariamente o recurso que ele está aplicando (ele pode, porém).

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

Editar: mais uma coisa -- um PUT pode criar, mas se o fizer então o ID tem de ser um identificação natural, também conhecido como endereço de E-mail. Dessa forma, quando você colocar duas vezes, a segunda colocação é uma atualização da primeira. Isto torna-o idempotente.

Se o ID for gerado (um novo ID de empregado, por exemplo), então o segundo colocado com a mesma URL criaria um novo registo, o que viola a Regra do idempotente. Neste caso, o verbo seria POST, e a mensagem (Não recurso) seria criar um recurso usando os valores definidos nesta mensagem.

A semântica é suposto ser diferente, nesse "PUT", como "GET" é suposto ser idempotente -- o que significa, você pode exactamente o mesmo put pedido várias vezes e o resultado será como se você executasse apenas uma vez.

Quando você coloca um recurso em um determinado URL o que acontece é que ele deve ser salvo nesse URL, ou algo ao longo dessas linhas.

Quando você postar para um recurso em uma URL particular, muitas vezes você está postando uma parte relacionada de informação para essa URL. Isto implica que o recurso na URL já existe.

Por exemplo, quando você quer criar um novo fluxo, você pode colocá-lo em algum URL. Mas quando você quer postar uma mensagem para um fluxo existente, você postar para a sua URL.

Quanto a modificar as propriedades do fluxo, você pode fazer isso com PUT ou POST. Basicamente, use apenas " PUT " quando a operação é idempotente-caso contrário use POSTAR.

Note, No entanto, que nem todos os navegadores modernos suportam verbos HTTP para além do GET ou POST.

Na maior parte do tempo, vais usá - los assim:

• POST um recurso numa colecção
• colocar um recurso identificado pela colecção/: id

Por exemplo:

• após / itens
• colocar / itens / 1234

Em ambos os casos, o organismo de pedido contém os dados para o recurso a ser criado ou actualizado. Deve ser óbvio a partir dos nomes de rota que POST não é idempotent (se você chamá-lo 3 vezes ele irá criar 3 objetos), mas PUT é idempotente (se você chamá-lo 3 vezes o resultado é o mesmo). PUT é muitas vezes usado para a operação "upsert" (criar ou atualizar), mas você sempre pode retornar um erro 404 se você só quiser usá-lo para modificar.

Note que POST "cria" um novo elemento na coleção, e colocar "substitui" um elemento em uma dada URL, mas é uma prática muito comum usar PUT para modificações parciais, ou seja, usá-lo apenas para atualizar os recursos existentes e apenas modificar o campos incluídos no corpo (ignorando os outros campos). Isto está tecnicamente incorrecto, se quiser ser purista, PUT deverá substituir todo o recurso e deverá usar o PATCH para a actualização parcial. Pessoalmente, não me importo tanto quanto o comportamento é claro e consistente em todos os seus objectivos API.

Lembre-se, o descanso é um conjunto de Convenções e diretrizes para manter a sua API simples. Se você acabar com um trabalho complicado apenas para verificar a caixa "RESTfull", então você está derrotando o propósito;)

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

Claro que "pode" usar "POST" para actualizar, mas basta seguir o convenções estabelecidas para você com seu quadro dado. No meu caso é API. net / Web, então PUT é para atualização não há debate.

Espero que isto ajude qualquer programador da Microsoft que leia todos os comentários com as ligações do site Amazon e Sun/Java.

Se estiver familiarizado com as operações da base de dados, há

1. seleccionar
2. inserir
3. actualizar
4. apagar
5. juntar (actualizar se já existir, caso contrário inserir)

Eu uso PUT para juntar e actualizar operações semelhantes e uso POST para inserções.

Coloque num URL deve ser usado para actualizar ou criar o recurso que pode ser localizado nesse URL.

POST para um URL deve ser usado para atualizar ou criar um recurso que está localizado em algum outro URL ("subordinado"), ou não é localizável através de HTTP.

POST: Use - o para criar novos recursos. É como inserir (instrução SQL) com um ID Auto-aumentado. Na parte de resposta contém um novo Id gerado.

A publicação também é utilizada para actualizar um registo.

PUT: Use - o para criar um novo recurso, mas aqui eu sei a chave da identidade. É como inserir (instrução SQL) onde eu sei com antecedência a chave de identidade. Na parte da resposta, não envia nada.

PUT também é usado para actualizar um recurso