使用Deep Chat项目时如何自定义请求参数格式

在基于Deep Chat项目开发聊天应用时，开发者经常会遇到后端服务要求的请求参数格式与前端组件默认发送格式不一致的情况。本文将通过一个典型场景，详细介绍如何优雅地解决这类问题。

问题背景

Deep Chat组件默认发送的请求参数格式为：

{
    "messages": [{
        "role": "user",
        "text": "hello"
    }]
}

然而，许多后端服务（特别是兼容OpenAI API的服务）期望接收的格式却是：

{
    "messages": [{
        "role": "user",
        "content": "hello"
    }]
}

关键区别在于消息内容字段名，前者使用text，后者要求content。

解决方案

Deep Chat提供了requestInterceptor这一强大功能，允许开发者在请求发送前拦截并修改请求参数。这是处理此类格式转换问题的最佳实践。

实现代码示例

chatElementRef.requestInterceptor = async (requestDetails) => {
  return {
      headers: requestDetails.headers,
      body: {
          model: 'gpt-4o', // 添加模型参数
          messages: requestDetails.body.messages.map((message) => {
              return {
                  role: message.role,
                  content: message.text // 将text字段转换为content
              }
          }),
          stream: true // 启用流式响应
      }
   }
}

方案优势

1. 非侵入式修改：不改变Deep Chat内部逻辑，仅对输出进行转换
2. 灵活性高：可以同时添加其他参数（如model、stream等）
3. 可维护性好：转换逻辑集中在一处，便于后续调整

替代方案对比

虽然也可以使用handler函数完全控制请求流程，但相比之下：

• requestInterceptor方案更简洁
• 保持Deep Chat的核心功能不变
• 只需关注需要修改的部分

最佳实践建议

1. 保持向后兼容：转换逻辑应考虑未来可能的格式变化
2. 错误处理：在拦截器中添加适当的错误处理逻辑
3. 性能考虑：对于大量消息，注意转换操作的性能影响
4. 类型安全：在TypeScript项目中，建议为转换后的类型定义接口

总结

通过requestInterceptor实现请求参数格式转换是Deep Chat项目中处理前后端数据格式差异的推荐方案。这种方法既保持了代码的整洁性，又提供了足够的灵活性来满足各种后端API的要求。开发者可以根据实际需求，扩展这一模式来处理更复杂的数据转换场景。