引言：为什么是 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 接入到数据展示"的另一半拼图：
- 数据准备差异：报表只有直连数据集、无直连模型，多实体关联建议下沉到 API 侧聚合；
- 参数差异：报表参数是"驱动取数"，仪表板参数是"过滤已加载数据"；
- 输出形态差异：报表产出可打印/可导出的正式单据，仪表板产出交互式可视化。