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请求类型。

一.GET请求类型

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

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

执行Workflow后，在跟踪界面（开始->HTTP请求->结束）可查看最终输出：

二.POST请求类型

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

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

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

执行Workflow后，在跟踪界面（开始->HTTP请求->结束）可查看最终输出：

三.HEAD请求类型

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

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

执行Workflow后，在跟踪界面（开始->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'])：

执行Workflow后，在跟踪界面（开始->HTTP请求->结束）可查看最终输出：

五.PUT请求类型

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

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

执行Workflow后，在跟踪界面（开始->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'])：

执行Workflow后，在跟踪界面（开始->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 通常用于文件上传或当表单包含文本和文件数据时使用。

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

参考文献

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