REST中 @POST & @PUT 区别

首先解释幂等，幂等是数学的一个用语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的。对于两个参数，如果传入值相等，结果也等于每个传入值，则称其为幂等的，如min(a,b)。

POST

用于提交请求，可以更新或者创建资源，是非幂等的

举个例子，在我们的支付系统中，一个api的功能是创建收款金额二维码，它和金额相关，每个用户可以有多个二维码，如果连续调用则会创建新的二维码，这个时候就用POST

PUT

用于向指定的URI传送更新资源，是幂等的

还是那个例子，用户的账户二维码只和用户关联，而且是一一对应的关系，此时这个api就可以用PUT，因为每次调用它，都将刷新用户账户二维码

比如一个接口用于用户生成，接收的数据是用户名、密码等相关信息，则用POST

RESTful建议所有的URI都是对应资源，所以创建用户不应该理解为一个行为，在此将此接口命名为:/user/creation，每次调用它都会新建一个用户（假定用户名可以重复），而PUT方法更加关心一个具体资源对应的URI，比如更新当前用户信息，这里可以用PUT，/user/me/update这里用me来指代当前用户，如果是针对更多用户适用的接口，可以考虑

/user/{uid}/update注意多次调用同一接口，只要提交的数据一致，用户信息每次结果就会一致，即产生同样的结果：服务器端某个具体的资源得到了更新当需要以更新的形式来修改某一具体资源的时候，如何判断用PUT还是POST呢？很简单，如果该更新对应的URI多次调用的结果一致，则PUT，比如更新某个blog文章，因为该文章具有单一的具体URI，所以每次更新提交相同的内容，结果都一致，/blog/{document_id}/update在每次更新提交相同的内容，最终的结果不一致的时候，用POST举个很常见的例子，一个接口的功能是将当前余额减一个值，每次提交指定该值为100，接口如/amount/deduction，调用一次，你的余额-100，调用两次，余额-200，这个时候就用POST

RESTful的4种层次

Representational status transfer

个人理解为：表现形式的状态传递

1、只有一个接口交换xml来实现整个服务

目前我们的移动站点的服务就是类似的结构，我们有两个URI接口/mapp/lead和/msdk/safepay

2、每一个资源对应一个具体的URI，比1好维护，但是问题依然很明显，资源版本更新会引入时间戳维护，资源的获取和更新修改必须对应不同的URI

目前PC主站和移动站点的静态内容（包括html文件）都是这种形式

3、在2的基础上使用了http verb，每个URI可以有不同的动作，充分利用了http协议，所以自然居然http协议的完整优势，比如缓存和健壮性

HTML4.0只支持POST和GET，所以无论DELETE还是PUT操作，都用POST去模拟了

在WEB开发者看来，就是如果有数据变动，就用POST，如果没有，就用GET

所以目前中国用户来看，PC端实现RESTful很困难，只有移动端支持Html5的浏览器，才能让前端做出尝试

4、现在似乎更加无法实际应用，Hypemedia control，也就是RESTful的本意，合理的架构原理和以网络为基础的设计相结合，带来一个更加方便、功能强大的通信架构

这就有点虚无缥缈了，不过是一个努力的方向，想想看，以后要缴水费了，打开浏览器，输入我要缴水费，就自动定位+自动下单+自动付款+自动展示结果，完成整个缴水费的过程，这是多么方便的领悟！gwy要失业了有木有，那帮吃白饭做很简单的事情的，生产力发展第1个要淘汰的就是阻碍生产力发展的落后生产关系……

举一个简单的例子，假如有一个博客系统提供一个Web API，模式是这样http://superblogging/blogs/post/{blog-name}，很简单，将{blog-name}替换为我们的blog名字，往这个URI发送一个HTTP PUT或者POST请求，HTTP的body部分就是博文，这是一个很简单的REST API例子。我们应该用PUT方法还是POST方法？取决于这个REST服务的行为是否是idempotent的，假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？如果产生了两个博客帖子，那就说明这个服务不是idempotent的，因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。前一种情况，应该使用POST方法，后一种情况，应该使用PUT方法。