从 Discord 工作流迁移到 REST API
若希望在自己的产品中管理生成任务，可通过 REST API 调用替代依赖聊天交互的流程，并获得更直接的服务端集成方式。
旧流程与 REST API 流程对照
| 方面 | Discord Bot 方式 | REST API 方式 |
|---|---|---|
| 稳定性 | 界面变动可能导致无声失败 | 由标准 HTTP 请求提交任务 |
| 凭据维护 | 管理 Discord token 与 session | 在服务端管理 API 密钥 |
| 结果跟踪 | 轮询 Discord 消息 | taskId、状态端点与 Webhook |
| 并发控制 | 并行任务管理复杂 | 使用 API 任务与队列管理并发 |
迁移前后有什么不同
基于 Discord Bot 的工作流通常围绕聊天消息、命令与频道事件构建；REST API 工作流由您的服务端提交请求、保存任务 ID，并在自己的界面展示进度和结果。
迁移可让您将认证、用户权限、任务队列和结果存储纳入现有系统。与此同时，您需要负责安全管理、错误处理、速率控制和用户体验。
迁移步骤
- 盘点当前使用的提示词、参数和后处理步骤。
- 建立服务端 API 适配层，并安全配置密钥。
- 把原有命令映射为应用请求和 API 参数。
- 实现异步状态管理、Webhook 接收或受控轮询。
- 先以小流量验证结果和故障恢复，再逐步切换用户。
适合 REST API 的场景
当生成能力需要嵌入自有 Web 应用、SaaS 产品或批处理管线时，REST API 可减少对聊天界面流程的依赖。若团队仍以 Discord 作为主要操作界面，迁移前应权衡维护成本和用户习惯。
常见问题
不要假设机器人命令与 API 字段完全一致；逐项验证参数映射。迁移期间保留回滚方案，并确保用户权限、内容审核与任务状态在新旧系统中一致。
迁移前后的差异
Discord Bot 自动化依赖抓取消息；当 Discord 或 Midjourney 更新界面时可能失效，且需要维护 token、会话和速率限制。轮询频道消息也可能漏掉消息、匹配到错误结果或等待过久。REST API 则通过标准端点提交任务、返回 taskId，并可设置 Webhook 接收结果。
REST API 接入优势
- 标准 REST 端点：POST 提示词后获得 taskId，再查询状态或配置 Webhook。
- Webhook 回调：图像生成完成时 POST 结果，无需抓取 Discord 消息。
- 并行任务：无需在自己的服务中管理 Discord 会话。
- 减少 Discord 依赖：集成不直接依赖 Discord 可用性、条款或 Bot token 状态。
迁移步骤
- 整理 Bot 当前使用的提示词、模式和后续动作。
- 用服务端 REST 请求替换 Discord 命令。
- 用 taskId、状态查询或 Webhook 替代频道消息轮询。
- 在小范围验证结果与异常恢复后逐步切换。
示例提示词
- 示例：a serene mountain landscape。
常见问题
为什么 Discord Bot 不适合 Midjourney 自动化？
Bot 依赖抓取 Discord 消息，界面更新可能使其失效，需要维护 token 与 session，也难以可靠管理并发任务。生产环境使用专用 REST API 通常更稳健。
使用 API 还需要 Midjourney 或 Discord 账户吗？
根据英文原页描述，开发者需要注册 Midjourney API 账户并取得 API 密钥；底层交互由服务处理，调用方发送标准 HTTP 请求。请以账户当前要求为准。
迁移大概要多久？
原页面表示多数团队可在数小时内完成。实际时间取决于现有 Bot 逻辑；提交任务端点和 Webhook 通常可替代消息轮询流程。
API 暂时不可用怎么办？
原页面说明任务会进入队列，短暂中断时在途任务会自动重试，并提供状态页面。实际可用性和恢复行为请查看当前服务状态及文档。