Lite API：重新思考 Java API 开发

这段时间，我一直在思考一个问题：

Java Web 开发为什么越来越重？

一个简单接口，往往需要：

• Controller

• Service

• ServiceImpl

• Mapper

• Entity

• DTO

• VO

• XML

• Swagger

大量时间消耗在：

• 结构搭建

• 模板代码

• CRUD

• 对象转换

而真正的业务代码，占比其实并不高。

于是，我尝试做了一套不同思路的 API 开发框架：

Lite API

一个基于 JFinal 的轻量级 API 敏捷开发框架。

---

Lite API 的核心理念

Lite API 的核心理念非常简单：

API 应该是“描述”出来的，而不是由大量 Java 类“堆”出来的。

因此，Lite API 采用：

• XML 定义 API

• Script 实现逻辑

• Runtime 动态加载

例如：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<api-group id="hello" name="Hello APIs" path="/doc/hello">
    <api id="world" method="GET" name="Hello World" path="/world">
        <script><![CDATA[
            return 'Hello, World!';
        ]]></script>
    </api>
</api-group>

即可直接生成：

GET /doc/hello/world

无需：

• Controller

• Service

• Dao

• Mapper

---

为什么选择 XML？

很多框架倾向于：

• Annotation

• YAML

• JSON

Lite API 最终选择 XML，主要有几个原因。

---

1. XML 更适合 DSL

API 本身具有明显层级结构：

• group

• api

• request

• response

• cache

• auth

XML 在结构表达上天然具备优势。

未来也更容易扩展为：

<cache />
<page />
<auth />
<tx />

这种 DSL 形式。

---

2. 更适合动态加载

Lite API 支持：

• 热更新

• 动态编译

• 无需重启

XML 在动态配置场景中更加稳定。

---

3. 更适合 API Engine 化

Lite API 并不想成为：

“另一个 SpringBoot”。

它更偏向：

API Runtime Engine。

因此：

• 配置驱动

• 动态执行

• Runtime 解析

会比 Annotation 更自然。

---

Lite API 的主要特性

零编码 API 开发

很多接口不需要写 Java 类。

直接：

<script>
return db.select(...)
</script>

即可完成业务。

---

基于 JFinal 5.x

Lite API 基于 JFinal 构建。

选择 JFinal 的原因：

• 极简

• 启动快

• 性能高

• 没有复杂 IOC 容器负担

非常适合作为 Runtime API Engine。

---

动态脚本支持

基于 Magic-Script：

• 热更新

• 即时生效

• 动态执行

适合：

• 中后台

• 内部平台

• 低代码系统

• API 聚合

---

多数据源

支持：

• MySQL

• PostgreSQL

• Oracle

• SQLServer

• MariaDB

支持在线动态配置数据源。

---

SQL 缓存

支持：

• SQL Cache

• 自定义缓存

• 热点数据缓存

减少数据库压力。

---

Lite API 更适合什么场景？

目前比较适合：

1. 中后台 CRUD 系统

大量标准接口。

---

2. API 聚合层

统一接口出口。

---

3. 低代码平台

动态生成接口。

---

4. AI Agent Backend

未来 AI 调用后端：

更偏向：

• 动态 API

• 配置式 API

• Runtime API

而不是传统 Controller 架构。

---

和 SpringBoot 的区别

SpringBoot：

@RestController

本质是：

Java 对象驱动。

Lite API：

<api />

本质是：

API DSL 驱动。

两者并不是简单替代关系。

更像：

• 工程化框架VS

• Runtime API Engine

---

当前方向

目前 Lite API 仍在持续演进。

后续计划：

• OpenAPI 支持

• API 文档生成

• 权限体系

• API 编排

• 分布式缓存

• AI Function Calling 支持

---

最后

我一直觉得：

很多业务系统，并不需要那么“重”。

Lite API 更像是一次尝试：

让 API 开发：

从“写模板代码”，回到“描述业务本身”。

欢迎交流与建议。