如何设计接口

如何设计接口

接口作为连通客户端与数据库进行数据流通的桥梁，起着举足轻重的作用，直接影响着程序的效率性、稳定性、可靠性以及数据的正确性、完整性。客户端注重的是界面美观，操作方便顺畅，是用户最直接的感受体验，而接口则是所有数据的提供者，是用户深层的内涵体验。

因次，设计接口在一个项目中，是非常重要的。本篇经验将和大家总结下如何合理设计接口。

深入了解需求

除了设计数据库的人最了解需求外，其次就是设计接口的人了，甚至有时接口开发人员还要参与到数据库设计中。从“客户端-接口-数据库”的层次上看，接口明显扮演着承上启下的角色，一方面要明白接口要什么数据，另一方面要考虑如何从数据库获取、组织数据。

所以如果不了解需求，你就无法正确抽象对象来组织数据给客户端，也无法验证数据库的数据结构能否满足需求。数据库设计者要了解需求中的数据结构，而接口则更多的要了解需求中的逻辑结构以及由此衍生出的逻辑数据结构。

了解数据库结构

既然接口要明白如何从数据库获取、组织数据，就当然要了解数据库结构啦。

了解客户端原型

了解原型，其实更多是为了帮助你设计接口时需要提供的数据和结构。但有时当你设计时并没有原型，所以此条并不是必须要求的。

但假如设计完接口后原型出来了，我们也可以拿原型还验证接口设计是否正确、合理。

充分理由

不是随便一个功能就要有个接口，也不是随便一个需求就要加个接口。

每新建一个接口，就要有充分的理由和考虑，即这个接口的存在是十分有意义额价值的，无意义的接口不仅增加了维护的难度，更重要是对于程序的可控性的大大降低，接口也会十分臃肿。因此我放在了第一条。

职责明确

一个接口只负责一个业务功能，它与设计模式里的职责单一原则类似但却不同，因为一个业务功能里可能会包含多个操作，比如查询会员，可能除了查询会员表外还要获取该会员的其他必要信息，但不要在查询会员的同时还有修改权限等类似的其他业务功能，应该分成两个接口还做。

高内聚低耦合

一个接口要包含完整的业务功能，而不同接口之间的业务关联要尽可能的小。还是查询会员的例子，有时查询会员的同时，可能该会员的相关信息要随之发生变化（如状态），如果这时一条完整的业务流水线，那么就应该在一个接口里完成，而不应再单独设立接口去操作完成。

就是说一个接口不应该随着另一个变化而变化或以某几个接口为前提而存在。

分析角度明确

设计接口分析的角度要统一明确。否则会造成接口结构的混乱。例如，不要一会以角色的角度设计，一会儿就要以功能的角度设计。

入参格式统一

所有接口的参数格式要求及风格要统一，不要一个接口参数是逗号分隔，另一个就是数组；不要一个接口日期参数是x年x月x日风格，另一个就是x-x-x。

状态及消息

提供必要的接口调用状态信息。调用是否成功？如果失败，那么失败的原因是什么。这些必要的信息必须要告诉给客户端。

控制数据量

一个接口返回不应该包含过多的数据量，过多的数据量不仅处理复杂，对数据传输的压力也非常大，会导致客户端反应缓慢。过多的数据量很多时候都是接口划分不明确。

禁止随意拓展参数

与第1条类似，只不过是针对参数而言了。日后拓展接口可能是难以避免的，但是不要随意就加参数，加参数一定是必要且有意义的，需求改变前首先应考虑现有接口内部维护是否能满足需求，而不要通过加个参数来方便自己实现需求的难度，因为参数的更变会直接导致客户端调用的变化，容易产生版本兼容性问题。

抽象业务

相比抽象对象而言，抽象业务更宏观，我觉得相对也容易一些，但抽象尺度往往不太好把握。

数据格式

接口定义的数据格式必须都经过充分考虑，否则会出现数据转换失败或超出长度等错误。如果无法确定，直接设置成字符串是最合适的。

有意义的命名

无论是接口还是参数，名称都应该是有意义的，让人能看明白的。

总之，接口设计是一个细致的工作，设计时也会有很多矛盾，但个人倾向于粗粒度设计方向（即内聚性更高一些），这样不仅给客户端浏览接口方便明确，维护也轻松些，这么做的缺点就是某一接口扩展时不是很灵活，但可以通过重新定义一个接口来弥补，但正如上所说，新增接口还是要三思而后行的。

以上很多虽然都是理论性讲解，但牢牢记住这些，并结合实际工作，就会慢慢深刻的体会到其中的含义。即理论指导实践，实践来验证理论。