基于政务问答的dify接口请求测试

Dify 的智能体后端服务 API 为开发者提供便捷方式,能让前端应用直接调用大语言模型能力。在请求时,需先前往应用左侧导航的 “API Access” 部分,在此可查看文档和管理访问凭据。为保障安全,API 密钥应通过后端调用,避免在前端代码中暴露。比如文本生成应用,可调用 completion - messages API,向其发送用户输入来获取生成的文本;而对话应用则调用 chat - messages API,首次调用发起对话,后续通过返回的 conversation_id 维持会话,实现与用户的持续问答交互。

Dify发布页面测试:

API方式设置:

点击“监测“,然后点击”API密钥“,进行相关设置

整体代码:

import requests
import json
import time

url = 'http://101.10.1.4:8850/v1/chat-messages'
api_key = 'app-kQ8NiePzWojwefCNRKXG2Xqv'  

headers = {
    'Authorization': f'Bearer {api_key}',
    'Content-Type': 'application/json',
}

data1 = {
    "inputs": {},
    "query": "军人抚恤优待管理单位、参与单位及其工作人员的相关规定有哪些",
    "response_mode": "blocking",
    "conversation_id": "",
    "user": "1"
}
response1 = requests.post(url, headers=headers, json=data1)
print("#########blocking测试\n")
print(response1.json())


data2 = {
    "inputs": {},
    "query": "军人抚恤优待管理单位、参与单位及其工作人员的相关规定有哪些",
    "response_mode": "streaming",
    "conversation_id": "",
    "user": "1"
}

response2 = requests.post(url, headers=headers, json=data2)
print("#########streaming测试\n")

for r in response2.text.split("\n"):
    if r!="":
        r_json = json.loads(r[5:])
        if "answer" in r_json.keys():
            print(r_json["answer"],end="")
            time.sleep(0.01)

for r in response2.text.split("\n"):
    if r!="":
        r_json = json.loads(r[5:])
        if "metadata" in r_json.keys():
            for content_json in r_json["metadata"]["retriever_resources"]:
                print("\n####文件引用:" + content_json["document_name"])
                print(content_json["content"],end="")
                time.sleep(0.01)

代码中包含了阻塞式请求、流式请求2种请求方式。

阻塞式测试结果,

流式测试结果,

总结:

(1)通过接口请求和基于dify网页请求2者的结果基本是相同的,但是细节处还是有些差别,感觉应该是dify网页上还有一些后续的完善和处理的操作。

### HTTP 请求详解 HTTP (HyperText Transfer Protocol) 是用于分布式、协作式和超媒体信息系统的一种协议。它是一个应用层协议,通常运行于TCP之上。HTTP遵循客户端-服务器模型。 #### HTTP请求结构 一个完整的HTTP请求由三部分组成: 1. **请求行** - 方法(如`GET`, `POST`) - URL路径 - 协议版本 2. **首部字段** - 各种元数据信息,例如`Host`, `Content-Type`, `Accept-Encoding` 3. **消息体** - 对于某些方法(如`POST`),这里包含了要提交给服务器的数据[^1] #### 常见问题及其解决方案 ##### 不同服务器解析HTTP头部顺序差异引起的问题 由于不同服务器可能会按照不同的顺序来解析HTTP头,这可能导致一些意外行为。例如,在特定情况下,两个连续的请求可能被误解为单个复合请求的一部分。为了避免此类问题的发生,建议确保每条指令之间有足够的分隔符,并且避免在同一连接上发送多个未完成的消息。 ```http POST / HTTP/1.1 Host: example.com Content-Length: 5 0 GET /malicious HTTP/1.1 Host: example.com ``` 上述例子展示了潜在的风险——当第二个请求紧跟第一个之后而没有适当间隔时,中间件或代理可能会将其视为同一请求的一部分。因此应当保持良好的编码习惯并测试各种环境下的兼容性。 ##### CORS跨域资源共享配置不当引发的安全隐患 现代Web应用程序经常涉及来自不同源的服务交互。为了安全起见,默认情况下浏览器会阻止这种跨站请求除非目标站点明确允许通过设置合适的响应头。如果设置了`withCredentials=true`却将`Access-Control-Allow-Origin:*`作为通配符,则会造成安全隐患,因为这意味着任何网站都可以携带凭证访问资源。正确的做法是在服务端指定具体的域名列表而不是使用星号[^2]。 ```javascript // 客户端代码示例 var xhr = new XMLHttpRequest(); xhr.withCredentials = true; xhr.open('GET', 'url', true); xhr.send(null); // 错误回包配置 // Access-Control-Allow-Origin: * ``` ##### 缓存穿透带来的性能挑战 缓存机制旨在提高读取效率的同时减少对后端存储系统的压力。然而,对于不存在的数据项频繁查询同样会给系统带来负担。一种有效的策略是采用逻辑过期技术:即使物理上的TTL还未到期,也可以提前判定该记录已失效;此时既不会影响正常用户的体验又能防止恶意试探造成的损害[^4][^5]. ```python def get_data_from_cache(key): cached_value, expire_time = cache.get(key) if not expired(expire_time): return cached_value # 如果认为已经过了合理的时间范围, # 则立即给出默认回应并启动后台刷新流程。 update_cache_async(key) return default_response() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值