Web Api的两种风格，实战的建议 / 附：ABP中的处理

1.面向过程

RPC：“控制器/操作方法“的形式把服务器端的代码当成方法去调用。把HTTP当成传输数据的通道，不关心HTTP谓词。通过QueryString、请求报文体给服务器传递数据。状态码。比如：/Persons/GetAll、/Persons/GetById?id=8、/Persons/Update、/Persons/DeleteById/8；

2.面向REST

按照HTTP的语义来使用HTTP协议：

URL用于资源的定位：/user/888、/user/888/orders；

HTTP谓词：GET、POST（新增）、PUT（整体更新）、DELETE、PATCH（局部更新）等；

（啥时候用put？一次性跟新十个数据，啥时候用patch，更新十个数据里面2个时候）

什么是“幂等”，举例？DELETE、PUT、GET是幂等的，POST不幂等；

GET的响应可以被缓存；

5、

1、完全按照HTTP语义要求高。

2、我的建议：

1）对于保存、更新类的请求POST、PUT请求，把全部参数都放到请求报文体中；

2）对于DELETE请求，要传递的参数就是一个资源的id，因此把参数放到QueryString中即可；

3）对于GET请求，一般参数的内容都不会太长，因此统一通过QueryString传递参数就可以。对于极少数参数内容超过URL限制的请求，由于GET、PUT请求都是幂等的，因此我们把请求改成通过PUT请求，然后通过报文体来传递参数。

服务器端要通过状态码来反映资

1、对于数据库服务器连接失败、请求报文格式、服务器端异常等非业务错误，服务器端应该返回4xx、5xx等状态码。

2、对于业务层面的错误，比如用户不存在，我们要使用4xx等HTTP状态码返回。同样在响应报文体中给出详细的错误信息，比如{“code”:3,”message”:”用户不存在”}。

3、不仅要返回4xx的HTTP状态码，而且不要忘了通过响应报文体给出详细的错误信息。对于用户不存在，不仅要404，而且把响应报文体设置为{“code”:3,”message”:”用户名已存在”}，这样能区分出来是哪里的问题。

源获取的结果：404、403（没有权限）、201（新增成功）。

重点看一下红字部分，需要对错误写出详细信息，看一下ABP项目中是如何对错误进行处理的.

if (xxxxxxxxxxxxxxxxxxxxxx)
   {
       throw new ConditionException(fuckErrorCodes.nofuckUser);
    }

 新建一个类来定义错误状态. 具体实现看一下官方文档。

Exception Handling | Documentation Center | ABP.IOABP提供了用于处理Web应用程序异常的标准模型.https://docs.abp.io/zh-Hans/abp/5.3/Exception-Handling