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

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 doesnt 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数组整理如下参数Key类型必填默认值说明Methodmethod下拉框是GET请求方法可选GET、POST、PUT、PATCH、DELETEURLurl字符串是—请求地址含查询字符串的 URL 会被正确重新编码Datadata字符串否—在此放置原始 JSON 数据请求体Headersheaders动态键值对否Content-Type: application/json按需增删请求头键与值均支持变量细节要点Method 的取值源码中明确枚举了DELETE / GET / PATCH / POST / PUT五种方法不含HEAD、OPTIONS等。URL 与 Data 支持变量variables: true可以在这些字段中引用上游步骤的输出例如把 Webhook 收到的数据、数据库查询结果动态拼进 URL 或请求体中这是实现动态请求的关键能力。Headers 是动态字段默认预置一条Content-Type: application/json你可以添加/删除任意数量的请求头且键、值都支持变量注入例如动态传入AuthorizationBearer Token。一个可落地的配置示例假设你要在流程中调用一个需要鉴权的 JSON APIMethodPOSTURLhttps://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 时值得注意无需任何前置配置在流程编辑器中选择 HTTP Request 后直接配置Custom request动作即可没有连接账号步骤这是它与其余应用最大的体验差异。URL 中的查询参数会自动重新编码源码描述明确指出含 querystring 的 URL 会被正确重新编码可放心填入带?、、的地址。响应体超过 25MB 会失败请求目标应尽量返回精简数据需要拉取大文件时可考虑让目标接口配合分页或下载直链。非文本响应是 Base64如果对接的是图片或文件类接口下游要处理 Base64 数据例如在后续动作中解码或透传而不是直接当文本使用。请求失败需自行处理由于没有认证与重试的外部服务语义对状态码的判定如 4xx/5xx需要在流程逻辑中显式设计例如通过后续的 Filter 或条件步骤依据status字段分流。该应用没有触发器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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考