引言：为什么是 Web API + JSON + 报表

在 SaaS、ERP / MES / CRM 等系统中，业务数据往往已经通过 HTTP 接口以 JSON 形式暴露。传统 BI 要分析这些数据，通常先 ETL、建数仓、再建模；而 Wyn 这类嵌入式 BI 可直接对接 Web API / JSON 数据源，实时消费业务接口，省掉 ETL 与中间数仓。

本文是《如何通过 JSON 数据源 / Web API 快速构建轻量级 Dashboard？》的姊妹篇。两篇文章共用同一套"JSON/Web API 数据接入"方法论，本文聚焦报表（Report）与仪表板（Dashboard）的差异点：数据准备方式不同、参数机制不同、输出形态不同。读本文前建议先读 Dashboard 篇。

一图看懂：报表数据接入流程

一、为什么需要报表，而不仅是仪表板？

Web API + JSON 的组合，最大的价值是让 BI 工具直接消费业务系统实时暴露的接口，省掉 ETL 与中间数据仓库的建设。在上篇文章里，我们用它构建了"实时看数"的仪表板；但在真实业务里，还有一类需求是仪表板解决不了的：

• 结构化单据与正式文档：对账单、采购单、发货单、工单、发票、合同附件——它们需要按固定格式、分页、可打印、可导出 Word/Excel/PDF；
• 精确的条件查询与套打：用户输入一个单号或时间段，系统返回这张单据的完整明细，而不是一堆图表；
• 批量归档与分发：财务月报、合规报表，需要定时生成、统一版式。

这正是报表的立足点。仪表板回答"现在整体情况怎样"，报表回答"这笔/这批业务的具体凭证是什么"。

二、核心差异速览（读这篇前先看清）

三、实战：四步完成一个 Report

下面以一个公开 Web API 为例。

示例接口：https://jsonplaceholder.typicode.com

整个过程只需要三步。

Step 1 创建 JSON 数据源

进入文档门户 → 工作空间 → 数据源，点击创建数据源，选择JSON，源类型选择网络，然后填写基准地址，端点地址和对应的参数。

例如：

配置完成后，可以直接预览接口返回的数据。如果字段正常识别，就说明连接成功。

JSON 数据源配置流程图

Step 2 创建数据集

Report仅可以使用数据集，针对JSON API数据，为了让其动态参数值传递，只能使用直连数据集完成数据准备，将对应的数据集数绑定到数据源参数。

Step 3 创建 Report

数据准备完成后，就可以开始设计Report，整个过程几乎都是拖拽完成。在Report设计器中把字段拖进去即可生成图表，然后在配置联动，筛选，参数等，几分钟就可以完成一个可交互的仪表板。

Step 4 发布与嵌入业务系统

Report设计完成后，需要保存和发布审批。随后即可：

• 分享链接
• Portal 查看
• iframe 嵌入
• 集成到业务系统

对于 SaaS 产品来说，这一步尤其重要；因为 Report不需要单独部署；可以直接作为业务系统的一部分进行展示。

四、报表参数 vs 仪表板参数（核心差异点）

这是读者最容易踩坑的地方，单列一节对比。

一个最小可运行示例：

• 数据源 URL，携带参数：https://jsonplaceholder.typicode.com/users?id=@id
• 创建直连数据源，添加用户输入的参数id，类型=整数，默认值=1；将其绑定到数据源的参数
• 在报表设计器里选择该直连数据集，系统会自动创建一个和直连数据集参数同名的报表参数
• 设计报表内容，预览时修改报表参数 id，报表会带着新参数重新请求 API，渲染出对应用户的明细——这就是"参数驱动取数"，和仪表板"参数过滤已加载数据"本质不同

五、适用场景：什么时候用报表，什么时候用仪表板？

• 用仪表板：经营驾驶舱、实时监控大屏、自助探索分析、IoT 设备状态——强调"看趋势、看整体、可交互"。
• 用报表：对账单、工单、发票、采购单、合规月报、合同附件——强调"出单据、可打印、精确查询、正式归档"。

两者在 Wyn 里可以共用同一批直连数据集和同一套 Web API 接入范式，只是数据准备类型和参数不同。

六、小结

本文承接 Dashboard 篇，补全了"从 JSON/Web API 接入到数据展示"的另一半拼图：

1. 数据准备差异：报表只有直连数据集、无直连模型，多实体关联建议下沉到 API 侧聚合；
2. 参数差异：报表参数是"驱动取数"，仪表板参数是"过滤已加载数据"；
3. 输出形态差异：报表产出可打印/可导出的正式单据，仪表板产出交互式可视化。