zoukankan      html  css  js  c++  java
  • 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。
     
     
     
     

    文章来源:https://blog.csdn.net/russell_tao/article/details/72801496

  • 相关阅读:
    关于celery踩坑
    关于git的分批提交pull requests流程
    SymGAN—Exploiting Images for Video Recognition: Heterogeneous Feature Augmentation via Symmetric Adversarial Learning学习笔记
    AFN—Larger Norm More Transferable: An Adaptive Feature Norm Approach for Unsupervised Domain Adaptation学习笔记
    Learning to Transfer Examples for Partial Domain Adaptation学习笔记
    Partial Adversarial Domain Adaptation学习笔记
    Partial Transfer Learning with Selective Adversarial Networks学习笔记
    Importance Weighted Adversarial Nets for Partial Domain Adaptation学习笔记
    Exploiting Images for Video Recognition with Hierarchical Generative Adversarial Networks学习笔记
    improved open set domain adaptation with backpropagation 学习笔记
  • 原文地址:https://www.cnblogs.com/zhanglixina/p/9584078.html
Copyright © 2011-2022 走看看