怎么设计一个好的接口（一）

之前有面试官问我：怎么设计一个好的接口

结合工作实际做记录：

1.昨天遇到一个接口，入参给了一个售后单id，查询售后单详细，接口内部还需要根据这个id去调调用方查询这个售后单id是哪供应商的，解读这个接口是：给了一个不知道是哪个供应商的售后单id来查询售后单详细，很奇怪不？参数不明确

定义的参数要明确，能让人看懂，你这个接口是干嘛的，这个接口可以加上一个参数，供应商code，就可以解读为：查询某某的供应商的售后单id为某某的售后单详细

2.接口要遵循业务单一职责，特别是基础服务接口，对外的聚合接口可以有一定的业务耦合

3.接口从命名到参数，能看出明确的含义，包括参数，即看到接口，你能看出这个接口干啥的

4.参数和功能最小功能原则，接口不能暴露和处理除了业务外的其他信息

5.命名规范

6.了解业务，举个栗子：之前我们商城的售后是别的团队开发的，考录到团队间的bian边界，我们对外提供了售后的接口，在提供接口时，我把很多接口的入参都是我们的供应商订单号，而不是我们的sha商城的订单号，这回造成什么影响呢，使用者必须知道我们的配货这块的信息，我需要额外提供供应商的配货信息接口，其实对于他来说，只用使用售后接口就行了，现在加了一个一个前提，他们需要了解配货，相当于，我这个接口的一部分信息对外暴露了，我不能控制这部分配货的信息逻辑，所以，我们应该入参是商城的订单id，我们根据商城订单id，找到对应的供应商，找到供应商的售后，我们要封装这段供应商逻辑，不能抛到外面，不可控，也违背迪米特原则：最少知识，降低系统之间耦合。