ApiGo 5.1.0：把 SQL 直接变成可管可控的 API

预计阅读时间：9 分钟

做后台开发，最重复的工作之一就是：写 SQL → 写 Controller → 写 Service → 写权限校验 → 发布接口。一个简单的查询接口，从建表到上线可能要折腾半小时。ApiGo 这个项目想做的事情很直接——在线写 SQL，一键发布成 REST API，顺带把数据源管理、权限、上下线这些运维动作也收进来。

5.1.0 版本最大的变化是项目从 crabc-api 正式更名为 ApiGo，同时数据源支持和标签能力继续扩展。下面拆开看它到底能做什么，以及怎么上手。

SQL2API：核心能力拆解

ApiGo 的核心流程可以概括为三步：

配数据源——在管理后台注册一个 MySQL、Oracle、达梦、TiDB、DolphinDB、Hive 或 Elasticsearch 连接，动态加载，不需要重启服务。
写 SQL——在可视化编辑器里写查询语句，支持动态标签（类似 MyBatis 的 <if>、<where>），可以根据请求参数动态拼接条件。
发布接口——保存后一键上线，外部通过 REST 地址直接调用，返回 JSON；不需要再写一行 Java 代码。

这意味着什么？对于内部报表查询、数据预览、运营后台这类"读多写少、接口逻辑简单"的场景，开发周期可以从天级压缩到分钟级。

动态标签：让 SQL 不再是死字符串

静态 SQL 只能查固定条件，真实业务几乎都需要根据入参动态过滤。ApiGo 的标签语法类似 MyBatis XML，但直接嵌在在线编辑器里：

SELECT
    order_id, user_name, amount, create_time
FROM
    t_orders
WHERE
    status = 'PAID'
    <if test="userName != null">
        AND user_name = #{userName}
    </if>
    <if test="startDate != null">
        AND create_time >= #{startDate}
    </if>
    <if test="endDate != null">
        AND create_time &lt;= #{endDate}
    </if>
ORDER BY create_time DESC

调用方传 userName=张三&startDate=2024-01-01，标签层会自动裁剪掉为空的分支，只拼出实际需要的 WHERE 子句。这样既避免了 SQL 注入风险（参数是预编译绑定），又不用为每种查询组合各写一个接口。

多数据源与 NoSQL：不止是 MySQL

5.1.0 支持的数据源列表已经覆盖了主流关系型和几种 NoSQL：

类型	支持的数据源
关系型	MySQL、Oracle、达梦、TiDB
大数据/时序	Hive、DolphinDB
搜索引擎	Elasticsearch

同一个平台里可以同时挂多个数据源，接口配置时指定使用哪个连接池。对于需要跨库查询再统一输出的场景（比如业务库是 MySQL、日志在 ES、分析走 Hive），不用再各自搭服务再聚合，一个平台直接配三个源、各写一条 SQL、分别发布三个接口就行。

快速上手：从零发布一个查询接口

以下是一个最小化启动示例，基于 ApiGo 的 Spring Boot 后端。假设你已经有一个可用的 MySQL 库。

第一步：拉代码、改配置

git clone https://github.com/apigo-api/apigo.git
cd apigo

修改 src/main/resources/application.yml 中的数据库连接（ApiGo 自身元数据存储用的库）：

spring:
  datasource:
    url: jdbc:mysql://127.0.0.1:3306/apigo_meta?useSSL=false&characterEncoding=utf8
    username: root
    password: your_password
    driver-class-name: com.mysql.cj.jdbc.Driver

第二步：启动服务

mvn clean package -DskipTests
java -jar target/apigo-5.1.0.jar

启动后访问 http://localhost:8080 进入管理后台。

第三步：注册业务数据源

在后台「数据源管理」页面新增一个 MySQL 连接，填写你业务库的 JDBC 地址、用户名、密码，保存后即时生效，无需重启。

第四步：写 SQL 并发布

进入「接口管理」→ 新增接口，选择刚才注册的数据源，在 SQL 编辑器里写入：

SELECT id, title, author, publish_time
FROM t_articles
WHERE status = 'PUBLISHED'
ORDER BY publish_time DESC
LIMIT #{pageSize}

设置接口路径为 /api/articles，请求方式为 GET，点击「上线」。

第五步：调用验证

curl "http://localhost:8080/api/articles?pageSize=10"

返回的就是 JSON 格式的文章列表。整个过程没有写 Controller、没有写 Service、没有编译部署——从 SQL 到可调用 API，几分钟完成。

接口生命周期管理

ApiGo 把接口当作可运维的资源来管，几个关键动作：

一键上下线：接口有问题时直接下线，外部调用立即返回禁用提示，不需要改代码或重启服务。
权限控制：每个接口可以配置访问权限，支持 Token 验证、角色白名单，避免裸接口暴露在公网。
代理三方接口：不只是自建 SQL 接口，还可以把已有的外部 HTTP API 代理进来统一管理，对外只暴露 ApiGo 的统一地址和鉴权。

这套机制对内部平台尤其有用——几十个数据查询接口散落在各处，谁建的、谁有权用、哪个还活着，往往一团乱。收进 ApiGo 之后，上线状态、调用权限、数据源归属一目了然。

适用场景与边界

ApiGo 最适合的场景：

内部数据查询/报表接口——逻辑简单、读多写少，SQL 就是核心。
多源数据统一出口——MySQL + ES + Hive 混合环境，需要统一鉴权和路由。
快速原型/临时需求——运营临时要拉一组数据，几分钟配一个接口交付。

不太适合的场景：

复杂业务逻辑接口——涉及多步事务、跨服务编排的，SQL2API 的抽象层不够用，还是得写代码。
高并发写入接口——动态 SQL + 通用执行引擎的性能天花板低于手写优化过的专用服务。
严格合规审计要求——金融级审计可能需要更细粒度的操作日志和变更追踪，开源版需要二次开发补充。

上手建议

如果你正在维护一堆"查个表返回 JSON"的内部接口，可以拿一个最简单的查询场景试跑：本地起一个 ApiGo，挂一个 MySQL 源，把现有的一条查询 SQL 照搬进去上线，对比一下原来那条接口的开发和维护成本。体验过 SQL→API 的速度之后，再决定要不要把更多数据源和接口迁进来。

项目地址：https://github.com/apigo-api/apigo，5.1.0 版本的更名意味着后续迭代会以 ApiGo 的品牌推进，旧版 crabc-api 用户注意依赖包路径的变更。