PUT 还是 POST ?
http://www.oschina.net/translate/put-or-post
http://my.oschina.net/u/1263964/blog/268932
这两个方法咋一看都可以更新资源，但是有本质区别的
具体定义可以百度，我这里就不贴了，光说我自己的理解
首先解释幂等，幂等是数学的一个用语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的
对于两个参数，如果传入值相等，结果也等于每个传入值，则称其为幂等的，如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个要淘汰的就是阻碍生产力发展的落后生产关系……
=================================
By 灵魂码者 at 2013-05-20 08:15
表征状态转移（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。
目前在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。
应该是，做WEB服务，都必须掌握REST哦~~
Rest模式有四种操作，
-
POST /uri 创建
-
DELETE /uri/xxx 删除
-
PUT /uri/xxx 更新或创建
-
GET /uri/xxx 查看
GET操作是安全的。所谓安全是指不管进行多少次操作，资源的状态都不会改变。比如我用GET浏览文章，不管浏览多少次，那篇文章还在那，没有变化。当然，你可能说每浏览一次文章，文章的浏览数就加一，这不也改变了资源的状态么？这并不矛盾，因为这个改变不是GET操作引起的，而是用户自己设定的服务端逻辑造成的。
PUT，DELETE操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同，DELETE也是一样。顺便说一句，因为GET操作是安全的，所以它自然也是幂等的。
POST操作既不是安全的，也不是幂等的，比如常见的POST重复加载问题：当我们多次发出同样的POST请求后，其结果是创建出了若干的资源。
安全和幂等的意义在于：当操作没有达到预期的目标时，我们可以不停的重试，而不会对资源产生副作用。从这个意义上说，POST操作往往是有害的，但很多时候我们还是不得不使用它。
还有一点需要注意的就是，创建操作可以使用POST，也可以使用PUT，区别在于POST 是作用在一个集合资源之上的（/uri），而PUT操作是作用在一个具体资源之上的（/uri/xxx），再通俗点说，如果URL可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使用POST，比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是什么只能由服务端提供，这个时候就必须使用POST。
关于GET POST 的混淆
先说相同点，只有了解了相同点之后才能理解为什么会发生混淆。两者都能向服务器发送数据，提交的“内容”[注1]的格式相同，都是var_1=value_1&var_2=value_2&....get 和 post 区别如字面，一个是get（获取），一个是post（发送）。get用来告诉服务器需要获取哪些内容（uri+query），向静态页面（uri）请求则直接返回文件内容给浏览器，向一个动态页面请求时可以提供查询参数（query）以获得相应内容。post用来向服务器提交内容，主要是为了提交，而不是为了请求内容，就是说post的初衷并不要求服务器返回内容[注2]，只是提交内容让服务器处理（主要是存储或者处理之后再存储）。get和post出现混淆是因为对提交的数据处理方法的滥用造成的，数据是无辜的。
混淆之一： 将get提交的用来查询的字段当作是存储数据存入了服务器端文件或者数据库。然后就误以为get是用来提交用于存储的数据的。
混淆之二： 编写脚本在服务器端通过处理post提交的数据并返回内容。只要有数据，就能用来进行判断，脚本怎写是程序员的事，而不在乎数据来源的形式（post、get，或者是自己预设值的常量）。这点功能上确实没问题，只是背离的其初始目的而已。
由于都是要传送数据，且数据格式相同（即使数据格式不同，只要能提取出相应数据）。使用的时候难免出现张冠李戴，将get数据用来存储、将post数据用来检索返回数据。但是二者还是有区别的（主要是根据其用途而“人为”[注3]造成的），get的长度限制在2048字节（由浏览器和服务器限制的，这是目前IE的数据，曾经是1024字节），很大程度上限制了get用来传递“存储数据”的数据的能力，所以还是老老实实用来做检索吧；post则无此限制（只是HTTP协议规范没有进行大小限制，但受限于服务器的处理能力），因此对于大的数据（一般来说需要存储的数据可能会比较大，比2048字节大）的传递有天然的优势，谁让它是 nature born post 呢。
get提交的数据是放在url里，目的是灵活的向服务其提交检索请求，可以在地址栏随时修改数据以变更需要获取的内容，比如直接修改分页的编号就跳到另外一个分页了（当然也可能是 404）。post提交的数据放在http请求的正文里，目的在于提交数据并用于服务器端的存储，而不允许用户过多的更改相应数据（主要是相对于在url 修改要麻烦很多，url的修改只要点击地址栏输入字符就可以了），除非是专门跑来编辑数据的。
花边：post和get的安全性在传输的层面上区别不大，但是采用url提交数据的get方式容易被人肉眼看到，或者出现在历史纪录里，还是可能被肉眼看到，都是一些本地的问题。
-
注1：我强调的是内容，至于http协议中的get和post的格式大家有兴趣就自己看看吧。
-
注2：get方式主要是为了获得预期内容，即uri+query相同时所得到的内容应该是相同的。而post主要是提交内容，至于是否有必要返回页面可能只是出于用户体验，比如注册时返回你的注册id，但是如果只是返回一个“您已注册成功”的相同页面（即使你post的数据不一样）也没什么好奇怪的。
-
注3：关于这个“人为”，不是那么贴切，get和post还是有技术层面的区别的。但是从表象上看暂且这么说吧，毕竟二者的混淆也是“人为”的。
======================
http://www.restapitutorial.com/lessons/httpmethods.html
Using HTTP Methods for RESTful Services
The HTTP verbs comprise a major portion of our “uniform interface” constraint and provide us the action counterpart to the noun-based resource. The primary or most-commonly-used HTTP verbs (or methods, as they are properly called) are POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations, respectively. There are a number of other verbs, too, but are utilized less frequently. Of those less-frequent methods, OPTIONS and HEAD are used more often than others.
Below is a table summarizing recommended return values of the primary HTTP methods in combination with the resource URIs:
| HTTP Verb | CRUD | Entire Collection (e.g. /customers) | Specific Item (e.g. /customers/{id}) |
|---|---|---|---|
| POST | Create | 201 (Created), 'Location' header with link to /customers/{id} containing new ID. | 404 (Not Found), 409 (Conflict) if resource already exists.. |
| GET | Read | 200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists. | 200 (OK), single customer. 404 (Not Found), if ID not found or invalid. |
| PUT | Update/Replace | 404 (Not Found), unless you want to update/replace every resource in the entire collection. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. |
| PATCH | Update/Modify | 404 (Not Found), unless you want to modify the collection itself. | 200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. |
| DELETE | Delete | 404 (Not Found), unless you want to delete the whole collection—not often desirable. | 200 (OK). 404 (Not Found), if ID not found or invalid. |
Below is a more-detailed discussion of the main HTTP methods. Click on a tab for more information about the desired HTTP method.
The POST verb is most-often utilized to **create** new resources. In particular, it's used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. In other words, when creating a new resource, POST to the parent and the service takes care of associating the new resource with the parent, assigning an ID (new resource URI), etc.
On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.
POST is neither safe nor idempotent. It is therefore recommended for non-idempotent resource requests. Making two identical POST requests will most-likely result in two resources containing the same information.
Examples:
- POST http://www.example.com/customers
- POST http://www.example.com/customers/12345/orders
