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请求是获取全部资源。
实现：后端通过Flask实现@app.route('/products', methods=['GET'])：
执行Workflow后，在跟踪界面（开始->HTTP请求->结束）可查看最终输出：
功能：创建一个新的产品。POST请求是创建新资源。
实现：后端通过Flask实现@app.route('/products', methods=['POST'])：
如果出现status_code: 502，且确保POST接口没有问题，那么基本上是设置了Proxy代理问题，关闭代理接口正常运行。
执行Workflow后，在跟踪界面（开始->HTTP请求->结束）可查看最终输出：
功能：根据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请求->结束）可查看最终输出：
功能：替换指定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 中。
功能：删除指定id的产品资源。DELETE请求为删除资源。
实现：后端通过Flask实现@app.route('/products/<int:id>', methods=['DELETE'])：
执行Workflow后，在跟踪界面（开始->HTTP请求）可查看最终输出：
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
（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 通常用于简单的表单提交，当数据仅包含文本内容时使用。
