AWS API Gateway ＋ Lambda で自分で用意したエンドポイント
/items と /changes に対して、
実際の Android から HTTP リクエストを送り、レスポンスの形・エラー・レイテンシなどを
細かく確認するためのテスト専用クライアントアプリです。
「test」は、将来の本番アプリ（予定管理・ログ収集・CanSat など）から 叩くことを想定した AWS API を、安全なサンドボックス環境で検証するためのアプリです。 画面上からリクエスト種別（GET/POST/PUT…）やパラメータを指定し、 JSON レスポンスとステータスコード、レスポンスヘッダをそのまま見られるようにしています。
バックエンドは、/items が「現時点のアイテム一覧」、
/changes が「アイテムに対する変更履歴」や「差分アップロード」に対応する想定で、
このアプリではそれぞれに対して CRUD 系の操作を順番に試しながら、
データ構造・バリデーション・エラー処理を調整していきます。
Android アプリから HTTPS で API Gateway の
/items と /changes にアクセスし、
バックエンド側では Lambda 経由でデータストア（DynamoDB や S3 など）を更新します。
test アプリは、この往復を一つずつ観察するための窓口です。
/items と /changes のインターフェイスを定義し、
シリアライザとタイムアウトをまとめて管理。
/items は、「今こういうデータを持っている」という状態を表す API を想定しています。
test アプリからは GET（一覧取得）、POST（新規追加）、PUT（更新）、DELETE（削除）などを順に試し、
レスポンスの JSON スキーマが設計通りになっているかを確認します。
@GET("items")
suspend fun getItems(): List<ItemDto>
@POST("items")
suspend fun createItem(@Body body: ItemDto): ItemDto
/changes は、オフライン中に貯めた更新や、
クライアント側の状態との差分をやり取りするためのエンドポイントとして設計しています。
test アプリでは、小さな JSON パッチを送ってみたり、
連続して同じ変更を送ったときの冪等性（idempotency）をテストします。
{
"clientId": "android-001",
"changes": [
{ "op": "update", "itemId": "abc", "fields": { "title": "new" } }
]
}
本番アプリを作る前に、400/401/403/404/500 といったエラーが どのような JSON で返ってくるかを統一しておくことは重要です。 test アプリでは、あえて不正なリクエストや権限不足の状態を作り、 エラー JSON をきちんとパース・表示できるかを確認します。
if (!response.isSuccessful) {
val errorBody = response.errorBody()?.string()
showError(response.code(), errorBody)
}
APIまわりのトラブルは、「どんな入力を送ったのか」「その時のレスポンス」が すぐに再現できるかどうかで解決スピードが決まります。 test アプリでは、送信した内容と返ってきた JSON を ひとまとまりのログとして保存し、必要に応じて再送できるようにしています。
・/items に対して 50 件のデータがある状態で全件取得 ・/changes に対して同じ変更を 2 回送って冪等性を確認 ・わざと必須フィールドを欠けさせて 400 Bad Request を発生させる といったテストを行い、バックエンドの設計を固めていきました。
・本番用の認可（JWT・Cognitoなど）を入れた時の挙動検証はこれから ・オフライン時に溜めた /changes をどのタイミングで再送するか ・API バージョンアップ時に古いクライアントをどう扱うか といった、運用寄りの課題が見えてきています。
/items と /changes に対して、 いくつかのリクエストを送り、レスポンスとログを確認していく 一連の様子を録画したデモ動画です。
test はあくまで検証用ですが、 ここで作った Retrofit 設定やエラー処理、ログ保存の仕組みは 他のアプリ（osakanakuwaetasazaesan など）でもそのまま使える 共通 API クライアントになり得ます。 今後は本番プロジェクトに組み込める形にリファクタリングしていく予定です。
認証・モジュール化・モニタリングの 3 つの軸で改善を進めます。
自分で設計した API を、実際の Android から叩いてみることで、 「ドキュメント上はきれいでも、実際にはこういうところで詰まる」というリアルな感覚が掴めました。 例えば、タイムアウト・エラー形式・認証ヘッダの付け忘れなど、 細かい部分はテストクライアントがないと気づきにくいところです。
また、ログをちゃんと残しておくことで、 後から「この時どんなリクエストを送ったんだっけ？」を再現できる安心感も得られました。 test アプリで得た知見は、今後のすべてのサーバ連携アプリの「下地」になっていくと思います。