伪前端花式调接口伪前端花式调接口

背景作为你一个前端，可能你常常自诩，你是一个无情的API调用机器，调框架API，调服务端API；但下文可能会震惊到你，至少已经让我崩溃了好几天。
从10月就接到一项需求，需要将我们平台的数据同步到集团另一个平台，how? 通过开放API！！！
这个开放API 有多难调，我大概描述一下

对称加密，对方平台将给我发放一对秘钥；这似乎所有API都会这样做，毕竟安全第一!!!
MD5计算, 哦不，是MD5计算后转base64；这个其实也正常，为了数据传输防篡改，请求bodymd5加密也很常见;
请求头摘要加签，加签是什么鬼?摘要是什么鬼？没错，还是为了安全，而且这个玩法很复杂，是我以前没见过的；
只有线上环境可调，线下不可调，what？？；但最难的是，环境隔离，就是不能跨机房调用，大白话就是线下机房不能调线上机房（玩法类似于我高中时的小灵通，就是只能拨本市的号码，异地恋是不可能的），这预示着什么？

预示着热更新不可用，本地调不可行？改一行代码，就需要去预发环境（预发环境属于线上机房）部署一次(> 5min), 然后调一下刚刚部署的接口，发现不对，然后又改一行代码，又部署，又调，不断重复！！！Seriously？？？

文章图片

可能你现在想知道，是哪个平台商提供了这个API, 悄悄告诉你, 算了，你还是自己看吧：https://help.aliyun.com/docum...
花式调接口 postman 是一个好工具，但有时postman也可能力不从心(postwoman也一样)，比如今天要讲的机房内调用。
所以，下面讲到的招式，可能常规前端开发不一定遇得到，也不一定用得上，但看一看又不要钱，万一赚了喃。
招式1：动态传参
通常我们调服务端API接口不通，通常只有两种情况：

服务端傻逼，写了一个根本调不通的接口（我这里不存在，因为传说是通的，至少他向我证明了网关是通的）；

文章图片
前端傻逼，参数没按照指示来

所以，我默认按我是傻逼的方案来做，就是服务端的入参，我都通过我的接口动态传上去，哪不对我就改哪里，听起来可能有点懵逼，我画个图：有点草率。

文章图片

但事情，原没有我想的那么简单，我确实懵逼了，因为这个接口，远不是入参正确就能调通那么简单。
因为我还得md5计算正确、请求头设置正确、签名正确;
而这些请求头也需要动态改变，不过这时我灵光乍现：上面这个防止自己傻逼方案, 和接口代理有什么区别, 所以我顿时有了方案2：接口代理
方案2：接口代理
【伪前端花式调接口】proxy, 前端可能都不陌生，webpack-dev-server 就有这个功能，多是用来解决接口跨域。所以，我何必要什么动态传参，我直接加个代理不更简单，所以方案是这样的：

文章图片

两行代码搞定：

// plugin.js加入插件 export const httpProxy = { enable: true, package: 'egg-http-proxy', }; // config.js 加入配置 config.httpProxy = { '/aapi': { target: 'http://api-gateway.test.com', pathRewrite: {'^/aoneapi' : ''} } };

这个方案，听起来很美好，热更新有了，线下调试有了；但由于我们平台底层有一些中间件，所以当目标平台响应了400 或 401，我们平台(node-server) 就会拦截，返回一个302重定向, 这就会导致我看不到目标平台真实的错误响应，但改底层拦截改动很大，也会影响到其他同事的开发。
方案3: 远程server直接调
鉴于前面的curl尝试, 证明最直接的接口调用，最短的链路，可以避免最少的错误

curl -v -X GET http://test.goaway.com/checkpreload -H 'Authorization: APPCODE f7f526fd3adf2f38d46'

因为NodeJs 是脚本语言，区别于Java这种编译型语言。这时候好处就体现了，考虑到服务器上有源代码，那就可以直接通过 node 命令去唤起接口调用, 所以现在链路变成了这样：

文章图片

我在我的仓库中加入了一个文件（test.js），伪代码：

