前端项目的接口管理方案—-构思前端欢迎来到☆槿畔☆的博客-

一般来讲，现在百分之90的开发方式都是前端端分离，通俗来讲就是服务端提供一个http的REST API，前端同学去调用服务端的接口进行交互。

因此就衍生出请求代码的各类封装，但是网上的开发者从来就没有一个具体的定义，网上也没有具体的一个特别规范的一个点。

我个人观点认为，封装就应该是拆分一层又一层，最终目的就是为了方便维护，方便拓展，方便管理。

传统的代码，也是我看见项目最烦的一种代码：

以上的这种写法，大体功能是实现了，一眼就觉得新入门的前端同学才会这样调用，缺点就是axios没有任何的封装，带来了许多累赘的代码量，headers每次都需要重复定义，返回结果也是每次都要处理一遍，对于强迫症的前端同学来讲，看着就头疼，我就不一一吐槽了。。。

进阶版的代码：

统一拦截器

post方法封装

接口调用

以上就是对axios的简单封装,主要是从几个思维，第一就是axios拦截器的综合应用统一拦截错误码，第二就是post通用方法的封装方便调用避免了通用参数的调用，这种也是我做开发以来见到各个公司最常见的封装调用方式，大同小异，基本雷同的思想。

我个人认为还能再做一层处理，我不认为这样封装请求就算完了，它在项目中依然还有一个弱点，那就是接口不方便管理，各类的接口五花八门。

理想化的调用（本人已投入项目中有使用案例）

理想化的调用就是能把所有的请求url放到一个位置集中归类并生成，各页面之间随用随调，统一管理所有url，即使后期url改版迁移，你也基本无需更改项目中的代码，只需要在你封装的请求方法上简单的动一动。

api存储json文件

循环生成接口请求的方法api，这里直接根据vue的特性，挂载到Vue.prototype上,Vue.prototype.$api = api

（这里要提一下，关于把接口挂载到vue原型链上是否真的可行，有的觉得过多的内容挂载到vue的原型上会让其根变的笨重，各位可以亲测一下，你如果只是把function循环挂载到原型上其实一般是不会影响你网页的加载速度以及各项性能的。除非你打印出来具体整个对象。实在觉得有问题你也可以无需挂载，直接单个引入，像引入单个组件那样去使用）

项目中直接调用

以上方法比传统封装调用有以下优势：

• apiName自定义语义化key值，方便自我接口调用
• 解决了后台定义请求url较长，代码不美观问题
• 方便维护接口，假如有项目接口迁移，你只需要在api的json列表去简单更改
• 接口统一管理，逻辑业务代码只管调用

以上是对项目封装请求的一个小结，但是本人太懒，希望这些接口json无需前端手动，而是服务端生成的，前端同学在开发的时候只需要在项目中拉取代码生成即可，所以有以下构思，也是正准备实践的，

搭建一个可视化的后台管理系统，可以配置前端开发中用到的所有接口，把不同项目请求的所需要的json进行统一管理

1.先出原型（产品的活，人人都是产品经理，简单），在这里可以新建一个项目，技术选型 nodejs+mysql+redis

*key值和版本就是项目请求json的依据，合并编辑删除是对项目的操作，合并只能合并同一项目下的不同版本号

2.新建项目可以选择历史项目，加上版本号，就参考了git的分支思想，后期迭代时可以不公用一个项目api

3.点击项目的详情就是对单个项目的接口管理，在这里可以新建单个，也可以选择从公司接口文档中批量导出

以上是接口管理方案的主流程，只要对外的json开放了http服务，本地项目直接请求通过fs模块生成到本地目录即可，出于安全机制考虑会加入账号系统，日志管理，并仅部署在内网

以上所有方案均为个人构思，欢迎各位技术大佬互相学习指正。。。