1. 从零开始为什么选择Node-RED处理HTTP请求如果你正在寻找一种能快速连接各种API、设备或服务又不想写太多代码的方法那么Node-RED很可能就是你的答案。我第一次接触Node-RED就是被它处理HTTP请求的便捷性所吸引。当时我需要一个简单的Webhook接收器用来处理来自第三方服务的通知。如果用传统的Node.js写我需要搭建Express服务器、定义路由、处理请求和响应还要考虑错误处理一套流程下来虽然不复杂但总感觉有些“仪式感”过强。而Node-RED让我在几分钟内通过拖拽几个节点就搭建起了一个功能完整的HTTP端点。Node-RED本质上是一个基于流的编程工具它把复杂的逻辑封装成一个个可连接的“节点”。对于HTTP通信这种高度标准化的任务它提供了现成的“http in”和“http out”节点让你能像搭积木一样构建服务。这特别适合做原型验证、自动化脚本、或者作为复杂系统中的一个小型胶水层。比如你可以用它监听一个GET请求触发一系列动作如查询数据库、调用另一个API、控制硬件最后再返回一个定制化的响应。整个过程可视化逻辑清晰调试起来也直观。很多人会问这和直接写一个Node.js脚本有什么区别核心区别在于“抽象层级”和“开发效率”。Node-RED将HTTP服务器的细节如端口监听、路由解析、请求体处理抽象掉了你只需要关心“收到请求后要做什么”以及“最后要回复什么”。这对于前端开发者、运维人员或物联网爱好者来说门槛大大降低。当然它并非要取代专业的后端框架而是在需要快速实现、变更频繁或逻辑相对简单的场景下提供了一个无与伦比的效率工具。接下来我们就从最基础的HTTP GET请求和响应设置开始一步步拆解其中的门道。2. 核心节点详解http in与http response的职责与配置在Node-RED中处理一个完整的HTTP请求-响应周期最少需要两个节点一个“门卫”一个“回信员”。“门卫”就是http in节点它的职责是监听特定的HTTP路径如/api/data并拦截到达该路径的请求。“回信员”则是http response节点它负责将处理后的数据打包成HTTP响应发回给客户端。这两个节点必须成对出现才能构成一个完整的端点。2.1http in节点请求的入口与解析器双击一个拖入工作流的http in节点你会看到它的配置面板。这里有几个关键配置项理解它们能避免很多后期的坑。1. 方法 (Method):这里选择GET。这意味着这个节点只响应HTTP GET请求。如果你误用POST方法访问这个端点Node-RED默认不会处理客户端会收到一个404或405错误。这是一个常见的排查点检查前端调用的方法是否与节点配置一致。2. URL (路径):这是你端点的地址。例如你设置为/api/weather。那么完整的访问地址就是http://你的服务器IP:1880/api/weather。这里有几个细节需要注意不要带协议和主机名只需填写路径部分。支持路径参数你可以设置动态路径如/api/user/:id。在后续的节点中你可以通过msg.req.params.id来获取这个id的值。这是实现RESTful风格API的基础。根路径如果设置为/它将成为你Node-RED HTTP服务的默认响应如果未设置其他更具体的路径。通常不建议这么做容易冲突。3. 名称 (Name):给节点起个有意义的名字比如“获取用户信息-GET”。当流程变复杂时清晰的命名是拯救调试时间的利器。配置完成后这个节点就具备了接收请求的能力。当一个GET请求到达指定路径时该节点会被触发并输出一个msg对象。这个对象是Node-RED中信息传递的载体它包含了请求的所有信息。msg对象的关键属性msg.req: Node.js原生的HTTP请求对象 (http.IncomingMessage)。你可以从这里获取请求头 (msg.req.headers)、查询字符串 (msg.req.query)、IP地址等信息。msg.payload: 初始状态下通常是空的。它的设计是用来承载你“处理后的、想要返回给客户端”的主要数据。msg._msgid: 本次消息流的唯一ID用于跟踪。一个常见的误解是认为msg.payload会自动包含请求体。对于GET请求它没有请求体参数都在URL的查询字符串中。你需要从msg.req.query中获取它们。例如对于请求/api/data?cityBeijing在下一个节点中你可以用msg.req.query.city来得到“Beijing”。2.2http response节点响应的构造与发送http response节点是流程的终点之一。它接收上游节点处理好的msg对象并根据其中的属性构造HTTP响应。它的配置相对简单但每个选项都直接影响客户端收到的结果。1. 状态码 (Status Code):默认是200表示成功。你必须根据业务逻辑来设置正确的状态码。常见的如200 OK: 成功。201 Created: 创建成功常用于POST请求。400 Bad Request: 客户端请求错误如参数缺失。404 Not Found: 资源不存在。500 Internal Server Error: 服务器内部错误。 注意在流程中你可以动态设置状态码。例如在一个“函数”节点中写msg.statusCode 404那么http response节点就会使用这个值而不是配置面板中的默认值。这给了你极大的灵活性。2. 响应头 (Headers):你可以在这里添加自定义的响应头。一个至关重要的头部是Access-Control-Allow-Origin它决定了是否允许浏览器跨域访问你的API。如果你在网页中用JavaScript调用这个接口而网页域名与Node-RED服务域名不同就会遇到CORS跨域资源共享错误。解决方法之一就是在这里添加一个头Access-Control-Allow-Origin-*允许所有域仅用于开发测试或具体的域名如https://your-frontend.com。3. 响应体的来源http response节点会将msg.payload的内容作为响应体发送出去。因此在数据流到达这个节点之前你必须确保msg.payload已经被设置为你想返回的数据通常是一个JSON对象或字符串。3. 实战演练构建一个带参数查询的天气API端点现在我们把理论付诸实践构建一个简单的模拟天气查询API。这个API通过GET请求接收城市名参数返回该城市的模拟天气数据。第一步放置并配置节点从左侧节点面板的“网络”分类下拖出一个http in节点到工作区。双击配置方法选GETURL填/api/weather名称写“天气查询入口”。再拖出一个http response节点放到它右边。用连线将http in的输出端右侧小点连接到http response的输入端左侧小点。现在一个最简单的、直接返回空响应的端点就完成了。但我们需要处理参数和逻辑。第二步添加函数节点处理逻辑直接连接两个节点没什么用。我们需要在中间对请求进行处理。拖入一个“函数”节点在“功能”分类下放在它们中间并重新连线http in-函数-http response。双击“函数”节点编写处理逻辑// 从请求的查询字符串中获取城市参数 let city msg.req.query.city; // 简单验证参数 if (!city) { // 如果城市参数为空返回400错误和提示信息 msg.statusCode 400; msg.payload { error: “请提供城市参数例如?cityBeijing” }; return msg; } // 模拟根据城市获取天气数据这里用固定数据代替数据库查询 let weatherData; switch(city.toLowerCase()) { case “beijing”: weatherData { city: “Beijing”, temperature: “22°C”, condition: “Sunny” }; break; case “shanghai”: weatherData { city: “Shanghai”, temperature: “25°C”, condition: “Cloudy” }; break; default: // 如果城市不在列表中返回404 msg.statusCode 404; msg.payload { error: 未找到城市 ${city} 的天气信息 }; return msg; } // 将处理好的数据放入payload状态码默认为200 msg.payload weatherData; return msg;这个函数完成了参数提取、验证、业务逻辑处理和错误处理。它动态设置了msg.statusCode和msg.payload。第三步部署与测试点击右上角的红色“部署”按钮让你的流程生效。打开浏览器或使用Postman、curl等工具进行测试。测试成功案例访问http://127.0.0.1:1880/api/weather?cityBeijing预期返回{“city”: “Beijing”, “temperature”: “22°C”, “condition”: “Sunny”}状态码200。测试参数缺失访问http://127.0.0.1:1880/api/weather预期返回{“error”: “请提供城市参数例如?cityBeijing”}状态码400。测试城市不存在访问http://127.0.0.1:1880/api/weather?cityParis预期返回{“error”: “未找到城市 Paris 的天气信息”}状态码404。通过这个简单的流程你已经实现了一个具备基本健壮性的RESTful API端点。Node-RED的可视化调试功能在这里非常有用你可以点击节点间的连线注入测试数据或者查看每个节点处理后的msg对象内容这对排查逻辑错误至关重要。4. 进阶技巧与高频避坑指南掌握了基础搭建后在实际项目中你会遇到更复杂的情况。下面分享一些进阶技巧和常见问题的解决方案。4.1 处理复杂的查询参数与JSON响应有时参数不止一个或者你需要返回结构复杂的嵌套JSON。处理多参数时只需从msg.req.query中依次取出即可它是一个对象。例如?cityBeijingdays3可以用let days parseInt(msg.req.query.days) || 1;来获取并设置默认值。构建复杂的JSON响应时建议在函数节点中先构建一个清晰的JavaScript对象然后直接赋值给msg.payload。Node-RED的http response节点会自动将对象序列化为JSON字符串并设置Content-Type: application/json响应头。这是非常方便的特性。// 构建复杂响应 msg.payload { status: “success”, forecast: { city: city, daily: [ { date: “2023-10-27”, high: “24°C”, low: “12°C” }, { date: “2023-10-28”, high: “23°C”, low: “11°C” } ] }, updatedAt: new Date().toISOString() }; // 无需手动设置Content-Type return msg;4.2 解决CORS跨域问题这是前端开发者调用本地Node-RED API时最高频遇到的坑。浏览器控制台会报错Access to fetch at ‘http://localhost:1880/api/weather‘ from origin ‘http://localhost:3000‘ has been blocked by CORS policy。解决方案有两种在http response节点中设置响应头如前所述添加头Access-Control-Allow-Origin值为*不推荐生产环境或你的前端域名。这种方法只对当前这个响应节点生效。在Node-RED设置文件中全局启用CORS推荐用于开发。找到你的Node-RED用户目录下的settings.js文件搜索httpNodeCors取消注释并修改httpNodeCors: { origin: “*”, // 或指定如 “http://localhost:3000” methods: “GET,PUT,POST,DELETE” },修改后需要重启Node-RED服务。这种方法对所有通过http in节点创建的端点都生效。4.3 应对“Unexpected status 502 Bad Gateway”错误这个错误在网络热词中频繁出现它通常不直接是Node-RED的错而是发生在Node-RED作为中间层去请求另一个后端服务时。错误信息如url: http://127.0.0.1:1572暗示了这一点。在Node-RED上下文中可能的原因和排查步骤下游服务不可达或崩溃你使用“http request”节点调用了一个外部API或服务但该服务没有启动、端口错误或已崩溃。检查目标URL是否正确服务是否正常运行。网络超时下游服务响应太慢超过了Node-RED或前置代理如Nginx的等待时间。你可以在“http request”节点的配置中增加“超时”时间默认为0即不超时。响应格式异常下游服务返回的响应无法被正确解析比如承诺返回JSON却返回了HTML错误页面。在“http request”节点后添加一个“调试”节点查看原始返回的msg.payload和msg.statusCode确认数据格式。流程逻辑错误导致响应缺失你的流程可能有多个分支但并非所有分支都最终连接到了http response节点。如果触发请求的分支没有到达响应节点客户端就会一直等待直到超时上游代理如网关就可能返回502。务必确保所有可能的逻辑路径最终都能到达一个http response节点。对于错误分支你也应该连接一个响应节点并返回错误信息。4.4 连接超时与“stream disconnected”错误处理类似stream disconnected before completion: transport error的错误通常指向不稳定的网络连接或服务端提前关闭了连接。增加超时设置在对外发起请求的“http request”节点中明确设置一个合理的超时如30秒避免无限等待。添加异常捕获利用“Catch”节点在“状态”分类下来捕获流程中任何节点抛出的异常。你可以将“Catch”节点连接到专门的错误处理流程记录日志并给客户端返回一个友好的500错误而不是让流程静默失败。使用异步上下文如果你在“函数”节点中执行了真正的异步操作如使用setTimeout、读取大文件需要确保正确处理回调或Promise。Node-RED的“函数”节点支持返回Promise这是处理异步操作最清晰的方式。如果异步操作中需要发送响应必须确保在操作完成后才调用node.send(msg)将消息传递到http response节点。4.5 流程的模块化与复用当API数量增多时把所有逻辑堆在一个流程里会难以维护。Node-RED提供了“子流程”和“配置节点”来提升复用性。子流程你可以将“参数验证”、“数据库查询”、“数据格式化”等通用逻辑封装成一个子流程。主流程中的多个HTTP端点都可以调用这个子流程实现逻辑复用。配置节点对于像数据库连接、第三方API密钥这类通用配置可以创建“配置节点”。在多个“函数”或“http request”节点中共享同一份配置方便统一修改。例如创建一个名为“数据库连接”的配置节点然后在多个查询函数中引用它这样数据库连接信息只需要维护一处。
Node-RED实战：快速构建HTTP API与避坑指南
1. 从零开始为什么选择Node-RED处理HTTP请求如果你正在寻找一种能快速连接各种API、设备或服务又不想写太多代码的方法那么Node-RED很可能就是你的答案。我第一次接触Node-RED就是被它处理HTTP请求的便捷性所吸引。当时我需要一个简单的Webhook接收器用来处理来自第三方服务的通知。如果用传统的Node.js写我需要搭建Express服务器、定义路由、处理请求和响应还要考虑错误处理一套流程下来虽然不复杂但总感觉有些“仪式感”过强。而Node-RED让我在几分钟内通过拖拽几个节点就搭建起了一个功能完整的HTTP端点。Node-RED本质上是一个基于流的编程工具它把复杂的逻辑封装成一个个可连接的“节点”。对于HTTP通信这种高度标准化的任务它提供了现成的“http in”和“http out”节点让你能像搭积木一样构建服务。这特别适合做原型验证、自动化脚本、或者作为复杂系统中的一个小型胶水层。比如你可以用它监听一个GET请求触发一系列动作如查询数据库、调用另一个API、控制硬件最后再返回一个定制化的响应。整个过程可视化逻辑清晰调试起来也直观。很多人会问这和直接写一个Node.js脚本有什么区别核心区别在于“抽象层级”和“开发效率”。Node-RED将HTTP服务器的细节如端口监听、路由解析、请求体处理抽象掉了你只需要关心“收到请求后要做什么”以及“最后要回复什么”。这对于前端开发者、运维人员或物联网爱好者来说门槛大大降低。当然它并非要取代专业的后端框架而是在需要快速实现、变更频繁或逻辑相对简单的场景下提供了一个无与伦比的效率工具。接下来我们就从最基础的HTTP GET请求和响应设置开始一步步拆解其中的门道。2. 核心节点详解http in与http response的职责与配置在Node-RED中处理一个完整的HTTP请求-响应周期最少需要两个节点一个“门卫”一个“回信员”。“门卫”就是http in节点它的职责是监听特定的HTTP路径如/api/data并拦截到达该路径的请求。“回信员”则是http response节点它负责将处理后的数据打包成HTTP响应发回给客户端。这两个节点必须成对出现才能构成一个完整的端点。2.1http in节点请求的入口与解析器双击一个拖入工作流的http in节点你会看到它的配置面板。这里有几个关键配置项理解它们能避免很多后期的坑。1. 方法 (Method):这里选择GET。这意味着这个节点只响应HTTP GET请求。如果你误用POST方法访问这个端点Node-RED默认不会处理客户端会收到一个404或405错误。这是一个常见的排查点检查前端调用的方法是否与节点配置一致。2. URL (路径):这是你端点的地址。例如你设置为/api/weather。那么完整的访问地址就是http://你的服务器IP:1880/api/weather。这里有几个细节需要注意不要带协议和主机名只需填写路径部分。支持路径参数你可以设置动态路径如/api/user/:id。在后续的节点中你可以通过msg.req.params.id来获取这个id的值。这是实现RESTful风格API的基础。根路径如果设置为/它将成为你Node-RED HTTP服务的默认响应如果未设置其他更具体的路径。通常不建议这么做容易冲突。3. 名称 (Name):给节点起个有意义的名字比如“获取用户信息-GET”。当流程变复杂时清晰的命名是拯救调试时间的利器。配置完成后这个节点就具备了接收请求的能力。当一个GET请求到达指定路径时该节点会被触发并输出一个msg对象。这个对象是Node-RED中信息传递的载体它包含了请求的所有信息。msg对象的关键属性msg.req: Node.js原生的HTTP请求对象 (http.IncomingMessage)。你可以从这里获取请求头 (msg.req.headers)、查询字符串 (msg.req.query)、IP地址等信息。msg.payload: 初始状态下通常是空的。它的设计是用来承载你“处理后的、想要返回给客户端”的主要数据。msg._msgid: 本次消息流的唯一ID用于跟踪。一个常见的误解是认为msg.payload会自动包含请求体。对于GET请求它没有请求体参数都在URL的查询字符串中。你需要从msg.req.query中获取它们。例如对于请求/api/data?cityBeijing在下一个节点中你可以用msg.req.query.city来得到“Beijing”。2.2http response节点响应的构造与发送http response节点是流程的终点之一。它接收上游节点处理好的msg对象并根据其中的属性构造HTTP响应。它的配置相对简单但每个选项都直接影响客户端收到的结果。1. 状态码 (Status Code):默认是200表示成功。你必须根据业务逻辑来设置正确的状态码。常见的如200 OK: 成功。201 Created: 创建成功常用于POST请求。400 Bad Request: 客户端请求错误如参数缺失。404 Not Found: 资源不存在。500 Internal Server Error: 服务器内部错误。 注意在流程中你可以动态设置状态码。例如在一个“函数”节点中写msg.statusCode 404那么http response节点就会使用这个值而不是配置面板中的默认值。这给了你极大的灵活性。2. 响应头 (Headers):你可以在这里添加自定义的响应头。一个至关重要的头部是Access-Control-Allow-Origin它决定了是否允许浏览器跨域访问你的API。如果你在网页中用JavaScript调用这个接口而网页域名与Node-RED服务域名不同就会遇到CORS跨域资源共享错误。解决方法之一就是在这里添加一个头Access-Control-Allow-Origin-*允许所有域仅用于开发测试或具体的域名如https://your-frontend.com。3. 响应体的来源http response节点会将msg.payload的内容作为响应体发送出去。因此在数据流到达这个节点之前你必须确保msg.payload已经被设置为你想返回的数据通常是一个JSON对象或字符串。3. 实战演练构建一个带参数查询的天气API端点现在我们把理论付诸实践构建一个简单的模拟天气查询API。这个API通过GET请求接收城市名参数返回该城市的模拟天气数据。第一步放置并配置节点从左侧节点面板的“网络”分类下拖出一个http in节点到工作区。双击配置方法选GETURL填/api/weather名称写“天气查询入口”。再拖出一个http response节点放到它右边。用连线将http in的输出端右侧小点连接到http response的输入端左侧小点。现在一个最简单的、直接返回空响应的端点就完成了。但我们需要处理参数和逻辑。第二步添加函数节点处理逻辑直接连接两个节点没什么用。我们需要在中间对请求进行处理。拖入一个“函数”节点在“功能”分类下放在它们中间并重新连线http in-函数-http response。双击“函数”节点编写处理逻辑// 从请求的查询字符串中获取城市参数 let city msg.req.query.city; // 简单验证参数 if (!city) { // 如果城市参数为空返回400错误和提示信息 msg.statusCode 400; msg.payload { error: “请提供城市参数例如?cityBeijing” }; return msg; } // 模拟根据城市获取天气数据这里用固定数据代替数据库查询 let weatherData; switch(city.toLowerCase()) { case “beijing”: weatherData { city: “Beijing”, temperature: “22°C”, condition: “Sunny” }; break; case “shanghai”: weatherData { city: “Shanghai”, temperature: “25°C”, condition: “Cloudy” }; break; default: // 如果城市不在列表中返回404 msg.statusCode 404; msg.payload { error: 未找到城市 ${city} 的天气信息 }; return msg; } // 将处理好的数据放入payload状态码默认为200 msg.payload weatherData; return msg;这个函数完成了参数提取、验证、业务逻辑处理和错误处理。它动态设置了msg.statusCode和msg.payload。第三步部署与测试点击右上角的红色“部署”按钮让你的流程生效。打开浏览器或使用Postman、curl等工具进行测试。测试成功案例访问http://127.0.0.1:1880/api/weather?cityBeijing预期返回{“city”: “Beijing”, “temperature”: “22°C”, “condition”: “Sunny”}状态码200。测试参数缺失访问http://127.0.0.1:1880/api/weather预期返回{“error”: “请提供城市参数例如?cityBeijing”}状态码400。测试城市不存在访问http://127.0.0.1:1880/api/weather?cityParis预期返回{“error”: “未找到城市 Paris 的天气信息”}状态码404。通过这个简单的流程你已经实现了一个具备基本健壮性的RESTful API端点。Node-RED的可视化调试功能在这里非常有用你可以点击节点间的连线注入测试数据或者查看每个节点处理后的msg对象内容这对排查逻辑错误至关重要。4. 进阶技巧与高频避坑指南掌握了基础搭建后在实际项目中你会遇到更复杂的情况。下面分享一些进阶技巧和常见问题的解决方案。4.1 处理复杂的查询参数与JSON响应有时参数不止一个或者你需要返回结构复杂的嵌套JSON。处理多参数时只需从msg.req.query中依次取出即可它是一个对象。例如?cityBeijingdays3可以用let days parseInt(msg.req.query.days) || 1;来获取并设置默认值。构建复杂的JSON响应时建议在函数节点中先构建一个清晰的JavaScript对象然后直接赋值给msg.payload。Node-RED的http response节点会自动将对象序列化为JSON字符串并设置Content-Type: application/json响应头。这是非常方便的特性。// 构建复杂响应 msg.payload { status: “success”, forecast: { city: city, daily: [ { date: “2023-10-27”, high: “24°C”, low: “12°C” }, { date: “2023-10-28”, high: “23°C”, low: “11°C” } ] }, updatedAt: new Date().toISOString() }; // 无需手动设置Content-Type return msg;4.2 解决CORS跨域问题这是前端开发者调用本地Node-RED API时最高频遇到的坑。浏览器控制台会报错Access to fetch at ‘http://localhost:1880/api/weather‘ from origin ‘http://localhost:3000‘ has been blocked by CORS policy。解决方案有两种在http response节点中设置响应头如前所述添加头Access-Control-Allow-Origin值为*不推荐生产环境或你的前端域名。这种方法只对当前这个响应节点生效。在Node-RED设置文件中全局启用CORS推荐用于开发。找到你的Node-RED用户目录下的settings.js文件搜索httpNodeCors取消注释并修改httpNodeCors: { origin: “*”, // 或指定如 “http://localhost:3000” methods: “GET,PUT,POST,DELETE” },修改后需要重启Node-RED服务。这种方法对所有通过http in节点创建的端点都生效。4.3 应对“Unexpected status 502 Bad Gateway”错误这个错误在网络热词中频繁出现它通常不直接是Node-RED的错而是发生在Node-RED作为中间层去请求另一个后端服务时。错误信息如url: http://127.0.0.1:1572暗示了这一点。在Node-RED上下文中可能的原因和排查步骤下游服务不可达或崩溃你使用“http request”节点调用了一个外部API或服务但该服务没有启动、端口错误或已崩溃。检查目标URL是否正确服务是否正常运行。网络超时下游服务响应太慢超过了Node-RED或前置代理如Nginx的等待时间。你可以在“http request”节点的配置中增加“超时”时间默认为0即不超时。响应格式异常下游服务返回的响应无法被正确解析比如承诺返回JSON却返回了HTML错误页面。在“http request”节点后添加一个“调试”节点查看原始返回的msg.payload和msg.statusCode确认数据格式。流程逻辑错误导致响应缺失你的流程可能有多个分支但并非所有分支都最终连接到了http response节点。如果触发请求的分支没有到达响应节点客户端就会一直等待直到超时上游代理如网关就可能返回502。务必确保所有可能的逻辑路径最终都能到达一个http response节点。对于错误分支你也应该连接一个响应节点并返回错误信息。4.4 连接超时与“stream disconnected”错误处理类似stream disconnected before completion: transport error的错误通常指向不稳定的网络连接或服务端提前关闭了连接。增加超时设置在对外发起请求的“http request”节点中明确设置一个合理的超时如30秒避免无限等待。添加异常捕获利用“Catch”节点在“状态”分类下来捕获流程中任何节点抛出的异常。你可以将“Catch”节点连接到专门的错误处理流程记录日志并给客户端返回一个友好的500错误而不是让流程静默失败。使用异步上下文如果你在“函数”节点中执行了真正的异步操作如使用setTimeout、读取大文件需要确保正确处理回调或Promise。Node-RED的“函数”节点支持返回Promise这是处理异步操作最清晰的方式。如果异步操作中需要发送响应必须确保在操作完成后才调用node.send(msg)将消息传递到http response节点。4.5 流程的模块化与复用当API数量增多时把所有逻辑堆在一个流程里会难以维护。Node-RED提供了“子流程”和“配置节点”来提升复用性。子流程你可以将“参数验证”、“数据库查询”、“数据格式化”等通用逻辑封装成一个子流程。主流程中的多个HTTP端点都可以调用这个子流程实现逻辑复用。配置节点对于像数据库连接、第三方API密钥这类通用配置可以创建“配置节点”。在多个“函数”或“http request”节点中共享同一份配置方便统一修改。例如创建一个名为“数据库连接”的配置节点然后在多个查询函数中引用它这样数据库连接信息只需要维护一处。
