Skip to content

HTTP 请求节点

HTTP 请求节点用于在工作流中调用 HTTP/HTTPS 接口,把上游变量组装成 URL、查询参数、请求头、鉴权信息和请求体,并将响应正文、状态码和响应头交给下游节点。

它适合调用 REST API、Webhook、模型或业务服务,但不是浏览器:不会执行网页脚本,也不能代替需要登录页面交互的自动化工具。

当前实现与旧文档差异

本页保留了旧文档中关于 API、鉴权、请求体、cURL 导入和异常处理的完整说明,并按当前系统实现做了以下更正:

项目当前实现旧文档需要更正之处
请求方法GETPOSTPUTDELETEPATCHHEAD旧文档对 PATCH 的描述不准确;PATCH 通常表示部分更新,节点本身只按所选方法发送请求
默认超时120 秒与旧文档一致
超时范围最长 3600 秒旧文档写的最长 600 秒已不适用
默认重试不重试旧文档写的默认重试 3 次已不适用
重试次数0~3 次旧文档写的最多 10 次已不适用
请求体none、JSON、form-data、x-www-form-urlencoded、raw text、binary当前增加并明确支持单独的 binary 配置
私网访问默认禁止 localhost、回环地址和私网 IP不是简单地“建议使用域名”;运行服务默认执行实际的私网地址校验
输出默认公开 bodystatusCodeheadersbodyheaders 都是字符串,不会自动展开成对象

不要把旧文档中的示例域名、访问令牌和接口参数原样复制到生产工作流。接口地址、鉴权方式和字段结构必须以当前被调用服务为准。

适用场景

  • 获取外部服务数据,例如查询天气、订单或设备状态。
  • 向业务系统提交表单或 JSON 数据。
  • 更新或删除远端资源。
  • 调用只提供 HTTP API、尚未封装成插件的服务。
  • 向 Webhook 发送工作流结果或事件通知。

如果同一服务会被多个工作流长期复用,并且需要统一版本、鉴权、参数说明和权限管理,优先把它封装为插件,再通过插件节点调用。

节点配置

API

