跳轉到

API 總覽

這一頁先提供功能分區與接法建議，不嘗試把每一支 API 的細節全部列成表格。
若未來要補到 Swagger 之外的完整接口手冊，建議再拆成多頁。

API 入口

啟動後可透過：

  • Swagger UI: /docs
  • ReDoc: /redoc

功能分區

1. 一般回測控制

  • GET /state
  • POST /set_ticker
  • POST /set_time_range
  • GET /get_time_range
  • POST /set_timeframe
  • GET /get_timeframe
  • GET /get_timeframe_list
  • POST /backfill

典型流程

  1. POST /set_ticker
  2. POST /set_strategy
  3. POST /set_timeframe
  4. POST /set_time_range
  5. GET /get_params
  6. GET /state

2. 策略與參數管理

  • GET /strategy_list
  • GET /get_strategy
  • POST /set_strategy
  • POST /set_params
  • GET /get_params
  • POST /set_params_for_combination
  • GET /get_params_for_combination
  • GET /get_all_combinations
  • GET /get_ticker_combinations
  • POST /reset_params_for_combination
  • GET /get_params_schema

接法建議

一般回測頁

  • 使用 set_strategy + get_params + set_params

多組合管理頁

  • 使用 get_params_for_combination + set_params_for_combination
  • 明傳 ticker / timeframe_minutes / strategy_name

3. 回測歷史

  • GET /backtest_history
  • GET /backtest_result/{record_id}
  • GET /backtest_params/{record_id}
  • GET /export_params/{record_id}
  • POST /clear_history

特性

  • 一般回測會記錄歷史摘要
  • 歷史結果可能來自記憶體 cache 或重跑
  • 舊紀錄若沒有 strategy_name，會使用目前邏輯做相容處理

4. 備註系統

  • POST /notes/add
  • GET /notes/all
  • POST /notes/get
  • POST /notes/delete

注意

備註目前主要依：

  • ticker
  • timeframe_minutes
  • params_hash

做關聯，而不是正式以 strategy_name 當主鍵維度。

5. 訓練區間

  • GET /api/training/chart_data
  • POST /api/training/param_range
  • GET /api/training/param_ranges
  • GET /api/training/param_range/{range_id}
  • PUT /api/training/param_range/{range_id}
  • DELETE /api/training/param_range/{range_id}
  • POST /api/training/param_ranges/batch

作用

這一塊不是模型訓練，而是：

  • 給前端畫圖
  • 人工標記區間
  • 保存某段時間對應的一組參數

6. 多區段回測

  • POST /multi_params/segments
  • GET /multi_params/segments
  • GET /multi_params/segments/{segment_id}
  • PUT /multi_params/segments/{segment_id}
  • DELETE /multi_params/segments/{segment_id}
  • GET /multi_params/result

重要提醒

這一塊目前與新主流程存在結構落差，尤其是策略維度尚未完全統一。

若你把系統視為新架構：

  • 一般回測：strategy-aware
  • 最佳化：strategy-aware
  • multi_params：尚未完全 strategy-aware

7. 最佳化任務

  • POST /optimization/tasks
  • GET /optimization/tasks
  • GET /optimization/tasks/{task_id}
  • GET /optimization/tasks/{task_id}/progress
  • POST /optimization/tasks/{task_id}/run
  • PATCH /optimization/tasks/{task_id}
  • POST /optimization/tasks/{task_id}/clone
  • GET /optimization/tasks/{task_id}/results
  • DELETE /optimization/tasks/{task_id}

建議前端流程

  1. 建立任務：POST /optimization/tasks
  2. 執行任務：POST /optimization/tasks/{task_id}/run
  3. 輪詢進度：GET /optimization/tasks/{task_id}/progress
  4. 查看結果：GET /optimization/tasks/{task_id}/results?limit=50&offset=0

為什麼要這樣接

系統已做過 task API 的輕量化優化：

  • 列表不回傳大 results
  • 單一進度有專用輕量端點
  • 結果支援 limit + offset

因此不建議前端在輪詢期間一直打完整 task 詳情或完整 results。

8. 最佳化結果收藏

  • POST /optimization/records/toggle
  • GET /optimization/records
  • DELETE /optimization/records/{record_id}
  • DELETE /optimization/records

這一層是給人工挑選優秀結果、做後續整理用。

錯誤處理慣例

多數 API 使用：

{
  "detail": "錯誤訊息"
}

常見 HTTP 狀態：

  • 200 成功
  • 400 請求錯誤 / 驗證不通過
  • 404 資源不存在
  • 500 伺服器錯誤

建議前端不要做的事

  • 不要自己硬寫可用策略清單，請讀 /strategy_list
  • 不要輪詢 GET /optimization/tasks/{task_id}?include_results=true
  • 不要假設所有回測子系統都已完整支援 strategy_name
  • 不要以舊文件中的欄位名為準，請以 Swagger 與目前實作為準