| HTTP方法 | 一般操作 | 幂等性 | 作用范围 |
备注 |
| GET | 读取 | 是 | ||
| DELETE | 删除 | 是 | ||
| PUT | 创建(更新) | 是 | 具体资源之上的（/articles/123） | |
| POST | 更新(创建) | 否 | 集合资源之上的（/articles） |
重复加载问题，用于删除操作的安全漏洞问题 |
|
PUT和POST的区别 |
简要之，POST 一般用于修改资源的部分定义，或者补充一些内容。PUT 请求必定发送的是资源的完整定义。 即使要使用 POST 和 PUT 来区分两种操作，也应该是 PUT 用于创建资源， POST 用于修改资源（并且可以只接受部分参数，其他参数stay intact）。 |
|||
google了一些中文的资料, 基本了解了幂等是怎么回事儿. 备忘一下.
PUT，DELETE操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同，DELETE也是一样。顺便说一句，因为GET操作是安全的，所以它自然也是幂等的。
POST操作既不是安全的，也不是幂等的，比如常见的POST重复加载问题：当我们多次发出同样的POST请求后，其结果是创建出了若干的资源。
安全和幂等的意义在于：当操作没有达到预期的目标时，我们可以不停的重试，而不会对资源产生副作用。从这个意义上说，POST操作往往是有害的，但很多时候我们还是不得不使用它。
还有一点需要注意的就是，创建操作可以使用POST，也可以使用PUT，区别在于POST是作用在一个集合资源之上的（/articles），而PUT操作是作用在一个具体资源之上的（/articles/123），再通俗点说，如果URL可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使用POST，比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是什么只能由服务端提供，这个时候就必须使用POST。
一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等操作对于代理和缓存来说具有“友好性”，因为幂等操作的额外执行不会对二者产生危害性后果（除了带宽浪费）。
PUT方法是幂等的，幂等性意味着对于一个成功执行的请求，不管其执行多少次，其结果都是一致的。也就是说，只要你愿意，你可以用PUT方法对 Hotel资源进行任意次更新，其结果都一样。如果两个PUT方法同时发生，那么只有其中之一会赢得最后的胜利并决定资源的最终状态。删除操作也是幂等的，如果一个PUT方法和DELETE方法同时发生，那么资源或者被更新，或者被删除，而不可能停留在某个中间状态。
如果你不确定是PUT还是DELETE被成功执行，并且没有得到状态码409 (Conflict)或者 417 (Expectation Failed)的话，那么就重新执行一遍。而不需要附加的可靠性协议来避免重复请求，因为通常重复的请求不会有任何影响。
上述描述对于POST方法就不适用了，因为POST方法不是幂等的，若要两次执行同一个POST请求那就要注意了。POST方法所缺失的幂等性就解释了为什么当你每次重新发送POST请求时浏览器总是弹出警告。POST方法用于创建资源，而不需要由客户端指定实例id
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()”函数就是一个幂等函数，“deleteFile()”函数就不是。“幂等”是HTTP Session和EJB失败转移中的一个重要概念。
当正在进行方法调用的时候失败了怎么办呢？答案是：处理过程中止，客户端看见错误消息提示(除非方法是幂等方法)。只有方法是幂等方法的情况，一些负载均衡器才能试图失败转移这些方法到别的实例。
幂等为何如此重要？因为客户端并不知道服务器何时失败的(在方法刚开始调用或者快要调用完成的时候)。如果是非幂等方法，则两次调用就会两次改变系统状态，系统就会处于不一致的状态。
在复杂应用中，不太可能把所有的方法都变成幂等方法。所以，只能通过失败转移减少错误，而不可能从根本上避免错误。
把应用程序设计为幂等的：幂等的的意思就是一个操做不会修改状态信息，并且每次操作的时候都返回同样的结果（换句话说就是：做多次和做一次的效果是一样的），通常，WEB请求，特别是 HTML forms 都被发送多次（当用户点击发送按纽两次，重载页面多次），导致多次HTTP请求。设计SERVLET和其他WEB对象为 幂等的，可以容忍多次请求。详细可以去参考设计模式“Synchronized Token ”和“Idempotent Receiver ”关于怎样设计幂等的的应用程序。