接口设计分析

为什么80%的码农都做不了架构师？>>>   

如何进行接口设计不是一件很容易说清楚的事情，很多人都说来自于经验。我对整个研发过程推理一下接口设计的基本方案。

在上篇文章：【从业务分析到流程设计 】 中，我分析了业务和设计的关系。在业务分析和流程设计中，比较重要的是业务概念和程序的数据对象，核心的工作是把业务概念正确地还原为数据对象，并且为数据对象设计合适的行为。

本次接口设计，借用上次的分析结果。

做接口设计，就是做业务概念的组合。最终的结果是，通过一些列接口的组合，能够完成一个应用。至于这个应用是web应用还是native应用，还是命令行程序，还是内嵌到其他代码中，都没有关系。也就是说，接口的设计其实和表现形式没有关系，理解了业务逻辑，可以立刻完成接口的设计，不需要GUI画面。接口设计和GUI画面是不依赖的。当然凡事皆有例外，针对GUI的不同特性，从性能和体验上考虑，可能会对接口做一层包装。  接口的本质，就是实现业务概念对应的数据对象的增删改查。数据对象之间是有关系的，更准确点说法：接口的本质就是对数据对象以及其关联数据对象的增删改查。

针对数据对象设计接口，一个数据对象的增删改查对应四个接口来完成。当然也不是所有的数据数据对象都需要暴漏这四个方法，因此接口数量理论上应该小于 业务概念的数量的4倍 。当然随着业务的进化，业务概念的分分合合，接口也会相应地做进化修改。

在这篇【REST 资源分析法】 文章中，我对数据对象（里面对应的概念是资源）进行了分析，大致分为了四种类型，他们分别完成概要查询，详情查询，统计查询和判定查询的不同需求，为什么没有针对提交来做分析，因为你提交的东西还是需要查询出来的。知道了如何查询，如何判断，就知道了如何提交。设计接口的时候，可以从这四个方向，理顺业务流程，也可以从这四个方面来自检。

理顺了接口，再看如何将接口设计和GUI画面联合起来。

一个画面包含若干的业务概念，这个业务概念中有一个是主要的，其他的是附属的。判断主要和附属并不是展示的多寡来计算的。打个比方，放风筝，线是主要的，风筝面是附属的，那个能够把整体页面的信息串联起来的业务概念就是主要的概念。主要概念和次要概念是相对的，如果换一个画面，那么主次关系很可能就颠倒过来了。主要概念只是起到一个线索作用：串联本画面的其他概念；串联本画面和上一个画面，下一个画面的概念。

接口像一根吸管，一端是调用者，一端是数据对象。调用者查询某个数据对象，调用者发生了兴趣，调用者对数据对象做些改变，调用者向服务器提交修改后的数据对象。

一个GUI画面根据展示需要，组合使用一个或多个接口查询概要，详情或者统计信息，然后根据判断查询来进行跳转或者提交。

对于web应用来说，接口是通过http协议表现的，由于http协议的天然无状态，所以，你不能指望，这些接口的调用是符合一定的顺序的。当然，没有绝对的，只要能接受相应的代价即可，这个代价会在未来的某一天出现。同样的，任何http的代理都有可能调用接口，所以不要指望，这些接口调用完全发生在自己的应用之内，他可能来自于另一个http代理。

GUI画面构建的流程，是脆弱的，随着对产品的认识和理解更深刻，会有对流程进行调整优化。GUI画面的跳转判断，理论上应该完全来自于接口数据，不能够依赖GUI画面的跳转顺序。

转载于:https://my.oschina.net/honchy/blog/524582