API 連接器構建器
當任務是添加一個倉庫原生的整合介面,而不僅僅是通用的 HTTP 客戶端時,請使用此方法。
重點在於匹配宿主倉庫的模式:
- 連接器佈局
- 配置模式
- 認證模型
- 錯誤處理
- 測試風格
- 註冊/發現接線
使用時機
- "為此專案構建一個 Jira 連接器"
- "按照現有模式添加一個 Slack 提供者"
- "為此 API 創建一個新的整合"
- "構建一個符合倉庫連接器風格的插件"
防護措施
- 如果倉庫已有整合架構,請勿發明新的架構
- 不要僅從供應商文檔開始;應先從現有的倉庫內連接器開始著手
- 如果倉庫預期需要註冊接線、測試和文檔,不要只停留在傳輸代碼層面
- 如果倉庫有更新的當前模式,不要盲目複製舊的連接器
工作流程
1. 學習內部風格
檢查至少兩個現有的連接器/提供者,並對應其:
- 文件佈局
- 抽象邊界
- 配置模型
- 重試/分頁慣例
- 註冊鉤子
- 測試固定裝置及命名
2. 縮小目標整合範圍
僅定義倉庫實際需要的表面:
- 認證流程
- 關鍵實體
- 核心讀/寫操作
- 分頁和速率限制
- Webhook 或輪詢模型
3. 建立在倉庫原生層
典型分層:
- 配置/模式
- 客戶端/傳輸層
- 映射層
- 連接器/提供者入口點
- 註冊
- 測試
4. 針對來源模式進行驗證
新的連接器在代碼庫中應顯得自然而然,而不是從不同的生態系統引入的。
參考形狀
提供者風格
providers/
existing_provider/
__init__.py
provider.py
config.py
連接器風格
integrations/
existing/
client.py
models.py
connector.py
TypeScript 插件風格
src/integrations/
existing/
index.ts
client.ts
types.ts
test.ts
品質檢查清單
- 符合現有的倉庫內整合模式
- 存在配置驗證
- 認證和錯誤處理明確
- 分頁/重試行為遵循倉庫規範
- 註冊/發現接線完整
- 測試鏡像宿主倉庫的風格
- 如果倉庫預期需要,更新文檔/範例
相關技能
backend-patternsmcp-server-patternsgithub-ops