最近前端团队越发觉得目前API接口有些不好用，所以我也借此重新理一下我们的API接口。
API没有什么完美的设计理念和原则，只有最适合当下的设计。这个最适合包括：当前使用的技术架构、团队规模、团队成员技术特点、开发时间、人力成本、未来业务与技术的预期等。我先来回顾下我们产品的API变迁过程。
作为从0到1的创业公司，客户、CEO提出的需求是全新没有产品先例可以参考的，故首先要验证产品原型，而最初只有我一个技术人员，因此开发效率是关键。此时，使用后端模板弱化API是速度最快的，讨论出一个页面往往一天就可以把前后端全部开发完成。特别使用django这种既把ORM做得灵活又好用，又把后端模板与表单、ORM的结合做到极致的全能型WEB框架后，一个人就可以维护上百个WEB页面和数据库表。
而接下来，业务驱动要求不光有浏览器还得有微信服务号、微信小程序、iOS和android的APP，这样之前的后端模板方式就有大问题了，往往每种前端都需要独立的后端模板，大量的重复代码将会产生，这对长期维护的产品是不可接受的。而团队成员也在扩张中，前后端人员招聘到位后，专业的前端人员比我这种后端出身的所谓“全栈”开发速度快很多。此时，我们第一位前端阿正建议使用前后端分离技术，用大前端框架与后端解耦合，开发频繁交互体验更好的单页式应用。而在我看来，这样也可以更好的满足多种前端并存时的产品，尤其是APP的开发上，我认定我们的APP不需要原生APP那么复杂的功能，而基于小团队定位、快速迭代开发这个原则，webapp成为我的第一选择，这与大前端是一致的。于是，我决定尝试前后端分离，而API也从此正式登场。
最初的产品交互原型改动频繁，而且团队的后端磊哥先于前端入职一个多月，所以，哪些数据应该划分到一个API呢？因为不能依据还没确定下来的产品原型图，于是很自然的，就以数据这个维度圈定API粒度了。通常是，一张mysql表就是一组API，包括增删改查。这么做的好处很明显，数据库是经过逻辑抽象的，改动数据库的频率要远远小于前端页面，以及API的请求参数和返回参数。而API是最怕重构式修改的，依据数据库的表设计，最初近百个API很快设计实现出来了，也确实可以支撑前端的开发。然而，问题也很明显，高度抽象的ORM使得关系数据库是完全范式设计的，所以DB表特别多！而前端最初不是一个几十人的团队，而是只有一个人！随便一个页面要拉好几个接口，这样就完全无法接受了，产品的开发速度大受影响。如何解决呢？方法一：前端多拉几次接口，同时把API调用框架做得再强大些；方法二：后端按照前端的要求，增加API的返回值，通常，这是由页面显示的值驱动后端在一个接口中返回多张表的数据，而后端强大的ORM模型可以轻松办到。然而，由于有两套玩法，就会造成不统一，不同的场景不同的前端开发人员选用不同的方式。最重要的是对API权限的考虑不到位。这为当前的困境埋下了隐患。
产品开发的差不多了，姗姗来迟的测试登场，于是权限问题冒出来了。之前，后端系统梳理过API权限的设计。由于我们的系统是平台，对接的是企业以及并不隶属于企业的工人，角色较多，且多企业实际上在协同服务于一个工程，最复杂的是角色间的关系是由实时变动的合同决定。所以API的权限会很复杂，例如：某请求可以被甲企业中的A角色调用，但不能被甲企业中的B角色调用，还不能被协同合作的乙企业中的A角色调用，但可以被乙企业中的C角色调用，且A角色中有M、N两个人，其调用完全相同参数的请求返回内容并不相同。这个现象的产生，是因为我们有多种合同，至少三种合同共同作用于一个工程时，就会产生多种角色下不同用户的权限变化多端。后端用了一种很巧妙的方式，把这种复杂以可读性还不错的配置文件实现，于是，测试提出的权限问题后端可以分分钟实现，但前端就苦逼了！就像上文我说的，有些页面前端发现需要调很多接口时，会要求后端增加返回字段；有些页面则调用了很多接口。而现在，原本体验很好的页面，因为后端在API上增加了权限限制，就会出现有些角色、用户在该页面上，部分接口调用开始权限不足，页面因为接口错误而出现各种问题！且随着测试的深入，权限控制越来越细，于是系统体验进一步变差，测试开始提更多的BUG砸向开发，前端越发对API不满。。。
那么，清楚了整个流程后，我们才可以梳理出脉络。之前留了些什么坑呢？有几个与实时合同关联密切的DB表，这几张表引出的相应API存在考虑产品设计不够的问题。即，不同的角色，会有场景要求对同一张表里的不同列有查询需求，而之前的API因为与DB表一一对应（抽象表时不考虑角色权限问题，因此忽略了列），且就像前文中所说API在增加字段时完全由前端人员驱动而整体考虑不足。所以，系统解决方案应为，对当前的这几个存在问题的API按照角色权限的调用，进一步归类，归类后按照类别增加关联DB表中某些列字段的返回。这个方案的修改成本最小，且DB表的抽象本来也隐含有一些权限控制，只是相对产品交互就要差一些，所以仍然可以保持API在未来不会有大的变迁。
再回过头来看看API的变迁，其实把一个产品从小开始往大了养，每个阶段的侧重点都应该是完全不同的。创业团队一定要勇于试错，在试错中磨合，提升团队和个人的战斗力。就像人月神话中所说，大公司的人海战术是无法跨跃试错阶段的，这也是创业公司的机会所在。而且，技术是服务于业务的，技术人员从这个角度出发，去看待项目管理，去看待产品发展，个人会有非常大的成长。所以从招聘角度，大公司从一开始就伴随公司成长的那批人，才是创业公司最需要的，他们清楚不同阶段应该采用什么策略。反之平台光环下后期加入的未经历过初始阶段的人才，一旦失去了大平台就容易无所适从，因为大平台的玩法只适合大平台，这限制了个人的成长。
我们公司是一家致力于改变中国建筑业的互联网公司，正在快速发展中，因为后发优势使用了诸多成熟的新技术，如docker微服务、大前端、h5 webapp、websocket协议、持续集成、一键部署、基于python的快速开发后台、人脸识别、室内外LBS服务、自动化测试、NOSQL分布式数据库、即将开展的数据挖掘，欢迎有志于创业的技术人加入我们！联系邮箱：hr@zlddata.cn。
文章来源：https://blog.csdn.net/russell_tao/article/details/72801496