5.3 Web服务与API连接

5.3 Web服务与API连接

把接口数据拉进管道的几条路

本篇是第 5 章第 3 节，也是连接章收尾，讲最不规整的源——Web API，是接入第三方数据的实战重点。

「REST 客户端」步骤能直接发 GET/POST 并取回 JSON，适合简单查询。我们在 URL 里拼 ${token} 等变量，响应用「JSON 输入」按路径抽取。注意分页：大多数接口一页几百条，要循环翻页才能拿全。

「HTTP 输入」更底层，适合自定义头、签名等复杂鉴权。我们调需要 HMAC 签名的接口时，先用「JavaScript」算出签名塞进请求头，再发请求。这类接口逻辑重，但封装一次就能复用。

SOAP 用「Web 服务查询」步骤，要配 WSDL。我们老系统对接还在用，新项目基本都 REST 了。WSDL 变更会让步骤失效，我们把它当不稳定源，加失败告警。

API 限流是现实约束：每秒请求数有上限，硬薅会被封。我们用「阻塞」步骤或作业级 sleep 控制节奏，并尊重响应的 Retry-After。曾经贪快被限流，反而更慢，后来改成匀速。

接口数据质量参差：字段可能缺失、类型可能为 null。我们抽取后必接「过滤」+「校验」，把不合规记录导错误表，绝不带病进仓。API 源的可信度天然低于数据库，校验要更狠。

关键代码与配置

下面这段 xml 给出了可直接落地的配置，输入来自上一步、输出写入目标端：

<step><name>REST</name><type>RestClient</type>
  <url>http://api.corp.com/orders?day=${p_day}</url>
  <method>GET</method>
  <header><name>Authorization</name><value>Bearer ${token}</value></header>
</step>
<step><name>解析</name><type>JsonInput</type>
  <json_field>result</json_field><field><name>id</name><path>$.id</path></field>
</step>
​

REST 取数 + JSON 抽取是标准组合。token 走变量，路径按接口文档配。我们限制单次返回量做分页。

// 计算 HMAC 签名放进请求头（SHA256）
var crypto = Packages.javax.crypto... ; // 伪示意
var sign = hmac256(secret, method + path + ts);
// 把 sign 写入变量供 HTTP 输入使用
SetVariable('api_sign', sign);
​

复杂鉴权用脚本算签名。我们封装成子转换，多个接口复用同一套签名逻辑，避免各处重写。

背景

为赶进度把接口并发拉满，结果触发限流，大量请求被拒重试，总耗时比匀速还长一倍。

操作

在作业里加匀速控制：每批请求后 sleep，并读响应头的 Retry-After 退避。

# Shell 条目内匀速
for p in $(seq 1 100); do
  curl -s "$API?page=$p"
  sleep 0.2   # 控制到接口允许的频率
done
​

结果

频率降到阈值内，不再被限，总耗时反而缩短，数据完整拉全。

解读

根因是忽视对方限流契约。API 接入的第一约束是「尊重频率」，匀速慢但稳，贪快会被惩罚。

变式

若数据量大，可改用接口提供的批量端点或落增量游标，从根源减少请求数，比调 sleep 更优。

常见误区与工程取舍

误区：并发拉满接口。必触发限流，匀速才是正道。

误区：API 数据直接进仓。缺失/null 普遍，必须过滤+校验。

取舍：简单查询用 REST 步骤；复杂鉴权用 HTTP+脚本，封装复用。

深入：Web 服务与 API 怎么接

现代数据源大量是 HTTP 接口。Kettle 用「HTTP 输入」或「REST 客户端」步骤拉取，需要配 URL、认证头（如 Bearer Token，用变量注入）、请求方法。接口通常分页，要在转换里用「生成行+循环」或作业里循环翻页直到取完。限流也要尊重：对方返回 429 时要退避重试，而非硬撞。拿到 JSON/XML 响应后，用对应的输入步骤配路径表达式抽取字段，再进入常规清洗。

# 在「HTTP 输入」步骤的 Header 中注入认证（输入：接口地址+令牌变量；输出：JSON 响应体）
Authorization: Bearer ${p_api_token}    # 令牌走变量，不写死在步骤里
# 限流：遇到 HTTP 429 时由作业重试间隔退避，避免触发对方封禁
​

⚠️ 常见坑（Web/API）

• 令牌明文：Secret 写死步骤，泄露风险高，应变量注入。
• 不分页：只取到第一页，数据缺大半。
• 不处理限流：硬撞 429 被对方封 IP，整条失败。

💡 关键直觉

• 接 API 的本质是「把不可控的外部依赖变可控」：令牌变量化、分页闭环、限流退避，三者缺一不可。
• API 数据是半结构，抽取字段那一步（JSON/XML 路径）才是稳定落库的关键。

工程实录：接一个分页 API

接口只返回第一页，数据缺大半还偶发限流。

用循环翻页直到取完，遇 429 由作业退避重试。

# HTTP 输入步骤 Header 注入令牌（变量，不写死）
Authorization: Bearer ${p_api_token}
# 作业循环 p_page 自增，直到响应为空或达到 total
​

数据完整拉取且不被对方封 IP。

令牌变量化、分页闭环、限流退避三者缺一不可。

响应用 JSON 输入步骤配路径表达式抽取字段。

参数与阈值速查