Dify 工作流 HTTP 请求配置5步把外部API接进流程【免费下载链接】Awesome-Dify-Workflow分享一些好用的 Dify DSL 工作流程自用、学习两相宜。 Sharing some Dify workflows.项目地址: https://gitcode.com/GitHub_Trending/aw/Awesome-Dify-Workflow以自动把 LLM 生成的文案渲染成封面图为例DSL/Dify 运营一条龙.yml 里的工作流就是这样做的——LLM 产出文案后一个 HTTP 请求节点把 JSON 渲染数据 POST 给图片渲染服务再从头节点的 body 里取回图片 URL。下面的 Dify 工作流 HTTP 请求配置就是照着这条真实链路拆的跟着做完你的工作流也能调通任意外部 API。按顺序配完这5步第1步确定请求方式。这一步决定数据往哪送。GET 用来取数据POST 用来提交数据。判断标准很简单只读就用 GET要传一段结构化数据就用 POST。上面那个工作流里ImgRender - 1 节点用的是 POST因为要把整段卡片配置发给渲染服务。第2步填 URL。这一步是告诉节点数据送到哪。固定接口直接填地址比如https://api.imgrender.net/open/v1/pics如果地址要动态生成用变量插值url: {{#1719878483248.item#}}搜索大师.yml 里就是这么做的——LLM 先吐出一批搜索链接循环内逐个填进 URL 再发请求。第3步配认证头。拿到第2步的 URL 后先确认接口要什么凭据。大多数国内 API 用自定义 Header 传 key在节点的授权里选 api-keyHeader 名按文档填比如X-API-Keyauthorization: type: api-key config: {type: custom, header: X-API-Key, api_key: your-key}注意 Dify 的 HTTP 节点认证是独立设置的不会和模型 API 的 key 混用这里只影响这一个节点。第4步组装请求体。凭据就位后把第1步决定要送的数据填进 body。Body 类型选 JSON内容直接用上游变量body: {type: json, data: {{#1721652505347.output#}}} headers: Content-Type: application/json这里的关键是选对上游变量——渲染工作流里body 内容来自前面请求体合并模板节点的 output也就是说先用模板节点把零散字段拼成一个完整 JSON再整体喂给 HTTP 节点比在 body 里逐字段插值更不容易出错。第5步校验响应。节点跑完后会输出status_code、headers、body三个变量。别直接拿 body 往下走先加一个条件分支判断status_code 200失败了走错误分支输出提示成功了再从 body 提取字段——搜索大师.yml 里紧跟 HTTP 节点的就是这么一条status_code判断。认证方式和参数位置速查配置项可选值说明请求方法GET / POST / PUT / DELETE只读取数据用 GET提交数据用 POST参数位置Params / Headers / Body简单筛选放 Params拼在 URL 后认证放 Headers结构化数据放 BodyBody 格式none / form-data / x-www-form-urlencoded / JSON / raw / binary表单接口选 form 类现代 API 基本都是 JSON认证方式无 / api-key / Bearer Tokenkey 放 Header 选 api-key 并指定 Header 名key 放 URL 参数的如高德直接在 URL 里拼?key{{API_KEY}}参考 DSL/MCP-amap.yml报错了先查这4层先查网络连通把 URL 贴进浏览器直接打开。打不开说明是网络或白名单问题跟 Dify 无关。再查认证凭据返回 401/403 时对照 API 文档逐字符检查 Header 名X-API-Key和Authorization写错一个字母就失败并确认 key 没过期。再查参数格式返回 400 时确认 body 类型选对了选 JSON 但文档要求 form-data 是最常见的坑以及 JSON 是否合法、字段名大小写是否一致。最后查响应解析接口通了但下游节点报错通常是 body 是字符串不是对象。渲染工作流里的解法是用 Python 代码节点json.loads后再取data[data][url]你可以照搬这个套路。稳定性要点超时别全靠默认给读超时设个明确值如 30 秒避免慢接口拖住整条流程。重试只针对偶发失败429/5xx 可以走条件分支重试400 这类确定性错误重试只会放大问题。小请求合并成大请求Dify 运营一条龙里四张卡片是分别渲染的但每张卡的内容都先经模板节点拼好再发一次请求而不是字段各发各的——请求次数越少整条流程越快越稳。最小完整骨架以下配置可直接套用改 URL、key 和 body 变量即可- data: authorization: type: api-key config: {type: custom, header: X-API-Key, api_key: your-key} body: {type: json, data: {{#step_output#}}} headers: Content-Type: application/json method: post url: https://api.example.com/v1/render timeout: {max_connect_timeout: 10, max_read_timeout: 30, max_write_timeout: 10} type: http-request延伸方向用迭代节点批量发 HTTP 请求DSL/搜索大师.yml 就是循环取页面的完整示范。用 MCP 节点替代手写 HTTP直接连高德这类服务的 SSE 端点。结合会话变量存 token实现过期后自动刷新。接 Webhook让外部系统反过来触发你的工作流。加日志节点记录每次请求的入参和响应方便排查线上问题。回到开头那个封面图场景从模板节点拼好 JSON到 POST 出去、判断状态码、代码节点提取 URL五个步骤走完一张图就渲染出来了。下次要接天气、支付或任何 REST 接口时把骨架里的 URL 和字段换掉就行。【免费下载链接】Awesome-Dify-Workflow分享一些好用的 Dify DSL 工作流程自用、学习两相宜。 Sharing some Dify workflows.项目地址: https://gitcode.com/GitHub_Trending/aw/Awesome-Dify-Workflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
