POST和PUT HTTP请求之间有什么区别？
他们似乎都在向身体内的服务器发送数据，那么是什么使他们与众不同呢？
HTTP PUT：
PUT把一个文件或资源放在一个特定的URI上，并且正好在那个URI上。 如果在该URI处已经有文件或资源，则PUT将replace该文件或资源。 如果没有文件或资源，PUT创build一个。 PUT是幂等的 ，但矛盾的是PUT响应不可caching。
PUT的HTTP 1.1 RFC位置
HTTP POST：
POST将数据发送到特定的URI，并期望该URI处的资源处理该请求。 此时，Web服务器可以确定如何处理指定资源上下文中的数据。 POST方法不是幂等的 ，但只要服务器设置了适当的Cache-Control和Expires头文件，POST响应就是可caching的。
官方HTTP RFC指定POST为：
- 诠释现有资源;
- 向公告栏，新闻组，邮件列表或类似的文章组发布信息;
- 向数据处理过程提供一组数据，例如提交表单的结果;
- 通过追加操作扩展数据库。
POST 1.1的HTTP 1.1 RFC位置
POST和PUT之间的区别：
RFC本身解释了核心差异：
POST和PUT请求之间的根本区别反映在Request-URI的不同含义中。 POST请求中的URI标识将处理封闭实体的资源。 该资源可能是数据接受过程，某个其他协议的入口，也可能是接受注释的单独实体。 相比之下，PUT请求中的URI标识了请求所包含的实体 – 用户代理知道哪个URI是预期的，服务器不能尝试将请求应用到其他资源。 如果服务器希望请求被应用到不同的URI，它必须发送301（永久移动）响应; 用户代理可以自行决定是否redirect请求。
使用正确的方法，无关的放在一边：
REST ROA和SOAP的一个好处是，当使用HTTP REST ROA时，它鼓励正确使用HTTP动词/方法。 所以举个例子，当你想在这个确切的位置创build一个资源时，你只能使用PUT。 而且你永远不会使用GET来创build或修改资源。
只有语义。
HTTP PUT应该接受请求的主体，然后将其存储在由URI标识的资源中。
HTTP POST更通用。 它应该在服务器上启动一个动作。 该操作可能是将请求主体存储在由URI标识的资源中，或者可能是一个不同的URI，或者可能是一个不同的操作。
PUT 就像file upload。 放入URI会影响该URI。 对URI的POST可能会有任何影响。
举例说明REST风格的资源：
带有大量书籍信息的“POST / books”可能会创build一本新书，并用识别该书的新URL（“/ books / 5”）进行响应。
“PUT / books / 5”将不得不创buildID为5的新书，或者用ID 5replace现有的书。
在非资源风格下，POST可以用于任何有副作用的东西。 另外一个区别是PUT应该是幂等的 – 对同一个URL的同一个数据的多个PUT应该没问题，多个POST可能会创build多个对象或者你的POST动作。
1）GET： – 当客户端在Web服务器上请求资源时使用。
2）HEAD：当客户端请求关于资源的一些信息，但不请求资源本身时使用。
3）POST：当客户端向服务器发送信息或数据时使用，例如，填写在线表格（即向Web服务器发送大量复杂的数据）。
4）PUT： – 当客户端在请求URL下发送replace文档或上传新文档到Web服务器时使用。
5）DELETE：当客户端试图从Web服务器中删除一个由请求URL标识的文档时使用。
6）TRACE：当客户端询问可用的代理服务器或者中间服务器改变请求来宣布自己时使用。
7）选项： – 当客户想要确定其他可用的方法来检索或处理Web服务器上的文档时使用。
8）CONNECT：当客户端想要与远程主机build立透明连接时使用，通常通过HTTP代理来实现SSLencryption通信（HTTPS）。
PUT的意思是把东西“上传”到某个特定的URI，或覆盖那个URI中已经存在的东西。
另一方面，POST是一种提交RELATED给定URI的数据的方法。
参考HTTP RFC
据我所知，PUT主要用于更新logging。
-
POST – 创build文档或任何其他资源
-
PUT – 更新创build的文档或任何其他资源。
但是要明确这个PUT通常是“取代”现有的logging，如果它存在，并创build，如果它不存在..
其他人已经发布了出色的答案，我只是想补充说，大多数语言，框架，和用例，你会处理POST很多，比PUT更频繁。 PUT，DELETE等基本上都是琐事问题。
根据RFC ，PUT和POST之间的区别在Request URI中。 由POST标识的URI定义了将处理POST请求的实体。 PUT请求中的URI包含请求中的实体。 所以， POST /v1/coffees/orders意味着创build一个新的资源并返回一个标识符来描述资源。 相比之下， PUT /v1/coffees/orders/1234意味着更新由“ 1234 ”标识的资源（如果存在） 否则，请创build一个新订单并使用orders/1234 URI来标识它。
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.
POST被认为是工厂types的方法。 你用它包含数据来创build你想要的，而另一端的任何东西都知道如何处理它。 PUT用于更新给定URL处的现有数据，或者在知道URI将会是什么并且它不存在的情况下创build新的东西（而不是POST将创build一些东西并返回一个URL如果需要的话）。
请参阅：http: //zacharyvoase.com/2009/07/03/http-post-put-diff/
最近，Web开发人员普遍认为POST是用来创build资源的，而PUT则用来更新/改变一个资源，这让我非常恼火。
如果你看RFC 2616（“超文本传输协议-HTTP / 1.1”） 第9.6节 （“PUT”）的第55页，你将会看到PUT实际上是什么：
PUT方法要求封闭的实体存储在提供的Request-URI下。
还有一个方便的段落来解释POST和PUT之间的区别：
POST和PUT请求之间的根本区别反映在Request-URI的不同含义中。 POST请求中的URI标识将处理封闭实体的资源。 该资源可能是数据接受过程，某个其他协议的入口，也可能是接受注释的单独实体。 相比之下，PUT请求中的URI标识了请求中包含的实体 – 用户代理知道哪个URI是预期的，服务器不能尝试将请求应用到其他资源。
它没有提到更新/创build之间的区别，因为这不是它的意思。 这是关于这个区别的：
obj.set_attribute(value) # A POST request.
和这个：
obj.attribute = value # A PUT request.
所以，请停止这种stream行的误解的蔓延。 阅读您的RFC。
REST要求开发人员明确地使用HTTP方法，并以符合协议定义的方式使用HTTP方法。 这个基本的RESTdevise原则build立了创build，读取，更新和删除（CRUD）操作与HTTP方法之间的一对一映射。 根据这个映射：
•要在服务器上创build资源，请使用POST。
•要检索资源，请使用GET。
•要更改资源的状态或更新资源，请使用PUT。
•要删除或删除资源，请使用DELETE。
更多信息： RESTful Web服务：IBM的基础知识
