出席管理APIのルート構造改善とSwagger文書の強化

[yuminn-k]

🔍 このPRで解決したい問題は何ですか？

• 既存の出席管理APIのルート構造が一貫性に欠け、RESTful APIの原則に完全に準拠していない問題がありました
• Swagger文書の記述が不十分で、API利用者にとって分かりにくい状態でした
• エラーレスポンスの形式が統一されておらず、クライアント側での処理が煩雑になっていました

✨ このPRで主に変わったことは何ですか？

• APIルートの構造をRESTful原則に基づいて統一（/api/gin/attendancesをベースとした一貫性のある構造）
• 共通のレスポンス型（SuccessResponse、ErrorResponse）を導入し、レスポンス形式を標準化
• Swagger文書に詳細な説明、レスポンスモデル、エラーケースを追加
• エラーハンドリングの共通化と改善

🔖 主な変更点以外に追加で変更された部分はありますか？

• コードのログ出力を強化し、デバッグ時の可読性を向上
• テストケース追加の準備としてのインターフェース改善

🙏🏻 Reviewerに特に見ていただきたい部分はありますか？

• 新しいAPIルート構造が実際のユースケースに適しているか
• エラーレスポンスの形式が十分な情報を提供しているか
• Swagger文書の記述が API利用者にとって分かりやすいものになっているか

🩺 このPRでテストや検証が必要な部分はありますか？

• 各エンドポイントの新しいルート構造での動作確認
• エラーケースでの適切なレスポンス返却の確認
• Swagger UIでの文書表示の確認
• クライアントアプリケーションとの互換性テスト

📚 関連するIssueやJira、ドキュメント

• [MIN-301] 出席データのエラーハンドリング改善および複数追加のサポート #325

🖥 作動する様子

スクリーンショットや録画したビデオ、またはgifを追加して、Reviewerが変更点を理解するのに役立ててください。

📌 PRを行う際の注意点

• Reviewerはコードレビュー時に良いコードの方向性を示しますが、コード修正を強制することはありません。
• Reviewerは良いコードを見つけた場合、賞賛と励ましを惜しみません。
• レビューは特別なケースでない限り、Reviewerに指定された時点から3日以内に行ってください。
• コメント作成時にPrefixにP1、P2、P3を書いていただくと、Assigneeがより明確にコメントに対して対応することができます。
  • P1 : 必ず反映してください (Request Changes) - 問題が発生したり、脆弱性が発見されたケースなど。
  • P2 : 反映を積極的に検討していただければと思います (コメント)。
  • P3 : こんな方法もあるんじゃないかな～などの些細な意見です (Chore)。

[Regulus0811]

✅