前言
作为一名前端同学，主要工作就是数据的展示和处理用户的可视化交互（就笼统地概括一下，当然还是代码管理项目构建和部署blablabla一大堆）。
其中一定少不了要和后端打交道，而API接口就是前端和后端之间的桥梁，后端同学按照约定好的接口格式返回前端所需要的数据，前端同学通过HTTP请求获取数据并呈现在用户面前。所以今天我们来谈谈前端对API接口的封装以及管理。
封装和管理，从何说起？我主要从以下几点展开：
-
HTTP库的选用
-
适配层的封装
-
业务层的封装
-
接口数据规范化
HTTP库的选用
目前流行的HTTP库有很多，从最开始的原生XHR，到JQ ajax，再到现在fetch API，Axios，Superagent，其实选用哪一个库都可以，他们都有自己的优势，就看你是想更加方便地无脑式操作还是想从更底层地去调用和封装出你想要的效果，重点是你得清楚了解你选用的库所提供的API，尽其所用。
这里提供一些HTTP库的文章，方便大家进行技术选型～
适配层的封装
为什么需要适配层？适配层的意义在于，提高代码的通用性和鲁棒性。
也就是说，哪天突然你真的觉得你所选用的HTTP库实在无法满足你的业务需求了，你可以将底层的HTTP库直接换掉也不会对你的项目造成太大的影响。这就是适配层发挥的作用。
所以适配层需要对底层的HTTP库进行封装，包括但不限于以下操作：
-
对传参进行默认配置和容错补全的封装。
-
提供更通用的请求接口，例如针对RESTful规范。
-
提供对接口请求的完整生命周期钩子，在接受请求数据，发起请求，获取响应，响应失败，响应成功等阶段提供事件监听操作。
-
对请求数据和相应数据的格式进行约束，更为规范化（下面还会讨论到）。
业务层的封装
有了适配层的封装，我们可以更专注于业务上的逻辑处理，为了提高代码的复用性，我们可以根据业务需求，在适配层的基础上再加一层业务层。
业务层可以做的东西很多，主要根据不同项目的需求进行定制，以下是一些我曾使用过或者比较常见的一些操作：
-
添加鉴权操作
-
监控日志埋点
-
错误/警告弹窗提示以及重定向
-
表单序列化
接口数据规范化
所谓的接口数据规范化，其实就是对请求数据和响应数据的格式进行严格的约束。
我们经常会和后端同学共同约定出一份接口文档，规定哪个接口对应哪些字段，每个字段对应哪些数据类型，哪些字段是必填项，哪些字段为空时是不传还是返回null或者{}，诸如此类的，我们最多就只能根据约定形成一份接口文档，大家按照文档严格执行即可。但是现实永远不会如我们想象中完美，我们总会有bug的时候。所以理想化的方案就是，我们为每个接口定义出一个schema，请求数据和响应数据都严格按照这个schema，假如出现问题就进行错误捕捉，这样至少可以让我们在出bug的时候不会一脸懵逼。
（以下都是一些方案的可行性分析，大家可以进行参考）
GraphQL
上面一提到理想化方案，有同学第一时间会想到GraphQL，是的，GraphQL就是为此而诞生的：
-
GraphQL可以提供一套完整的类型系统。
-
API有强类型的Schema作保证，若发现发送和接受的数据不符合预期，能够快速感知到错误。
但是同时，我们也要看到GraphQL存在的问题：
-
使用风险大。GraphQL即使几年前就已经火了起来，但是目前在国内关于GraphQL的文档和开源项目都不多，对于很多团队（包括我们。。）来说都是有不小的风险。
-
引入成本高。GraphQL对前端来说确实很爽，但是针对服务端来说是个很大的改动，例如搭建符合GraphQL标准的接口，若没有BE同学的全力配合，前端就需要自己搭建一层node API server。
TS Flow
TS和Flow本来就是对整个前端项目进行静态类型检查的，就算不提及本节的接口数据规范化，大家也应该主动去接触他们，在此不再赘述～
Superstruct
传送门：
Superstruct是slate作者Ian Storm Taylor的开源项目，他当初创建这个项目的初衷是通过定义一个简单的schema来验证数据，所以在通过与同类工具的对比以及受到Typescript，Flow，Go和GraphQL的启发，Superstruct，这个通过简单且可组合的方式来验证JS数据的工具库应运而生。
Superstruct相对于joi，express-validator，validator.js，yup，ajv等同款的校验工具库而言，他们存在一些问题：
-
无法提供准确的错误信息
-
无法自定义数据格式
-
和其他框架的强耦合
-
使用JSONS SCHEMA，过于重而复杂
而Superstruct的优势有以下几点：
-
方便轻松地定义整套数据结构
-
可组合Schema
-
有效的错误信息，包括出错的路径，期望类型，错误文本提示等
-
参考了Typescript，Flow，Go和GraphQL等优秀项目，提供的API都十分类似，可以快速入门
基于以上的优点，本人是比较倾向于使用Superstruct这类比较轻的工具来达到效果滴～
最后
最后说几点，以上都是本人在项目开发中的一些小领悟和看法，不一定准确而且满足读者们实际的项目需求哦，包括适配层和业务层的具体功能划分，而且也没有具体的代码呈现给大家（还不是因为懒），大家可以随时在评论区进行讨论和提出本文所不足或错误的地方，假如大家觉得有所收获的话也可以点个喜欢💗，谢谢🙏
网友评论