企业里做 API，最耗时间的往往不是写代码本身，而是反复搭骨架、调参数、写文档、做鉴权、再部署运维。PingAPI 5.0 把这条链路压缩成可视化配置 + AI 辅助，核心思路是：数据已经在那里了，为什么还要手写每一个接口？
5.0 版本最大的变化是明确了四种开发模式——SQL、Table、Proxy、编排——对应从最简单的单表 CRUD 到跨服务多步编排的全谱系需求。下面逐个拆开看。
SQL 模式：一句 SQL 直接出接口
最直接的场景：数据库里有一张表，前端需要一个查询接口。传统做法是写 Controller → Service → Mapper → XML，PingAPI 的 SQL 模式跳过全部中间层。
配置过程：选数据源 → 写 SQL → 配置入参出参映射 → 在线调试 → 发布。AI 在这一步主要做两件事——根据表结构推荐参数类型，以及自动生成接口文档的描述字段。
一个典型的 SQL 模式配置大致如下（以 MySQL 数据源为例）：
-- PingAPI SQL 模式中的查询语句
SELECT
order_id,
user_name,
total_amount,
created_at
FROM orders
WHERE status = :status
AND created_at >= :start_date
ORDER BY created_at DESC
LIMIT :page_size OFFSET :offset
在 PingAPI 界面中，:status、:start_date、:page_size、:offset 会自动被识别为入参，你可以逐个设定类型、默认值和校验规则。调试面板直接填参数跑一遍，返回结果确认后一键发布，接口地址类似 /api/v1/orders/query。
适合场景：报表查询、数据导出、运营后台列表接口——凡是"写 SQL 就能搞定"的，没必要再走三层架构。
Table 模式：零代码 CRUD 一键生成
SQL 模式还要写语句，Table 模式更彻底——选一张表，平台自动生成增删改查四个接口，包含分页、字段过滤、主键定位。
配置过程：选数据源 → 选表 → 勾选需要生成的操作（list / get / create / update / delete）→ 调整字段可见性和校验规则 → 发布。
# Table 模式生成的接口配置示例（PingAPI 导出格式）
table_api:
datasource: mysql_prod
table: products
operations:
- list:
pagination: true
default_page_size: 20
filterable_fields: [category, status, price]
- get:
lookup_field: id
- create:
required_fields: [name, price, category]
auto_fill:
created_at: NOW()
created_by: CURRENT_USER
- update:
updatable_fields: [name, price, status, description]
- delete:
soft_delete: true
delete_field: is_deleted
auth:
list: [anonymous]
create: [admin, operator]
update: [admin, operator]
delete: [admin]
注意几个细节：auto_fill 让平台自动注入时间戳和当前用户，soft_delete 把物理删除变成逻辑删除，auth 按操作粒度控制权限。这些在传统开发里每个接口都要重复写的逻辑，Table 模式一次配置全部覆盖。
适合场景：后台管理系统的标准 CRUD、移动端的数据同步接口、快速原型阶段的数据支撑。
Proxy 模式：不碰后端，直接转发
很多时候你不需要新建接口，只需要把已有服务包装一下——加鉴权、限流、缓存、字段裁剪。Proxy 模式就是干这个的。
配置过程：填上游服务地址 → 设定请求方法与路径映射 → 配置中间件链（鉴权 → 限流 → 缓存 → 响应裁剪）→ 发布。
# 用 PingAPI CLI 快速创建一个 Proxy 接口（5.0 新增命令行支持）
pingapi proxy create \
--name "user-profile-proxy" \
--upstream "https://internal-service.company.com/api/users/profile" \
--path "/api/v2/user/profile" \
--method GET \
--middleware "auth.jwt,rate-limit.100/min,cache.ttl.300s,response-filter.fields=id,name,email,avatar"
# 发布到网关
pingapi publish --api "user-profile-proxy" --env production
这个例子把内部服务的用户资料接口对外暴露，同时加了 JWT 鉴权、每分钟 100 次限流、5 分钟缓存、只返回四个字段。上游服务完全不需要改动。
适合场景：内部服务对外暴露、第三方 API 加壳代理、旧系统接口适配新规范。
编排模式：多步串联，一个接口搞定复杂业务
前面三种模式处理的是单数据源、单服务的场景。编排模式才是 PingAPI 区别于普通低代码平台的地方——它把多个 API 调用、数据转换、条件分支串成一个流程，对外只暴露一个接口。
典型流程：校验参数 → 调服务 A 获取基础数据 → 根据结果调服务 B 或 C → 合并响应 → 返回。
// 编排模式流程定义示例
{
"orchestration": "order-create-flow",
"steps": [
{
"id": "validate",
"type": "script",
"script": "return ctx.params.user_id && ctx.params.items.length > 0;"
},
{
"id": "check_stock",
"type": "api_call",
"api": "inventory-check",
"input": { "items": "{{ctx.params.items}}" },
"next": {
"success": "lock_stock",
"fail": "return_error"
}
},
{
"id": "lock_stock",
"type": "api_call",
"api": "inventory-lock",
"input": { "items": "{{ctx.params.items}}" },
"next": "create_order"
},
{
"id": "create_order",
"type": "api_call",
"api": "order-create",
"input": {
"user_id": "{{ctx.params.user_id}}",
"items": "{{ctx.params.items}}",
"total": "{{ctx.steps.check_stock.output.total}}"
}
},
{
"id": "return_error",
"type": "response",
"status": 400,
"body": { "message": "库存不足" }
}
],
"output": {
"order_id": "{{ctx.steps.create_order.output.order_id}}",
"total": "{{ctx.steps.check_stock.output.total}}"
}
}
步骤间通过 {{ctx}} 上下文变量传递数据，next 字段控制分支走向。AI 在编排模式中会根据你描述的业务意图推荐步骤顺序和参数映射，减少手动拼流程的试错成本。
适合场景：下单流程、审批链路、跨系统数据聚合——任何"前端调三个接口再拼数据"的痛点，编排模式都能收成一个调用。
从开发到运维：5.0 补齐了后半段
四种模式解决了"怎么造接口"，5.0 还补上了"怎么管接口"：
- 在线调试：每个模式都有调试面板，填参数直接看返回，不用再开 Postman。
- 版本管理：接口配置有版本记录，发布前可对比差异，回滚一键完成。
- 文档自动生成：参数类型、校验规则、示例值从配置中直接提取，AI 补充自然语言描述。
- 运维监控：发布后的接口有调用统计、错误率、响应时间面板，限流和熔断规则在 Proxy 和编排模式中直接配置。
实践建议：怎么选模式、怎么落地
| 需求特征 | 推荐模式 | 理由 |
|---|---|---|
| 单表增删改查 | Table | 零配置生成，最快 |
| 自定义查询/报表 | SQL | 灵活控制查询逻辑 |
| 包装已有服务 | Proxy | 不改上游，加壳即可 |
| 跨服务多步业务 | 编排 | 一个接口替代前端多次调用 |
落地路径建议：
- 先从 Table 模式切入——挑一个后台管理的 CRUD 模块，用 Table 模式生成，对比手写接口的开发耗时，团队会快速建立信心。
- Proxy 模式接旧系统——正在迁移的老服务，先用 Proxy 加壳暴露新规范接口，内部逐步重构，对外无感。
- 编排模式留给核心链路——下单、支付、审批这些高频且跨系统的流程，收益最大，但也最需要仔细设计步骤和异常分支。
- AI 辅助当建议看，不要盲信——参数推荐和文档描述可以采纳，编排流程的步骤顺序一定要人工复核业务逻辑。
PingAPI 5.0 的价值不是"取代程序员"，而是把重复的骨架工作压缩到配置层，让开发者把时间花在业务逻辑本身。四种模式的分层设计意味着你可以按复杂度选工具，不必一开始就跳进最重的编排模式。先跑通一个 Table 模式的 CRUD，再逐步往复杂场景走，是最稳的路径。