RESTFUL API 中的那些事

POST vs PUT

HTTP的POST/PUT方法经常会被弄混，因为这两个方法似乎都可以用来创建或更新一个资源。

但是它们之前的区别是很清楚的：

POST方法用来创建一个子资源，如 /api/users，会在users下面创建一个user，如users/1

POST方法是非幂等的，多次执行，将导致多条相同的资源被创建，如

（users/1，users/2 … 而这些用户除了自增长Id外有着完全相同的数据，除非你的系统实现了额外的数据唯一性检查）

而PUT方法用来创建一个URI已知的资源，或对已知资源进行完全替换，比如users/1，

因此除非在创建前你完全知道自己要创建的对象的URI，否则PUT方法无法更新一个已知资源。

PATCH vs PUT

PATCH方法是新引入的方法，该方法是对PUT方法的补充，用来对已知资源进行局部更新。

PATCH操作主要用来更新部分资源，而且其是非幂等的。（所谓的幂等就是每次更新后，结果不变）

PUT操作主要用来更新全部的资源，而且其是幂等的。

那么PATCH操作的优势是什么呢？因为PATCH操作是用来更新部分资源，所以可以节省网络带宽。

当然，PATCH操作也有其缺点，那就是PATCH操作是非幂等的，也是不安全的。（当执行PATCH操作时，如果资源不存在，则会创建资源而PUT不会）

因此实现PATCH操作语义的应用必须保证当前的PATCH操作是最小粒度，即它的原子性。

在HTTP常用的几个动词里, HEAD, GET, PUT, DELETE 都是安全的,幂等的。 因为对同一资源的任意多次请求, 永远代表同一个语义。

所以任何时候客户端发出去这些动词的时候, 如果服务器没有响应, 或者返回错误代码, 客户端都可以非常安全的再次执行同一操作而不用担心重复操作带来不同的语义及最终结果。

POST, PATCH操作就不是安全的, 因为当客户端向服务器端发出请求后, 服务器没有响应或者返回错误代码, 客户端是不能安全的重复执行操作的。

一定在重新与服务器确认了现在的资源状态下，才能决定下一步的操作。