一般来讲，现在百分之90的开发方式都是前后端分离，通俗来讲就是服务端提供一个http的RESTAPI，前端同学去调用服务端的接口进行交互。
因此就衍生出请求代码的各类封装，但是网上的开发者从来就没有一个具体的定义，网上也没有具体的一个特别规范的一个点。
我个人观点认为，封装就应该是拆分一层又一层，最终目的就是为了方便维护，方便拓展，方便管理。
传统的代码，也是我看见项目最烦的一种代码：
以上的这种写法，大体功能是实现了，一眼就觉得新入门的前端同学才会这样调用，缺点就是axios没有任何的封装，带来了许多累赘的代码量，headers每次都需要重复定义，返回结果也是每次都要处理一遍，对于强迫症的前端同学来讲，看着就头疼，我就不一一吐槽了。。。
进阶版的代码：
统一拦截器
post方法封装
接口调用
以上就是对axios的简单封装,主要是从几个思维，第一就是axios拦截器的综合应用统一拦截错误码，第二就是post通用方法的封装方便调用避免了通用参数的调用，这种也是我做开发以来见到各个公司最常见的封装调用方式，大同小异，基本雷同的思想。
我个人认为还能再做一层处理，我不认为这样封装请求就算完了，它在项目中依然还有一个弱点，那就是接口不方便管理，各类的接口五花八门。
理想化的调用
理想化的调用就是能把所有的请求url放到一个位置集中归类并生成，各页面之间随用随调，统一管理所有url，即使后期url改版迁移，你也基本无需更改项目中的代码，只需要在你封装的请求方法上简单的动一动。
api存储json文件
循环生成接口请求的方法api，这里直接根据vue的特性，挂载到Vuprototype上,Vuprototyp$api=api
项目中直接调用
以上方法比传统封装调用有以下优势：
apiName自定义语义化key值，方便自我接口调用解决了后台定义请求url较长，代码不美观问题方便维护接口，假如有项目接口迁移，你只需要在api的json列表去简单更改接口统一管理，逻辑业务代码只管调用
或者你这样做获取接口的模式也许更合适，写法差不多，但是没有让原型变得笨重，在vue原型上挂一个function，这个function就是去查询你对应的api列表
以上是对项目封装请求的一个小结，但是本人太懒，希望这些接口json无需前端手动，而是服务端生成的，前端同学在开发的时候只需要在项目中拉取代码生成即可，所以有以下构思，也是正准备实践的，
搭建一个可视化的后台管理系统，可以配置前端开发中用到的所有接口，把不同项目请求的所需要的json进行统一管理
先出原型，在这里可以新建一个项目，技术选型nodejs+mysql+redis
*key值和版本就是项目请求json的依据，合并编辑删除是对项目的操作，合并只能合并同一项目下的不同版本号
新建项目可以选择历史项目，加上版本号，就参考了git的分支思想，后期迭代时可以不公用一个项目api
点击项目的详情就是对单个项目的接口管理，在这里可以新建单个，也可以选择从公司接口文档中批量导出
以上所有方案均为个人构思，欢迎各位技术大佬互相学习指正。。。
文章为作者独立观点，不代表 股票程序化软件自动交易接口观点
股民评论