1、PUT: 把消息本体中的消息发送到一个URL,跟POST类似，但不常用。
简单地说：通常用于向服务器发送请求，如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。
-----PUT请求那些封装在Request-URI的实体。如果Request-URI引用一个已存在的资源，则该封装实体应该作为原始服务器上的修改版本。如果Request-URI不是指向一个已存在的资源，并且该URI可被请求的用户代码定义为新资源，则原始服务器可用此URI创建新的资源。如果新的资源被创建，这个原始服务器就必须通过201（Created）响应通知用户代理。如果已有资源被修改，则发送200或者204响应，表示成功完成了该请求。如果Request-URI既没有创建也没有修改资源，则应给予适当的错误响应来反映问题本质。实体的接受者不能忽略任何不理解或没有实现的Content-*（如Content-Range）头部，并且必须返回501响应。
如果请求经过缓存，并且Request-URI标识出一个或多个当前缓存的实体，则那些实体视为过期了。该方法的响应不会被缓存。
2、POST和PUT的请求根本区别
POST请求的URI表示处理该封闭实体的资源，该资源可能是个数据接收过程、某种协议的网关、或者接收注解的独立实体。然而，PUT请求中的URI表示请求中封闭的实体-用户代理知道URI的目标，并且服务器无法将请求应用到其他资源。如果服务器希望该请求应用到另一个URI，就必须发送一个301响应；用户代理可通过自己的判断来决定是否转发该请求。
HTTP/1.1没有定义一个PUT请求如何影响原始服务器的状态。
PUT请求必须遵守信息传输要求。
除非另有说明，PUT请求中的实体头部应该用于PUT创建或修改的资源上。
POST是用来提交数据的。提交的数据放在HTTP请求的正文里，目的在于提交数据并用于服务器端的存储，而不允许用户过多的更改相应数据（主要是相对于在url 修改要麻烦很多)。
PUT操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同
POST操作既不是安全的，也不是幂等的，比如常见的POST重复加载问题：当我们多次发出同样的POST请求后，其结果是创建出了若干的资源。
安全和幂等的意义在于：当操作没有达到预期的目标时，我们可以不停的重试，而不会对资源产生副作用。从这个意义上说，POST操作往往是有害的，但很多时候我们还是不得不使用它。
还有一点需要注意的就是，创建操作可以使用POST，也可以使用PUT，区别在于POST 是作用在一个集合资源之上的（/articles），而PUT操作是作用在一个具体资源之上的（/articles/123），再通俗点说，如果URL可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使用POST，比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是什么只能由服务端提供，这个时候就必须使用POST。