配置说明
请求方法支持 GET、POST、PUT、DELETE、PATCH、HEAD
URL必填,只允许 HTTP 或 HTTPS;可以输入 {{ 引用工作流变量
URL 长度当前前端校验要求小于 10000 个字符

当前运行时对 GET 和 HEAD 不发送请求体。即使界面中残留了 Body 配置,运行时也会忽略,因此查询条件应放到 URL 或“请求参数”中。

HTTP 请求节点的 API、参数、请求头和鉴权配置

请求参数

请求参数会作为 Query 参数追加到 URL。每项包含参数名和参数值,参数值可以填写常量,也可以引用上游变量。

当前校验规则:

  • 参数名只能包含字母、数字、中横线或下划线。
  • 参数名必须以字母或下划线开头。
  • 同一组参数名不能重复。
  • 变量引用必须指向有效的上游输出。

例如,参数 locale=zh-CN 会形成类似 ?locale=zh-CN 的查询字符串。涉及数组、对象或特殊编码规则时,应先确认目标接口如何接收,再决定是否在上游转换为字符串。

请求头

请求头用于传递内容协商、租户标识、链路标识或接口要求的其他元数据,例如:

text
Accept: application/json
X-Request-Id: {{request_id}}

请求头名称使用与请求参数相同的命名校验。不要在普通文本中写入真实 Token;优先引用由上游安全来源提供的变量。

鉴权

关闭鉴权时,节点不会自动添加认证信息。开启后支持两种方式:

类型配置发送方式
Bearer Tokentoken自动生成 Authorization: Bearer <token> 请求头
自定义KeyValue添加到把自定义键值添加到 Header 或 Query

Bearer Token 输入框只填写 Token 本身,不要重复输入 Bearer 前缀。自定义鉴权适合 API Key、签名字段或目标接口规定的其他认证参数。

鉴权已开启但值为空时,工作流发布校验会提示补全认证参数。Token、签名和密钥不应出现在 URL、截图、日志说明或提交到 Git 的文档中。

请求体

类型使用场景当前行为
noneGET、HEAD 或不需要 Body 的接口不发送请求体
JSONapplication/json 接口发送编辑器中的 JSON 文本,并支持变量插值
form-datamultipart 表单当前执行器把配置项组装为 multipart 文本字段
x-www-form-urlencodedURL 编码表单对字段名和值编码后发送
raw text纯文本、XML 或目标接口要求的自定义文本text/plain 发送文本
binary单文件或二进制内容使用文件变量中的 URL 或 Base64 内容发送

JSON 请求体必须在变量替换前后都能形成合法 JSON。例如字符串变量应放在 JSON 字符串位置:

json
{
  "message": "{{input}}"
}

不要在 JSON 字符串外额外拼接未经转义的文本。需要发送结构复杂的对象时,可先使用 JSON 序列化节点 生成严格 JSON,再按接口要求引用。

虽然 form-data 编辑器允许选择多种文件类变量类型,但当前运行执行器只组装 multipart 文本字段,不会把这些字段自动转换为真实文件附件。发送单个文件内容时使用 binary;需要多个文件或复杂 multipart 文件上传时,建议封装成专用插件。

binary 支持从文件变量中读取 URL 或 Base64 内容。使用 URL 时,运行时会先下载文件再作为请求体发送,同样受 HTTP/HTTPS 和私网地址限制。

输出

默认输出固定为:

输出类型说明
bodyString响应正文原文
statusCodeIntegerHTTP 状态码
headersString序列化后的响应头 JSON 字符串

当异常处理方式不是“中断流程”时,编辑器还会加入 errorBody,其中包含 errorMessageerrorCode,供异常分支或后续判断使用。

即使接口返回 application/jsonbody 仍然是字符串。需要引用 body.data.id 等内部字段时,应在下游接 JSON 反序列化节点,先将响应正文转换为结构化变量。

超时、重试和异常处理

HTTP 请求节点的请求体、输出和异常处理

配置当前默认值说明
整体执行超时120 秒最长 3600 秒;超过限制后按节点异常处理
重试次数不重试可选重试 1、2 或 3 次
异常处理方式中断流程还可选择“返回设定内容”或“执行异常流程”

重试不是越多越好:

  • GET、HEAD 等只读请求通常更适合重试,但仍要考虑目标服务限流。
  • POST、PATCH、PUT、DELETE 可能产生副作用;只有目标接口提供幂等键或明确保证幂等时才应自动重试。
  • 认证失败、参数错误等 4xx 问题通常无法通过重试解决。
  • 超时不代表目标服务一定没有完成操作。写接口超时后盲目重试,可能创建重复数据。

导入 cURL

点击 API 区域右上角的“导入 cURL”,可以把常见 cURL 命令转换为节点配置。

HTTP 请求节点导入 cURL

当前导入器会解析:

  • URL 和 GET 请求中的查询参数。
  • -X--request 指定的方法。
  • -H--header 请求头。
  • JSON、URL 编码表单、form-data 和 raw text 请求体。
  • --data--data-raw--data-binary--data-urlencode 等常见参数形式。

导入完成后仍需逐项核对:

  1. Content-Type 会用于判断 Body 类型,并从普通请求头列表中移除。
  2. 导入器只支持当前节点已有的六种请求方法。
  3. 复杂 shell 变量、命令替换、证书、代理、Cookie 文件等 cURL 行为不会完整迁移。
  4. application/octet-stream 的 cURL 当前不会自动生成 binary 文件变量;二进制请求应在导入后手动选择 binary 并绑定文件。
  5. 不要把含真实密钥、Cookie 或 Token 的 cURL 放进文档截图。

网络与安全限制

当前运行时具有以下边界:

  • 只允许 http://https:// URL。
  • 默认阻止 localhost、回环地址、链路本地地址和私网 IP。
  • 是否允许访问私网由工作流运行服务的安全配置决定,不能靠更换写法绕过。
  • HTTP 客户端连接超时为 5 秒;节点整体执行超时由异常处理中的超时设置控制。
  • binary URL 下载也执行同样的协议和私网校验。

如果必须调用企业内网服务,应由部署管理员配置可信的网络连通和安全策略,或将能力封装为受控插件。不要使用重定向、公共代理或硬编码地址规避限制。

配置示例

下面示例向一个 JSON 接口发送消息:

配置示例值
方法POST
URLhttps://httpbin.org/post
请求参数locale = zh-CN
请求头Accept = application/json
请求体JSON:{"message":"AIOS 文档示例"}
超时120 秒
重试不重试

httpbin.org 仅用于说明配置结构。实际工作流应替换为经过授权、可用性和数据合规评估的目标接口。

发布前检查

  1. URL 是否为允许访问的 HTTP/HTTPS 地址,变量引用是否有效。
  2. 请求方法是否与接口语义一致,GET/HEAD 是否误配了 Body。
  3. Query 和 Header 名称是否合法、无重复项。
  4. 鉴权是否开启,Token 是否只填写值而未重复添加 Bearer
  5. JSON 是否严格合法,字符串变量是否位于引号内。
  6. 文件上传是否选择了适合当前实现的 binary 或专用插件。
  7. 写接口是否具备幂等条件,再决定是否开启重试。
  8. 是否同时检查 statusCode 和业务响应字段。
  9. 响应正文是否需要 JSON 反序列化后再供下游使用。
  10. 试运行输入是否使用测试数据,且截图和日志中没有敏感信息。

常见问题

为什么配置了请求体,但 GET 或 HEAD 没有发送?

当前运行时对 GET 和 HEAD 固定忽略请求体。请把查询字段放在请求参数中,或根据目标接口改用 POST 等允许 Body 的方法。

为什么响应 JSON 不能直接引用内部字段?

HTTP 节点的 body 类型是 String。将 body 传给 JSON 反序列化节点,声明需要的输出结构后再引用内部字段。

为什么提示“JSON 语法错误”或旧版 Body is not json

请求体在变量占位符替换后仍必须是合法 JSON。重点检查双引号、逗号、转义字符,以及字符串变量是否放在 JSON 字符串位置。

为什么访问 localhost 或内网 IP 失败?

工作流运行在服务端,不是在当前浏览器或个人电脑上执行,并且当前安全策略默认拦截私网和回环地址。请使用可从运行环境访问的正式服务,或联系部署管理员配置受控内网访问。

为什么 form-data 中选择文件变量后没有变成文件附件?

当前 form-data 执行路径只生成文本字段。单文件内容使用 binary;多个文件或复杂 multipart 请求应封装为插件。

为什么 cURL 导入后缺少 Content-Type?

导入器会用 Content-Type 判断 Body 类型,并由运行时按 Body 类型重新生成对应的内容类型,因此不会把它重复保留在普通请求头列表中。

为什么请求失败后没有重试?

当前默认值是“不重试”。需要时手动选择 1~3 次,并先确认目标接口是否幂等以及是否允许重复调用。

为什么 401 或 403 一直失败?

检查鉴权是否开启、Bearer Token 是否重复写了前缀、自定义鉴权添加到了正确的 Header 或 Query,以及当前凭证是否具备接口权限。认证和授权错误通常不应通过重试处理。