api-connector-builder

Topics in the source

• API コネクター ビルダー
• 使用するとき
• ガード レール
• ワークフロー
• 1. ハウス スタイルを学ぶ
• 2. ターゲット統合を絞り込む
• 3. リポジトリネイティブ レイヤーで構築
• 4. ソース パターンに対して検証

リポジトリネイティブな統合サーフェスを追加する場合に使用します。汎用 HTTP クライアントではありません。 ポイントはホスト リポジトリのパターンと一致することです： コネクター レイアウト 構成スキーマ 認証モデル エラー処理 テスト スタイル 登録/発見ワイヤリング 「このプロジェクトの Jira コネクターを構築する」 「既存のパターンに従う Slack プロバイダーを追加する」 「この API の新しい統合を作成する」 「リポジトリのコネクター スタイルに一致するプラグインを構築する」 リポジトリに既に統合アーキテクチャがある場合は、新しい統合アーキテクチャを発明しないでください。 ベンダー ドキュメントだけから始めないでください。最初に既存の repo 内コネクターから始めてください。 リポジトリがレジストリ ワイヤリング、テスト、およびドキュメントを期待する場合は、トランスポート コードで停止しないでください。 リポジトリに新しい現在のパターンがある場合は、古いコネクターをカーゴカルト化しないでください。 少なくとも 2 つの既存のコネクター/プロバイダーを検査して、マップしてください： ファイル レイアウト 抽象化の境界 構成モデル 再試行 / ページネーション コンベンション レジストリ フック テスト フィクスチャと命名 リポジトリが実際に必要とするサーフェスのみを定義します： 認証フロー キー エンティティ コア読み取り/書き込み操作 ページネーションとレート制限 Webhook またはポーリング モデル 一般的なスライス： 構成/スキーマ クライアント/トランスポート マッピング レイヤー コネクター/プロバイダー エントリ ポイント 登録 テスト 新しいコネクターは、別のエコシステムから インポートされたのではなく、コードベースで明白に見えるはずです。 [ ] 既存の repo 内統合パターンに一致します [ ] 構成検証が存在します [ ] 認証とエラー処理が明示的です [ ] ページネーション/再試行動作がリポジトリ規範に従います [ ] レジストリ/発見ワイヤリングが完成しました [ ] テストはホスト リポジトリのスタイルを反映しています [ ] ドキュメント/例がリポジトリで期待されている場合は更新されます backend-patterns mcp-server-patterns github-ops