Dify中HTTP请求节点的常见操作

Dify 在 HTTP 请求中的流程编写

HTTP节点包括API请求类型(GET、POST、HEAD、PATCH、PUT、DELETE),鉴权类型(无、API-Key基础、API-Key Bearer、API-Key自定义),HEADERS键值设置,PARAMS键值设置,BODY(none、form-data、x-www-form-urlencoded、raw text、JSON),超时设置(连接超时、读取超时、写入超时),输出变量(body String 响应内容、status_code Number 响应状态码、headers Object 响应头列表 JSON、files Array[File] 文件列表)。说明:在平时开发中,主要使用GET和POST这两种API请求类型。

Dify中HTTP请求节点的常见操作
Dify中HTTP请求节点的常见操作

一.GET请求类型

功能:查询所有产品。GET请求是获取全部资源。

实现:后端通过Flask实现@app.route('/products', methods=['GET'])

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求->结束)可查看最终输出:

Dify中HTTP请求节点的常见操作

二.POST请求类型

功能:创建一个新的产品。POST请求是创建新资源。

实现:后端通过Flask实现@app.route('/products', methods=['POST'])

Dify中HTTP请求节点的常见操作

如果出现status_code: 502,且确保POST接口没有问题,那么基本上是设置了Proxy代理问题,关闭代理接口正常运行。

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求->结束)可查看最终输出:

Dify中HTTP请求节点的常见操作

三.HEAD请求类型

功能:根据id检查产品是否存在。HEAD请求为检查资源的存在性。

实现:后端通过Flask实现@app.route('/products/<int:id>', methods=['HEAD'])

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求)可查看最终输出:

Dify中HTTP请求节点的常见操作

(1)当使用HEAD方法访问/products/[int:id](int:id)时,函数会检查是否存在具有该ID的产品。

(2)如果产品存在,函数返回状态码200,表示资源存在,但不会返回产品的内容。

(3)如果产品不存在,函数返回状态码404,表示资源不存在。

执行Workflow后,在跟踪界面(开始->HTTP请求->结束)可查看最终输出:

四.PATCH请求类型

功能:根据id更新产品的名字。PATCH请求为部分更新资源。

实现:后端通过Flask实现@app.route('/products/<int:id>', methods=['PATCH'])

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求->结束)可查看最终输出:

Dify中HTTP请求节点的常见操作

五.PUT请求类型

功能:替换指定id的产品资源。PUT请求为完全替换资源。

实现:后端通过Flask实现@app.route('/products/<int:id>', methods=['PUT'])

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求->结束)可查看最终输出:

Dify中HTTP请求节点的常见操作

核心代码是product.update(request.json)product.update(...) 调用 product 字典的 update 方法,并将 request.json 作为参数传入。这个方法会遍历 request.json 中的所有键值对:

(1)如果 product 中已存在相同的键,则会用 request.json 中的值更新 product 中的值。

(2)如果 product 中不存在对应的键,则会将这个键值对添加到 product 中。

六.DELETE请求类型

功能:删除指定id的产品资源。DELETE请求为删除资源。

实现:后端通过Flask实现@app.route('/products/<int:id>', methods=['DELETE'])

Dify中HTTP请求节点的常见操作

执行Workflow后,在跟踪界面(开始->HTTP请求)可查看最终输出:

Dify中HTTP请求节点的常见操作

七.相关问题

1.API-Key基础、API-Key Bearer、API-Key自定义

API-Key基础: 使用预定义的头字段(如x-api-key)传递API密钥,简单直接。API-Key Bearer: 使用OAuth风格的Bearer Token传递API密钥,更适合需要增强安全性的场景。API-Key自定义: 根据需求自定义API密钥的传递方式,提供更大的灵活性。

(1)API-Key基础

API Key 基础认证是一种简单的认证方式,客户端在请求时将API密钥作为请求的一部分进行传递。通常,它会在请求头中包含一个特定的字段来传递API密钥。示例如下:

GET /resource HTTP/1.1
Host: api.example.com
x-api-key: your_api_key_here

(2)API-Key Bearer

API Key Bearer认证方式类似于使用OAuth的Bearer Token。客户端在请求头中的Authorization字段中传递API密钥,并以"Bearer"作为前缀。这种方式常用于需要更高安全性的场景。示例如下:

GET /resource HTTP/1.1
Host: api.example.com
Authorization: Bearer your_api_key_here

(3)API-Key自定义

API Key自定义认证允许开发人员根据需求自定义API密钥的传递方式。可以将API密钥放在请求的查询参数、请求体中,或者在请求头中使用自定义字段名。这种方式的灵活性较高,但需要确保在客户端和服务器端一致使用同样的方式。

查询参数方式,示例如下:

GET /resource?api_key=your_api_key_here HTTP/1.1
Host: api.example.com

请求体方式,示例如下:

POST /resource HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
"api_key": "your_api_key_here",
"other_data": "value"
}

自定义头字段方式,示例如下:

GET /resource HTTP/1.1
Host: api.example.com
x-custom-api-key: your_api_key_here
2.POST和PUT请求异同

(1)幂等性:POST不是幂等的,而PUT是幂等的。

(2)用途:POST用于创建,PUT用于更新或替换。

(3)URI的知晓:使用POST时,通常不知道新资源的URI;使用PUT时,通常知道资源的URI。

3.form-data和x-www-form-urlencoded异同

当需要上传文件时,应选择 form-data;如果仅需要提交简单的文本表单,x-www-form-urlencoded 是一个更简洁的选择。

(1)form-data 通常用于文件上传或当表单包含文本和文件数据时使用。

Dify中HTTP请求节点的常见操作

(2)x-www-form-urlencoded 通常用于简单的表单提交,当数据仅包含文本内容时使用。

Dify中HTTP请求节点的常见操作

参考文献

[1] HTTP请求:https://docs.dify.ai/v/zh-hans/guides/workflow/node/http_request

 

来源:NLP工程化

0赞

好文章,需要你的鼓励

2024

07/30

14:04

分享

点赞

NLP工程化

专注于Python/C++/CUDA、ML/DL/RL和NLP/KG/DS/LLM领域的技术分享。

最近文章 :