看业务吧，这个因该

做出来更好！
我这边对于简单业务接口，做了数据库校验，还有像涉及到手续费之类也添加了。
但是如果是很复杂的业务，涉及的表很多，这校验起来 会很麻烦，唉。。。做起来会比较繁琐。

这个肯定得做啊，这属于接口的主要功能呀

其实这个问题就涉及到测试的分层了。

如果你们公司会做比较完整的单元测试，单元测试会去校验数据库，那么你主要关注接口规范就好，或者业务逻辑。

不然的话，所有的东西你都需要去关注。

我自己理解，测试一层一层的上来，你可以选择信任或者不信任下层的测试。

谢谢大家解惑！我也觉得数据库校验应该留给单元测试，各个层级目的明确，不然会有很多交叉和重复性工作。

之前做过一个金融系统的，表单非常多，基于业务接口做的，不得不做数据库校验，不做心里没底呀

我给你说一下我目前的做法吧，例如一个接口，提交请求后，可能会涉及到多个接口的变化或者库的变化，例如淘宝的购物来说，下单的接口，肯定会影响，购买者购买列表 +1,商家订单 +1,商品库存-1，用户金额-xx 元，帐号中间人 +xx 元，周边的可能还会涉及到，例如商家的消息提醒列表，等等，很多。我这面是单独把上面所有的校验点，封装成一个 http 接口，例如像上面，封装后，我只需要接收 购买人,购买商品 ID，这俩参数，然后就直接返回，是否校验通过,如果校验不通过,不通过的原因，然后走正常的下单接口，校验简单的下单返回状态是否 OK，然后在去请求我的校验接口，查看是否校验通过

我觉得是要的，比如新增数据接口，我接口返回了成功，但是是否真的新增成功还是要检验数据库里面的数据！