.NET CORE WEB API入门day2 Rest风格

Web API的两种开发风格

面向过程的（简称RPC）、面向REST的（简称REST）。

面向过程（RPC）

在RPC风格的WebAPI中，我们通过“控制器／操作方法”的形式把服务器端的代码当成方法去调用。这样的接口只是把HTTP当成一个传输数据的通道，而不关心HTTP谓词的语义、状态码。比如：/Persons/GetAll、/Persons/GetById?id=8、/Persons/Update、/Persons/DeleteById/8；

REST

1. REST：按照HTTP的语义来使用HTTP协议：
2. URL用于资源的定位：/user/888、/user/888/orders；
3. HTTP谓词：GET、POST（新增）、PUT（整体更新）、DELETE、PATCH（局部更新）等；
4. （一次性跟新全部数据用PUT，更新全部数据里面2个时候用PATCH）
5. 幂等：对于一个接口采用同样的参数请求一次和请求多次的结果是一致的，不会因为多次请求而产生副作用。由于网络环境存在不稳定性，当遇到网络故障导致请求失败时，如果接口是幂等的，系统就可以向接口重新发送请求，而不用担心重复发送请求带来副作用。
6. DELETE、PUT、GET是幂等的，POST不幂等；
7. GET请求的响应是可以被缓存的，而DELETE、PUT、POST请求的响应是不可以被缓存的。客户端、网关等可以根据情况对GET请求的响应进行缓存，从而提升性能
8. 在HTTP中，服务器端要通过状态码来反映资源获取的结果:404、403(没有权限)、201(新增成功)。

幂等性代码介绍：

List list;
list.Add(3);//不是幂等
Dictionary dict;
dict["a"] = "b";//是幂等

REST的优点：

1. 通过URL对资源定位,语义更清晰;
2. 通过HTTP谓词表示不同的操作，接口统一且具有自描述性，减少了开发人员对接口文档的依赖性。
3. 可以对GET、PUT、 DELETE请求进行重试;
4. 可以用GET请求做缓存。网关、网络请求组件等可以对失败的请求自动重试。
5. 通过HTTP状态码反映服务器端的处理结果统一错误处理机制。
6. 网关等可以分析请求处理结果。比如可以根据HTTP状态码分析有多少成功的请求，有多少失败的请求。

REST的缺点：

1. 真实系统资源复杂，很难清晰划分，对业务技术水平要求高；Restful 风格对设计人员的IT技能和业务知识的水平要求都非常高。
2. 不是所有操作都能简单的对应到确定的HTTP谓词操作；
3. 系统的进化可能改变幂等性；一个操作本来是幂等的，但是经过后来代码的更迭，可能操作会变得不幂等，这样就很可能报错
4. 通过URL进行资源定位不符合中文用户习惯；
5. HTTP状态码个数有限；有些复杂的情况，仅通过状态码无法描述
6. 有的环节会篡改非200（成功）响应码的相应码的相应报文、比如往404里面加广告
7. 有的客户端不支持PUT/DELETE请求。比如旧版本的支付宝小程序、一些旧版浏览器等就不支持PUT、DELETE请求。