API的接口变迁

API的接口变迁

最近前端团队越发觉得目前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。

(转载本站文章请注明作者和出处 陶辉笔记 ,请勿用于任何商业用途)



发表评论

电子邮件地址不会被公开。 必填项已用*标注

浙公网安备 33010802009076号