const rp = require('request-promise'); const { createHash, createHmac } = require('crypto'); async function handle(str = []) { // 省去具体实现 }// 获取请求相关数据 const arg = process.argv.slice(ArgStart); handle(arg);

所以当我把代码部署上去时，我就可以运行node test.js ..., like:

文章图片

这样执行一下，我能自定义响应体，可以看到请求头是否符合规范，错误发生时可以清楚看到错误响应；最重要的，当我知道错误时，我可以直接在服务器上编辑代码，然后再接着运行命令测试，这样时间就大大节省了。这一切的实现，都归功于NodeJs一门脚本语言!!!

文章图片

分享个知识: md5 这一次调试，我的卡点可以大概纠结于四个阶段：

机房隔离，网络不通
Invalid md5
Invalid signalture
Authentication error since of operator not configured according to ak

卡的时间最久的，就是Invalid md5；由于最开始官方了提供了SDK，里面提供了md5计算方法：

static getContentMD5(body) { const hash = crypto_1.createHash('md5'); hash.update(body); return hash.digest('hex'); }

但问题，就出在这，这个MD5计算和官方文档提到的不一致：
可以看出，在经过md5计算后，又用base64的方式进行了编码。
而官方SDK提供的只需要如下修改一下，就可以获得一致的结果：

static getContentMD5(body) { const hash = crypto_1.createHash('md5'); hash.update(body); return hash.digest('base64'); }

那digest方法这个入参到底有什么机密？
细品digest入参
NodeJs官方文档
在crypto:0.1.92版本，入参的typescript是这样定义的；

type BinaryToTextEncoding = "base64" | "base64url" | "hex"

除了上面这三个参数(在0.1.94版本，已经没有base64url选项)，其实这个入参还能为空, 为空时返回Buffer, 否则返回string, 所有在日常场景入参都是存在的，因为我们拿着一个Buffer 意义不大，当对hello world做md5计算时，得到的buffer是:
那为什么不直接用Buffer，因为对象不利于传输!!!
base64 vs hex
又可以理解为base64 vs base16；
所以当我们传入hex时，达到的结果是：fc3ff98e8c6a0d3087d515c0473f8677，这个结果正好就是上面的buffer字符串化。
而传入base64, 得到的结果是：/D/5joxqDTCH1RXARz+Gdw==
因为Buffer 本身是由一串串16进制数组成的，所以转为hex，就会很容易，而转成base64，就需要再编码

关于base64编码：网络上传输的字符并不全是可打印的字符，比如二进制文件、图片等。Base64的出现就是为了解决此问题，它是基于64个可打印的字符（A-Z、a-z、0-9、+、/）来表示二进制的数据的一种方法；转码过程：首先将待转换的字符每三个字节分为一组，每个字节占8bit，那么共有24个二进制位,然后将二进制位每6个一组分为4组。在每组前面添加两个0，每组由6个变为8个二进制位，总共32个二进制位，即四个字节。最后根据Base64编码对照表获得对应的值(位数不足情况：当位数从8bit转化6bit时，不完整的6bit中用0填充，无对应6bit的8bit向后直接用=填充
这里粗略做个变换，hex结果是32个字符，每个字符为4个二进制数

第一步: 转化为二进制数：1111-1010-0011.....-0111-0111(32 * 4 = 128)第二步：转化为6个bit为一小组，然后三个一大组： 111110-100011-.....-011101-11（7 * 3 * 6 + 2）第三步：补0，补=：00111110-00100011-....-00011101-00110000-=-= 第四步：对照表转字符：/-D-....-d-w-=-=

至少头尾是一致的，套路应该没啥问题。
至于何时用base64, 何时用base16; 对于md5计算，这个主要看服务端心情！但对于大字节流，比如文件，图片的传输，都会选用base64, 因为这可以节省流量，提高传输效率。
那base64Url 又是什么? base64Url 又称为安全的Base64，和 base64的区别仅仅在于63号和64号字符的转换上；

文章图片

由于"/"，"="等是URL中的保留字符或不安全字符，因此如果直接在URL中传输Base64编码，保留字符和不安全字符会被替换为%XX的形式，对后端来说解码不方便。如果不替换，就会造成URL注入漏洞。所以 base64Url 其目的在于解决+、\、=在url的传输问题。
结尾写个文章也要有个仪式感，不能虎头蛇尾，这里就结尾感叹一声吧：做个前端好难！！！