API変更プルリクエストテンプレート
エンドポイント詳細、リクエスト/レスポンス例、バージョニング戦略、後方互換性分析、マイグレーションガイドを含むAPI変更用PRテンプレート。
Process Templates
詳細な説明
API変更PRテンプレート
API変更はダウンストリームの利用者(フロントエンドアプリケーション、モバイルアプリ、サードパーティ統合、他のマイクロサービス)に影響します。このテンプレートはAPI変更が徹底的に文書化され、後方互換性が考慮されることを保証します。
テンプレート構造
## Description
<!-- API変更を記述してください。 -->
## API Changes
### New Endpoints
<!-- 新しいエンドポイントのメソッドとパスを一覧。 -->
### Modified Endpoints
<!-- 既存エンドポイントの変更内容を記述。 -->
### Removed Endpoints
<!-- 削除されるエンドポイントを一覧(ある場合)。 -->
## Backward Compatibility
- [ ] この変更は後方互換性がある
- [ ] マイグレーションパスを文書化したBreaking change
- [ ] APIバージョンをバンプした
## Checklist
- [ ] OpenAPI/Swaggerスペックを更新
- [ ] APIドキュメントを更新
- [ ] リクエストバリデーションを追加
- [ ] レスポンススキーマがドキュメントと一致
- [ ] エラーレスポンスが標準フォーマットに従う
- [ ] レート制限を設定
- [ ] 認証/認可を確認
- [ ] 統合テストを更新
エンドポイントのドキュメント化
構造化されたNew/Modified/Removed Endpointsセクションにより、レビュアーはAPI変更の範囲を一目で理解できます。この情報はチェンジログの生成やAPIコンシューマーへの通知にも有用です。
リクエスト/レスポンス例
具体的な例は抽象的な説明より価値があります。レビュアーがAPIコントラクトを検証し、統合テストのテストケースとして機能します。
後方互換性の評価
後方互換性チェックボックスは、変更が既存コンシューマーを壊すかどうかの明示的な宣言を強制します。パブリックAPIやマイクロサービスアーキテクチャに不可欠です。
マイグレーションガイド
Breaking changeが避けられない場合、Migration Guideセクションはコンシューマーが統合を更新するためのステップバイステップの指示を提供します。このセクションはしばしばリリースノートにコピーされます。
ユースケース
複数のクライアントが消費するREST/GraphQL APIを構築するバックエンドおよびAPI開発チーム。API-first開発を実践するチームやパブリックAPIを管理するチームに必須。