对着rfc2616来看restful api中post和put的
当需要使我们的api更restful化的时候，我们得选择http的动词作为资源的crud动作，其中 Read -> Get ， Delete -> Delele 这两个没什么争议， 而 Create 和 Update 对应 Post 还是 Put ？
先给出正确的对应关系： Create -> Post , Update -> Put ， 再接着对着 rfc2616 来解释为什么
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
POST 方法用来请求源服务器接收附于请求中的实体，把它为作为请求行中 URI 所标识的资源的从属。 POST 被设计来作为统一的方法以覆盖以下几种功能：
Annotation of existing resources;
对已有资源的注解
Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
提交消息到布告板，新闻组，邮件列表或类似的论文组中
Providing a block of data, such as the result of submitting a form, to a data-handling process;
提交一段数据，比如表单提交中的数据，到数据处理程序
Extending a database through an append operation.
通过新增操作库充数据库（个人理解为 增加记录）
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
POST 方法的实际效果由服务器决定，而且通常也依赖于请求的URI。 被提交的实体从属于 URI 的方式就像文件从属于包含它的目录（文件夹）一样。比如，一条新闻从属于它发布的新闻组，一条记录属于一个数据库。
The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.
POST 方法执行的结果可能并不能由 URI 所标识。 这样的话，200（OK) 或 204 （No Content）都是合适的响应码，这依赖于相应是否包含描述结果的实体。
大白话 Post
先看看 post 的英文注释：
有道词典中，post作为及物动词时候的意思是 张贴、公布，比如在布告栏上张贴一个告示，目标是公告栏，公告栏可以贴好多个告示，一个告示是公告栏的一部分。
再看rfc2616中对post语义的描述，我们就有个印象 post 其实是“部分提交”（注意原文中的 subordinate 这个词），目标uri应该是一个资源组，如 向
订单列表 supermall.holysu.com/customer/{userid}/orders 提交一个订单， post的数据为 orders 中的一个order ； 或者上面几种情况中的第一条，post 提交的是uri所标识资源的注释；然后再根据语义想想我们平时更新数据的时候向 orders/{id} 提交数据就有点奇怪了吧 总而言之，post 向目标uri提交的是这个uri资源的附属资源，可以是注释、一个成员、一条记录或者其一部分。
然而大多数人平时开发并没有遵守http的谓词语义，就比如我个人之前做接口开发的时候，所有请求不管是查询、新增、修改还是删除都是通过post来发送参数的
// request
{
param1:xx,
param2:xx,
}
// response
{
code: 1,
msg: "success",
data:{}
}
之前只是考虑是方式统一，但是这一点都不restful。对前端接口本身是前后端的一个协议，而我们通过http进行交互的话，如果遵守http协议定义的语义的话，就能享受到更多的便利，如http条件缓存、减少歧义、降低沟通难度、方便接入 etc。不同的标准越少不就更利于沟通协作么，不然那个什么 DDD （最近突然很火）中倡导的领域统一语言就不会那么重要了。
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-*(e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
put 方法请求将实体存储在请求的uri中。如果请求uri 指向已存在的资源，则应该考虑将请求实体作为服务端那份已有资源的修改版本；如果请求 uri 并没有指向一个已有资源，并且这个 uri 可以被发出请求的用户代理定义为一个新的资源，那么源服务器就能用这个 uri 创建新的资源。 如果一个新资源创建好了，源服务器必须以 201（Created）的响应码来告知用户代理（浏览器）。如果已存在资源被修改了，发送响应码 200（OK）或 204（No Content）来表示请求已完成。如果请求 uri 标识的资源不能创建或不能修改，需要给出合适的错误相应来反应问题的原因。请求实体的接受方不能忽视任何 Content-*（比如 Content-Range）这样他不识别或没实现的请求头，这种情况必须返回 501（Not Implemented）。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
如果请求通过缓存，并且请求uri识别到1个多个缓存实体，那些实体应该视为过时的。对put方法的响应不能缓存。
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
POST 和 PUT 请求的基本区别反应在请求uri的含义上。在 POST 请求中 URI 标识的是处理请求实体的资源。这个资源可能是数据处理程序，针对其他协议的网关，或者一个接收注解的单独的实体。相反，PUT 请求中的 URI 标识的就是请求实体，用户代理（浏览器）知道 URI 所指向的是什么，而且服务端不能试图将请求应用到其他资源上。如果服务端想要将请求应用到一个不同的 URI 上，它必须发送 301（Moved Permanently）响应；接着浏览器可以自己决定是否重定向这个请求。
大白话 put
put，及物动词的含义是 “放”，那么这个动作的目标，放在哪里，是确定的；
举个例子，新建和更新客户信息
场景一，新建：用put来做的话就是往 xxx/customer/{id} 这uri上放一个新的客户，而这个 id 应该是服务端不存在的、新的； 成功应该返回 201(Created)
场景二，更新： 更新客户id为1的客户信息，向 xxx/customer/1 put 数据
{
"name": "holysu",
"post": "awesome coder"
}
服务端存在这个uri标识的资源并且修改成功的话返回 200(ok) ，如果不存在这个客户则返回 204(No Content)
而由于资源的唯一标识是由服务端生成的，比如订单id一般是服务端通过一定的业务规则生成的，所以在创建订单我们会选择以向 supermall.holysu.com/customer/{userid}/orders 这个uri post一个订单数据的方式来创建， 这就是为啥文章开始说 Create 对应的是 Post了。
个人的理解路径是： 英文单词的含义思考这两个动词的含义 -> rfc的定义（uri的含义） -> 实际使用场景 crud 的对应关系
