开发接口时的“边缘思想”

结论：开发接口时，除了实现基本需求外，还要考虑一些边缘条件，提高代码的健壮性。
方法：树立假想敌，不走正常的调用（前端页面操作），直接调接口（如postman、swagger…），调接口时就设置不正常的条件

举个很简单的例子：

• 前端用户做了一些列操作以后（中途可能调别的接口校验），最后才调你这个接口。
• 这时调你接口时，已经规避了很多边缘条件，发起调用的时候其实已经是“理想状态”了，能正常的调通、响应。
• 与上边说的相似的一种情况是，自己用postman测试的时候，也会mock符合接口条件的数据进行测试，这其实也已经隐形地 规避了很多边缘条件。

上边这种开发习惯会造成：程序的健壮性不够好

再形象化一下例子：

需求：

我要实现 添加应用依赖关系
-> 其中会开发 应用依赖关系检查 的接口，做预处理

• 前端用户操作：
  • 每添加一个应用的依赖时都会调用应用依赖关系检查接口，这样到最后调用添加应用依赖关系接口时，已经万事俱备只欠东风了，直接调用就可以。
• 用postman模拟用户操作mock数据：
  • mock通过“应用依赖关系检查”的数据，最后肯定也是成功的
• “假想敌”用postman mock数据
  • 可能不模拟用户操作（就当没有页面操作预判）
  • 他会怎么做？
    • 肯定是随便造数据 —— “错误的”数据
    • 这时候直接调用添加应用依赖关系接口时，肯定就失败了

那怎么办？

必须让添加应用依赖关系接口能独当一面

• 添加应用依赖关系接口不能单单只实现创建
• 在创建前，仍然要进行应用依赖关系检查
• 检查通过，方可执行

所以，可以得出这样一个结论
实现一个接口前的，所有用作 条件判断 的前置接口，他们的功能（方法）都应在这个接口中实现