类复用噩梦 在单一参数类结构下，我常常看到多个存在清楚功用差异的接口频繁复用一个结构体，甚至接口参数和前往值都复用一个DTO，为了保证兼容，又不得不在同一个DTO内不断加字段，一朝一夕维护成本继续增高，这是一种不合理的类设计，假设遵守专注准绳，这个成绩很多时分可以避免。

兼容性

接口逻辑或许参数变更时，需求对旧的接口保持兼容，这个是API变更时一定要遵守的准绳之一，而且要经过接口测试来验证兼容性。

能否要新增接口，当面对一个新的需求时，为了避免对旧接口直接修正，有的开发人员会一致提供新的接口，假设并非逻辑上发作较大的变更，这样做会提高API的维护成本，后续假设不对API停止重构，新添加的维护成本将远大于最末尾节省的开发成本，例如需求对某个参数添加有效校验，那么我们需求对两个接口的API完成都做修正，而且是重复性的代码，而且我们的影响范围曾经成了两个接口，这样影响范围的扩展也带来了更多的潜在风险。当然在某些场景例如接口逻辑出现大的调整，API重构等状况下，更好的办法是提供新的接口，并推进效劳消费者运用新的API，最后渐渐下线旧的API，这样才能遵照复杂和专注的准绳。

完善的测试

单元测试，完善的单元测试能保证代码的强健性，提早在编码阶段发现并处置潜在的bug，单元测试是一个开发人员的必备才能。

接口和场景测试，接口测试包含外部逻辑验证，异常输入，并发等场景下对单一接口的验证，假设要对API停止残缺的逻辑验证，需求开发人员结构残缺的测试数据（通常包含scheme.sql和data.sql文件），尤其是关于基础效劳，需求对某些复杂业务场景下结合多个接口完成某个场景的测试，并对中间的数据和输入停止Assert确认，这样也会代码一定的测试代码维护成本，需求开发人员停止利害权衡。

注重文档

良好的注释和文档能增加大部分和效劳消费者的沟通任务，也避免了一些错误的接口调运用。没有人希望每次都需求在IM工具上糜费少量口水或许需求当面讯问才知道如何正确运用API，也没有开发者情愿每天重复回答如何调用提供的接口。

关于接口文档，可以是采用Javadoc这样复杂的方式，也可以是经过wiki来集中管理，可以是markdown文档，也有很多的开源系系统例如Swagger，yapi，eolinker等；微效劳的架构极大的增强了沟通的成本，这也是微效劳架构的一个弊端，但是合理的应用 工具 可以增加不必要的沟通。

总结

作为微效劳之间的桥梁，API设计和维护是微效劳架构中很重要的一个环节，每个开发人员不只仅需求良好的代码标准，也需求树立并遵守API设计标准。API设计才能在微效劳架构中作为软实力的一个部分，需求开发人员有一定的设计阅历的积聚，同时，只要不断的思索和总结才能愈加深化的了解。

【编辑引荐】

笨办法学Linux 功用调优 (原理、实际、记载与排错)-视频课程

智能家居技术运用于家庭之外的3个中央

Netty基础招式——ChannelHandler的优秀实际

在 Dubbo3.0 上效劳管理的实际

从五小气面，清点2021年中UI/UX设计趋向

(责任编辑：admin)