WebサイトとアプリをAPIで連携するときの設計ポイント

Webサイトとモバイルアプリで同じ情報を扱うとき、個別にデータを持たせると「どちらが最新か」が分からなくなります。API連携の中心は、通信方式を決めることではなく、データと責任の境界を明確にすることです。

最初に「データの正本」を一つ決める

会員情報、契約状態、商品、お知らせなど、連携するデータごとに「どのシステムが正本か」を決めます。例えば、会員と契約はバックエンド、公開用のお知らせはCMSという役割分担です。Webとアプリは正本を直接更新せず、APIで検証された操作だけを依頼します。

認証と認可を分けて考える

「ログインできた」ことと「そのデータを見たり更新したりできる」ことは別の判定です。各APIで、ユーザーの本人確認だけでなく、対象データへの操作権限を確認します。管理者用の機能はエンドポイントを分けるだけでなく、サーバー側で権限を検証します。

OWASP API Security Top 10でも、オブジェクト単位・プロパティ単位・機能単位の認可が重要な論点として整理されています。

アプリの更新時期の違いを吸収する

Webはサーバー側を更新すれば即時に切り替わりますが、アプリはストア審査や利用者の更新に時間がかかります。そのため、APIの変更で旧バージョンのアプリをすぐに切り捨てない設計が必要です。

  • 必須項目の突然な追加や型の変更を避ける
  • 追加項目は旧版が無視できる形にする
  • 破壊的な変更はAPIのバージョンを分ける
  • 古いアプリの利用状況を確認してから廃止する

通信できない状態を正常な分岐として設計する

モバイル環境では、通信の切断やタイムアウトは例外ではなく日常的に発生します。読み取りはキャッシュでどこまで継続できるか、書き込みは再送しても二重登録されないかを決めます。決済や申込みなどの重要な処理では、リクエストごとの一意なキーを使い、同じ操作の繰り返しを検出します。

観測する単位を共通化する

問題が発生したときにWeb、アプリ、APIのログがつながらなければ、原因調査に時間がかかります。リクエストID、APIバージョン、アプリバージョン、結果コードを共通して記録し、個人情報やトークンはログに残さないルールにします。

API連携は、Webとアプリの同時開発だけでなく、将来の更新方法まで含めた設計が必要です。Plan-Kでは、仕様が固まっていない段階でも、データの整理と小さな検証からご支援できます。お問い合わせよりお気軽にご相談ください。

投稿者プロフィール

plan-k

Follow me!