创建成熟的 API 需要资源，包括时间和金钱。你需要考虑模型、设计、REST 原则等方面的东西。大多数情况下，你不知道这样做是否值得：你只是想要做出一个最小可行性产品，然后基于这个产品开始迭代。现在，我想向你展示如何在不编写一行代码的情况下实现它。
解决方案
解决方案的主要要求是使用 PostgreSQL 数据库，这是一个功能完善的开源 SQL 数据库。
我们不编写 REST API，而是使用 PostgREST 组件。
PostgREST 是一个独立的 Web 服务器，可以将 PostgreSQL 数据库直接转换成 REST API。数据库的结构约束和权限决定了 API 有哪些端点和操作。
—— PostgREST 官网
我们将在一个简单的场景中使用它。下面是一张我想通过 CRUD API 暴露出来的 product 数据表。
PostgREST 的入门指南（https://postgrest.org/en/stable/tutorials/tut0.html）提供了完整的内容，不过我没有找到现成的 Docker 镜像，所以自己创建了一个。
Dockerfile：
基于最新的 Debian。
参数化构建。
获取二进制包。
安装依赖项并解压二进制包。
Docker 镜像的/postgrest 文件夹中有一个 postgrest 可执行文件。我们可以通过 Docker Compose 来“部署”。
docker-compose.yml：
构建上面的 Dockerfile。
共享配置文件。
运行 postgrest 可执行文件。
使用配置文件。
初始化 Schema、权限和数据。
这个时候，我们可以查询 product 表：
我们会立即得到结果：
真是立竿见影！
改进解决方案
虽然这个解决方案是有效的，但还有很大的改进空间。例如，虽然用户不能修改数据，但每个人都可以访问到它。对于产品相关的数据，这可能不是一个大问题，但对于医疗数据呢？
PostgREST 文档提到了这个问题，并明确建议使用反向代理：
PostgREST 是快速构造 REST API 的一种方法，默认情况下非常适合用于构建开发脚手架。它也可以进入到生产环境，只要你需要采取一些预防措施。PostgREST 只是一个用于实现 API 到数据库映射的小工具，我们需要依靠像 Nginx 这样的反向代理来提供额外的安全性保障。
—— PostgREST 官网
不过我们没有使用 Nginx，而是一个成熟的 API 网关——Apache APISIX。我们把它添加到 Docker Compose 中。
docker-compose.yml
使用 Apache APISIX。
APISIX 将配置存储在 etcd 中。
我们先配置 Apache APISIX，用它来代理对 postgrest 的调用：
应该运行在其中一个 Docker 节点上，因此使用 Docker 镜像名称。或者也可以使用 localhost，但一定要公开端口。
创建可重用的上游。
指向 PostgREST 节点。
创建到上游的路由。
现在，我们可以通过 APISIX 来查询端点：
它返回与之前相同的结果。
DDoS 攻击保护
我们还没有加入任何东西，不过我们已经做好准备了。我们首先需要保护 API 免受 DDoS 攻击。Apache APISIX 是基于插件架构而设计的，为了防止 DDoS 攻击，我们将使用一个插件。我们可以在创建路由时设置插件，也可以在每个路由上设置插件。如果是第二种情况，就变成了全局规则。我们希望默认保护每一个路由，因此我们将使用第二种方式。
limit-count 限制一个时间窗口内的调用次数。
限制为每 5 秒调用 1 次，这只是为了演示。
返回“429 Too Many Requests”，默认值为 503。
现在，如果我们发送了太多请求，Apache APISIX 会保护上游：
路由授权
PostgREST 还提供了一个 root 的 Open API 端点，因此我们有两个路由：/用于遵循 Open API 规范，/product 是产品的相关端点。假设我们想禁止未经授权的人访问我们的数据，即普通用户可以访问产品信息，admin 用户可以访问 Open API 规范和产品信息。
APISIX 提供了几种身份验证方法。我们将使用最简单的 key-auth。它依赖了消费者抽象，key-auth 需要一个特定的标头：插件对标头中的值进行反向查找，并找到对应的消费者。
下面演示如何创建一个消费者：
创建新的消费者。
消费者的名字。
消费者的键值。
我们也为消费者 user 和键 user 做同样的事情。现在，我们可以创建一个路由并配置它，只让来自 admin 的请求通过：
创建一个新的路由。
使用 key-auth 和消费者限制插件。
只有管理员认证的请求才能调用路由。
我们来尝试一下：
无法调用，因为我们没有通过 API 标头进行身份验证：
也无法调用，因为我们使用了 user 的身份，但路由只授权给了 admin 身份。
这一次，它像预期的那样返回 Open API 规范。
监控
任何一个软件系统都有一个被低估的特性，那就是监控。在将组件部署到生产环境中后，我们就必须监控其运行状况。现在，我们有许多服务可用于监控。我们将使用 Prometheus，因为它是开源的，经过了实战的考验，并已被广泛使用。为了显示监控数据，我们将使用 Grafana。我们把组件添加到 Docker Compose 文件中。
docker-compose.yml
Prometheus 镜像。
Prometheus 的配置。可以在这里（https://github.com/ajavageek/poor-man-api/blob/master/prometheus/prometheus.yml）查看完整的文件。
Grafana 镜像。
Grafana 的配置。其中大部分来自 APISIX 提供的配置（https://github.com/apache/apisix/blob/master/docs/assets/other/json/apisix-grafana-dashboard.json）。
将默认端口 3000 改为 3001，避免与 PostgREST 服务冲突。
有了监控基础设施之后，我们只需要 APISIX 按照 Prometheus 期望的格式提供数据即可。我们可以通过配置和一个新的全局规则来实现。
config.yaml
绑定到任意地址。
绑定到 9091 端口。Prometheus 的指标信息可参考http://apisix:9091/apisix/prometheus/metrics。
我们可以创建全局规则：
发送几个查询并打开 Grafana 仪表板，看起来应该像这样：
结论
创建一个完整的 REST API 是一项巨大的投资。我们可以通过 PostgREST 将数据库暴露成 CRUD API，进行快速简单的测试。当然，这样的架构并不适用于生产环境。
要解决这个问题，我们需要在 PostgREST 前面设置一个门面，可以是反向代理或 API 网关。Apache APISIX 提供了很多特性，包括授权和监控等。有了它，我们就可以用较低的成本快速验证 API 需求。
在验证了需求后，我们可以保留现有的门面，并用定制开发的 API 替换 PostgREST。
这篇文章相关的完整源代码可以在 Github（https://github.com/ajavageek/poor-man-api）上找到。
原文链接：
https://blog.frankel.ch/poor-man-api/
推荐阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论