前言
作為一名前端同學(xué)茁帽，主要工作就是數(shù)據(jù)的展示和處理用戶的可視化交互（就籠統(tǒng)地概括一下蛤奥，當(dāng)然還是代碼管理項(xiàng)目構(gòu)建和部署blablabla一大堆）巡蘸。
其中一定少不了要和后端打交道畅蹂，而API接口就是前端和后端之間的橋梁童漩，后端同學(xué)按照約定好的接口格式返回前端所需要的數(shù)據(jù)，前端同學(xué)通過HTTP請(qǐng)求獲取數(shù)據(jù)并呈現(xiàn)在用戶面前沟蔑。所以今天我們來談?wù)勄岸藢?duì)API接口的封裝以及管理湿诊。
封裝和管理，從何說起瘦材？我主要從以下幾點(diǎn)展開：
HTTP庫的選用
適配層的封裝
業(yè)務(wù)層的封裝
接口數(shù)據(jù)規(guī)范化
HTTP庫的選用
目前流行的HTTP庫有很多厅须，從最開始的原生XHR，到JQ ajax食棕，再到現(xiàn)在fetch API朗和，Axios，Superagent簿晓，其實(shí)選用哪一個(gè)庫都可以眶拉，他們都有自己的優(yōu)勢(shì)，就看你是想更加方便地?zé)o腦式操作還是想從更底層地去調(diào)用和封裝出你想要的效果憔儿，重點(diǎn)是你得清楚了解你選用的庫所提供的API忆植，盡其所用。
這里提供一些HTTP庫的文章，方便大家進(jìn)行技術(shù)選型～
JS HTTP請(qǐng)求庫(Axios吴侦、Request、Superagent坞古、Fetch备韧、Supertest)的優(yōu)缺點(diǎn)
適配層的封裝
為什么需要適配層？適配層的意義在于痪枫，提高代碼的通用性和魯棒性织堂。
也就是說，哪天突然你真的覺得你所選用的HTTP庫實(shí)在無法滿足你的業(yè)務(wù)需求了奶陈，你可以將底層的HTTP庫直接換掉也不會(huì)對(duì)你的項(xiàng)目造成太大的影響易阳。這就是適配層發(fā)揮的作用。
所以適配層需要對(duì)底層的HTTP庫進(jìn)行封裝吃粒，包括但不限于以下操作：
對(duì)傳參進(jìn)行默認(rèn)配置和容錯(cuò)補(bǔ)全的封裝潦俺。
提供更通用的請(qǐng)求接口，例如針對(duì)RESTful規(guī)范徐勃。
提供對(duì)接口請(qǐng)求的完整生命周期鉤子事示，在接受請(qǐng)求數(shù)據(jù)，發(fā)起請(qǐng)求僻肖，獲取響應(yīng)肖爵，響應(yīng)失敗，響應(yīng)成功等階段提供事件監(jiān)聽操作臀脏。
對(duì)請(qǐng)求數(shù)據(jù)和相應(yīng)數(shù)據(jù)的格式進(jìn)行約束劝堪，更為規(guī)范化（下面還會(huì)討論到）。
業(yè)務(wù)層的封裝
有了適配層的封裝揉稚，我們可以更專注于業(yè)務(wù)上的邏輯處理秒啦，為了提高代碼的復(fù)用性，我們可以根據(jù)業(yè)務(wù)需求搀玖，在適配層的基礎(chǔ)上再加一層業(yè)務(wù)層余境。
業(yè)務(wù)層可以做的東西很多，主要根據(jù)不同項(xiàng)目的需求進(jìn)行定制巷怜，以下是一些我曾使用過或者比較常見的一些操作：
添加鑒權(quán)操作
監(jiān)控日志埋點(diǎn)
錯(cuò)誤/警告彈窗提示以及重定向
表單序列化
接口數(shù)據(jù)規(guī)范化
所謂的接口數(shù)據(jù)規(guī)范化葛超，其實(shí)就是對(duì)請(qǐng)求數(shù)據(jù)和響應(yīng)數(shù)據(jù)的格式進(jìn)行嚴(yán)格的約束。
我們經(jīng)常會(huì)和后端同學(xué)共同約定出一份接口文檔延塑，規(guī)定哪個(gè)接口對(duì)應(yīng)哪些字段，每個(gè)字段對(duì)應(yīng)哪些數(shù)據(jù)類型答渔，哪些字段是必填項(xiàng)关带，哪些字段為空時(shí)是不傳還是返回null或者{}，諸如此類的，我們最多就只能根據(jù)約定形成一份接口文檔宋雏，大家按照文檔嚴(yán)格執(zhí)行即可芜飘。但是現(xiàn)實(shí)永遠(yuǎn)不會(huì)如我們想象中完美，我們總會(huì)有bug的時(shí)候磨总。所以理想化的方案就是嗦明，我們?yōu)槊總€(gè)接口定義出一個(gè)schema，請(qǐng)求數(shù)據(jù)和響應(yīng)數(shù)據(jù)都嚴(yán)格按照這個(gè)schema蚪燕，假如出現(xiàn)問題就進(jìn)行錯(cuò)誤捕捉娶牌，這樣至少可以讓我們?cè)诔鯾ug的時(shí)候不會(huì)一臉懵逼。
（以下都是一些方案的可行性分析馆纳，大家可以進(jìn)行參考）
GraphQL
上面一提到理想化方案诗良，有同學(xué)第一時(shí)間會(huì)想到GraphQL，是的鲁驶，GraphQL就是為此而誕生的：
GraphQL可以提供一套完整的類型系統(tǒng)鉴裹。
API有強(qiáng)類型的Schema作保證，若發(fā)現(xiàn)發(fā)送和接受的數(shù)據(jù)不符合預(yù)期钥弯，能夠快速感知到錯(cuò)誤径荔。
但是同時(shí)，我們也要看到GraphQL存在的問題：
使用風(fēng)險(xiǎn)大脆霎。GraphQL即使幾年前就已經(jīng)火了起來猖凛，但是目前在國內(nèi)關(guān)于GraphQL的文檔和開源項(xiàng)目都不多，對(duì)于很多團(tuán)隊(duì)（包括我們绪穆。辨泳。）來說都是有不小的風(fēng)險(xiǎn)。
引入成本高玖院。GraphQL對(duì)前端來說確實(shí)很爽菠红，但是針對(duì)服務(wù)端來說是個(gè)很大的改動(dòng)，例如搭建符合GraphQL標(biāo)準(zhǔn)的接口难菌，若沒有BE同學(xué)的全力配合试溯，前端就需要自己搭建一層node API server。
TS Flow
TS和Flow本來就是對(duì)整個(gè)前端項(xiàng)目進(jìn)行靜態(tài)類型檢查的郊酒，就算不提及本節(jié)的接口數(shù)據(jù)規(guī)范化遇绞，大家也應(yīng)該主動(dòng)去接觸他們，在此不再贅述～
Superstruct
傳送門：
Superstruct是slate作者Ian Storm Taylor的開源項(xiàng)目燎窘，他當(dāng)初創(chuàng)建這個(gè)項(xiàng)目的初衷是通過定義一個(gè)簡(jiǎn)單的schema來驗(yàn)證數(shù)據(jù)摹闽，所以在通過與同類工具的對(duì)比以及受到Typescript，F(xiàn)low褐健，Go和GraphQL的啟發(fā)付鹿，Superstruct，這個(gè)通過簡(jiǎn)單且可組合的方式來驗(yàn)證JS數(shù)據(jù)的工具庫應(yīng)運(yùn)而生。
Superstruct相對(duì)于joi舵匾，express-validator俊抵，validator.js，yup坐梯，ajv等同款的校驗(yàn)工具庫而言徽诲，他們存在一些問題：
無法提供準(zhǔn)確的錯(cuò)誤信息
無法自定義數(shù)據(jù)格式
和其他框架的強(qiáng)耦合
使用JSONS SCHEMA，過于重而復(fù)雜
而Superstruct的優(yōu)勢(shì)有以下幾點(diǎn)：
方便輕松地定義整套數(shù)據(jù)結(jié)構(gòu)
可組合Schema
有效的錯(cuò)誤信息吵血，包括出錯(cuò)的路徑谎替，期望類型，錯(cuò)誤文本提示等
參考了Typescript践瓷，F(xiàn)low院喜，Go和GraphQL等優(yōu)秀項(xiàng)目，提供的API都十分類似晕翠，可以快速入門
基于以上的優(yōu)點(diǎn)喷舀，本人是比較傾向于使用Superstruct這類比較輕的工具來達(dá)到效果滴～
最后
最后說幾點(diǎn)，以上都是本人在項(xiàng)目開發(fā)中的一些小領(lǐng)悟和看法淋肾，不一定準(zhǔn)確而且滿足讀者們實(shí)際的項(xiàng)目需求哦硫麻，包括適配層和業(yè)務(wù)層的具體功能劃分，而且也沒有具體的代碼呈現(xiàn)給大家（還不是因?yàn)閼校┓浚蠹铱梢噪S時(shí)在評(píng)論區(qū)進(jìn)行討論和提出本文所不足或錯(cuò)誤的地方拿愧，假如大家覺得有所收獲的話也可以點(diǎn)個(gè)喜歡??，謝謝??
