企业官网建设流程全解析

Automatisch 内置 HTTP Request 应用指南：零连接配置发起自定义 HTTP 请求

【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch

在 Automatisch 中，大多数应用（如 Gmail、Slack、GitHub）都需要先完成 OAuth 授权或填入 API Token 等认证信息才能使用，而本文要讲解的HTTP Request是一个完全不同的特例：它作为 Automatisch 自带的内部应用，不依赖任何外部服务，也不需要任何连接（Connection）配置，开箱即用。读完本文，你将掌握 HTTP Request 应用的连接模型、为什么它无需认证、以及如何通过其唯一的Custom request动作在自动化流程中发起任意 HTTP 请求（含请求头、JSON 数据与二进制响应处理），并深入理解其底层实现机制。

一、Automatisch 的"连接（Connection）"是什么

在深入 HTTP Request 之前，先厘清 Automatisch 中"连接"的概念。在 连接相关文档 与 认证辅助函数 中可以看到：Automatisch 的绝大多数应用都定义了自己的auth认证方案（OAuth2、API Key、Basic Auth 等），用户在流程中必须先建立一个"连接"，将第三方服务的凭证安全地存储在系统里，之后该应用下的触发器和动作才能代表用户调用对应 API。

这种设计保证了第三方凭据的集中管理与复用，但代价是：每接入一个外部服务，都需要经历授权跳转或密钥填写的额外步骤。

二、HTTP Request 为什么不需要连接

原文档（connection.md）的核心结论非常明确：

HTTP Request is a built-in app shipped with Automatisch, and it doesn't need to talk with any other external service to run. So there are no additional steps to use the HTTP Request app.

即：HTTP Request 是随 Automatisch 一同发布的"内置应用"，它的作用只是替你向任意 URL 发起 HTTP 请求，本身不承载任何外部账号体系，因此不存在认证步骤，也无需建立连接。

这一结论在源码中得到了一一印证。查看 应用定义文件：

export default defineApp({ name: 'HTTP Request', key: 'http-request', iconUrl: '{BASE_URL}/apps/http-request/assets/favicon.svg', authDocUrl: '{DOCS_URL}/apps/http-request/connection', supportsConnections: false, baseUrl: '', apiBaseUrl: '', primaryColor: '#000000', actions, });

几个关键字段的说明：

• supportsConnections: false：从源码结构看，这是整个应用"不需要连接"的根源。它向前端与引擎声明：本应用不提供任何连接能力，因此在流程编辑器里，选择 HTTP Request 时不会出现"连接账号"的配置步骤。
• baseUrl与apiBaseUrl均为空字符串：连接类应用通常用这两个字段指定第三方 API 的根地址，而 HTTP Request 的 URL 完全由用户在动作参数中动态指定，所以这里为空。
• 未声明auth字段：对比需要认证的应用（如 openai 应用 中带有auth定义），HTTP Request 的定义里根本没有认证块，进一步印证"零凭证"特性。
• authDocUrl指向本页：{DOCS_URL}与{BASE_URL}这类占位符会由 app-info-converter.js 在返回应用信息时统一替换为真实地址，authDocUrl指向的正是本文对应的连接说明页。

从 应用定义辅助函数 可以看到defineApp只是透传定义对象的纯函数，上述声明就是应用运行时行为的直接依据。

三、在流程中使用：Custom request 动作

既然不需要连接，HTTP Request 的价值就全部落在它的动作上。当前版本该应用只提供一个动作Custom request（自定义请求），其说明记录在 动作索引 与 动作文档 中："Makes a custom HTTP request by providing raw details."——通过提供原始细节来发起自定义 HTTP 请求。

动作的完整参数定义位于 custom-request 动作源码 的arguments数组，整理如下：

细节要点：

• Method 的取值：源码中明确枚举了DELETE / GET / PATCH / POST / PUT五种方法，不含HEAD、OPTIONS等。
• URL 与 Data 支持变量（variables: true）：可以在这些字段中引用上游步骤的输出，例如把 Webhook 收到的数据、数据库查询结果动态拼进 URL 或请求体中，这是实现"动态请求"的关键能力。
• Headers 是动态字段：默认预置一条Content-Type: application/json，你可以添加/删除任意数量的请求头，且键、值都支持变量注入（例如动态传入AuthorizationBearer Token）。

一个可落地的配置示例

假设你要在流程中调用一个需要鉴权的 JSON API：

• Method：POST
• URL：https://api.example.com/v1/orders（也可写成https://api.example.com/v1/orders?source={{1.orderSource}}这样带变量的形式）
• Data：{"customer_id": "{{1.customerId}}", "amount": 99.9}
• Headers：保留默认的Content-Type: application/json，再新增一行Authorization，值为Bearer {{2.accessToken}}

由于所有字段都是字符串类型，请求体会作为原始 JSON 字符串随请求发送。

