引言
高质量API接口定义
前后端分离的架构的好处就是前端后端可以依据需求同时开工，可以提升工作效率，但这里有个非常重要的前提就是，必须得把接口文档搞定，前后端才可以一起开发。接口文档不但要有，而且要根据需求确定详细的接口内容（一般包含：接口访问地址，访问方式，提交的数据和返回的数据）。
有了接口文档，前端可以Mock数据，不影响开发。前端开发完毕后再和后端联调。
接口定义由后端人员给出，接口设计关键在于对业务的理解。业务整体变，导致接口也会随之做调整。所以从需求层面要尽量减少变更
是否要做接口设计评审？
就像需求评审一样，前后端一起确定接口的参数名称、数据类型、个数、数据组成形式，返回值的形式、个数、数据类型、接口返回的错误码列表等具体信息然后形成独立的文档，初期的时候，前端会用mock的方式造一些数据，等开发按照接口文档规定的方式和内容写完接口后，直接更换地址即可开始联调测试。
这种方式比较节省时间。而且也是比较科学的方式，避免了直到后期还要返工改接口的风险。
所以建议将接口设计评审纳入到研发流程中？如果接口定义遵守约定的话是否不需要接口评审
后端接口自测的标准？接口自测的方法
http/https接口：postman/YAPI
dubbo接口：单元测试
卡口标准：单测通过率>90%以上，单元测试覆盖率60%以上
gitt提交代码->自动执行单元测试/触发jenkins运行自动化测试/触发sonar执行静态代码扫描->上线前质量卡口（单测通过率、自动化测试通过率、静态代码扫描严重bug数）->上线后稳定性监控
接口定义规范
-
协议规则
-
请求参数公共字段格式
-
返回参数字段格式
-
示例1:获取商品库存
-
示例2:下单前校验库存
-
接口返回字段代码
-
接口错误码
-
各应用系统错误码
错误码共8位数字，前4位为系统编号，每个系统需要统一登记分配（全局异常系统编号为9999），后4位由各系统自行分配