使用 Whistle 作为 API 服务网关

最近写了一款 React 的工具，能拉取团队成员 Jira 上的 Task 和 Bug，根据其 Task 的 Efforts 时长和 Bug 的修复时长，计算对应的绩效指标。

今天给大家介绍下，我是如何在这个项目中利用 Whistle 来实现 API 服务网关的（还不知道 Whistle ？看这里）。

在项目开发过程中，前端本地的 webpack 会启动服务并监听一个端口（例如 8000），浏览器访问 http://localhost:8000 即可进行页面的开发预览。

假如你的 Jira 站点为 https://jira.example.com ，此时，需要浏览器能直接对 Jira 的 Rest API 服务（https://jira.example.com/rest/api/）发起请求。

1. CORS 合法化配置

当浏览器向与当前页面域名不同的域名发起 API 请求时，会触发 CORS 策略，以确保请求是被目标服务所允许的。

本地开发时的域名是 localhost，API 服务是 example.com，所以会触发 CORS 及其 Preflight Request 策略。

CORS Error

Whistle 提供了 resCors 协议可以很方便的为 response 加上 CORS 相关的 Header（Access-Control-Request-* ）。

如下图配置，我们可以设置允许来源 origin 为任意站点（*），允许自定义 Header Authorization 和 Content-Type 的使用：

https://jira.example.com/rest/api resCors://{resCorsTest.json} delete://req.headers.User-Agent

```resCorsTest.json
{
"origin": "*",
"headers": "authorization,content-type",
}
```

同时，我们还使用 delete 协议删除了请求头中的 UA 头信息（req.headers.User-Agent），让 API 服务无法判断出请求的发起方是否为浏览器（注意：Jira Rest API 会针对浏览器开启 XSRF Check）。

2. HTTP Header/Body 的过滤与修改

CORS 合法化配置完成后，浏览器已经可以成功发起跨域 API 请求，但在 console 控制台中，还有上图中的黄色 warning 需要消除。

这个 warning 的原因在于，options 请求的响应头中设置了 X-Content-Type-Options: nosniff，我们可以使用 includeFilter 针对 options HTTP Method，删除掉这个 Header：

https://jira.example.com/rest/api includeFilter://m:options delete://res.headers.X-Content-Type-Options 

如有需要，我们还可以利用 headerReplace 将某个 Header 替换成其他的值，以及使用 resBody 来设置 response 的 body 内容：

https://jira.example.com/rest/api headerReplace://res.Content-Type:/.*/=application/json resBody://({}) 

3. 同域网关

事实上，Whistle 作为代理网关，可以更加方便的绕过 CORS 策略限制。

我们只需为我们的静态页面和 API 服务设置一个相同的自定义域名，然后全部交给 Whistle 即可。

假如这里我们的自定义域名为：http://my.jira.com ，我们只需把对 http://my.jira.com/rest/api 的访问转发到 https://jira.example.com/rest/api 即可：

http://my.jira.com/rest/api https://jira.example.com/rest/api delete://headers.User-Agent
http://my.jira.com 127.0.0.1:8000

（注意：/rest/api 需要配置在前面，确保优先命中）

由于 Rest API 的域名和当前页面设置为同域，所以不会产生 CORS 与 Preflight Request 限制。

在本地开发完成后，我们可以使用 file 协议，直接将自定义域名映射到静态文件目录上。另外，由于需要在 JS 代码中隐藏 Jira HTTP 鉴权的用户名和密码，我们可以通过 auth 协议将这部分信息配置在 Whistle 网关中。以下是完整配置：

http://my.jira.com/rest/api https://jira.example.com/rest/api delete://headers.User-Agent auth://your-username:your-password 
http://my.jira.com file:///path/to/your/project/dist/

同域网关除了以上这种配置外，还有另外一种逆向思路：

将静态页面域名配置成实际的 API 服务域名，借助 xfile 协议，我们可以将未命中的请求全部转发到实际的线上服务，只需以下一行配置：

https://jira.example.com/ xfile:///path/to/your/project/dist/

需要注意的是，以上这种方法需要安装 Whistle CA 证书，用于解析 HTTPS 协议。

怎么样？把 Whistle 作为 API 服务网关，而不需要使用 Node 或 Nginx 服务来转发，是不是既简单又方便？赶紧试试吧：）