四、源码级原理：Custom request 到底怎么执行

仅仅配置参数还不够，理解执行原理能帮你预判各种响应场景。run($)函数的实现（custom-request/index.js）揭示了完整调用链：

1. 参数归一化

动作先取出method、url、data、headers，并把动态键值对规约成一个普通对象；键统一转小写，跳过值为空的条目。之后从请求头中读取accept作为期望的响应内容类型。

2. HEAD 预检：探测响应类型与大小

// in case HEAD request is not supported by the URL try { const metadataResponse = await $.http.head(url, { headers: headersObject }); if (!expectedResponseContentType) { expectedResponseContentType = metadataResponse.headers['content-type']; } throwIfFileSizeExceedsLimit(metadataResponse.headers['content-length']); } catch {}

在执行正式请求前，系统会先发一个HEAD请求来探测目标 URL：如果用户没有显式指定Accept头，就用 HEAD 响应的Content-Type推断响应是否为文本类内容；同时提前检查Content-Length是否超过 25MB 上限。整个探测包裹在 try/catch 中，目标不支持 HEAD 时静默降级，不影响后续正式请求。

3. 25MB 响应大小限制

const maxFileSize = 25 * 1024 * 1024; // 25MB if (Number(contentLength) > maxFileSize) { throw new Error(`Response is too large. Maximum size is 25MB. Actual size is ${contentLength}`); }

正式请求与 HEAD 预检后都会执行throwIfFileSizeExceedsLimit校验，超过 25MB 会直接抛出错误并中止执行，这是内置的安全上限，无法配置修改。

4. 二进制响应的处理策略

if (!isPossiblyTextBased(expectedResponseContentType)) { requestData.responseType = 'arraybuffer'; }

isPossiblyTextBased只认application/json与text/*两类内容类型；其他类型（如图片、PDF、ZIP）会被视为二进制，请求以arraybuffer模式接收，随后在响应中通过Buffer.from(responseData).toString('base64')转成Base64 字符串交付给下游步骤，这样二进制内容也能安全地在流程数据中传递。

5. 输出结构

动作通过$.setActionItem输出统一的结果对象：

{ data: responseData, // 文本响应为原始内容；二进制响应为 Base64 字符串 headers: response.headers, status: response.status, statusText: response.statusText }

下游步骤可以直接读取data、headers、status、statusText四个字段，例如用status判断请求是否成功、用data解析返回的 JSON 或文件内容。

6. 底层 HTTP 客户端

所有请求经由 http-client 工厂 创建的 axios 实例发出，该实例基于 axios-with-proxy 构建，支持代理配置；同时内置了 401/403 时的 token 自动刷新与重试逻辑——不过由于 HTTP Request 应用本身不定义auth，该逻辑对它是透明的，不会触发。请求失败时会抛出统一的 HttpError，由引擎的错误处理机制记录执行状态。

五、实战建议与注意事项

基于以上实现，使用 HTTP Request 时值得注意：

1. 无需任何前置配置：在流程编辑器中选择 HTTP Request 后直接配置Custom request动作即可，没有"连接账号"步骤，这是它与其余应用最大的体验差异。
2. URL 中的查询参数会自动重新编码：源码描述明确指出含 querystring 的 URL 会被正确重新编码，可放心填入带?、&、=的地址。
3. 响应体超过 25MB 会失败：请求目标应尽量返回精简数据；需要拉取大文件时，可考虑让目标接口配合分页或下载直链。
4. 非文本响应是 Base64：如果对接的是图片或文件类接口，下游要处理 Base64 数据（例如在后续动作中解码或透传），而不是直接当文本使用。
5. 请求失败需自行处理：由于没有认证与重试的"外部服务语义"，对状态码的判定（如 4xx/5xx）需要在流程逻辑中显式设计，例如通过后续的 Filter 或条件步骤依据status字段分流。
6. 该应用没有触发器（Trigger）：从 应用目录结构 看，它只包含actions而没有任何 trigger 目录，因此它只能作为流程中段或末段的动作，不能作为流程的起点。

六、小结

HTTP Request 是 Automatisch 中"零摩擦"接入外部 API 的通用通道：凭借supportsConnections: false的声明，它跳过了 OAuth 与凭证配置，让用户把全部精力放在Method / URL / Data / Headers四个参数的组合上；其底层实现则通过 HEAD 预检、25MB 上限、二进制 Base64 编码等细节，保证了请求的健壮性与输出的一致性。无论是对接自建服务、调用第三方 REST API，还是在多个自动化应用之间做 HTTP 桥接，它都是流程中最直接、最轻量的选择。

相关参考文件：

• HTTP Request 连接文档
• HTTP Request 动作文档
• 应用定义源码
• Custom request 动作实现
• 应用信息占位符替换逻辑
• HTTP 客户端工厂

【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch