はじめに
更新系APIを使うときや、設計するときに、リクエスト側のサーバAに、レスポンスが通知されないケースで発生する課題を明確にするためメモしておく。
架空のAPIとして更新系APIの仕様はここにまとめておく。
更新系APIの正常ケース
タイムアウトが発生しない正常ケースを、サーバ間通信をイメージしてシーケンス図に示す。
正常
更新リクエストがサーバBで正常に処理されて、サーバAがレスポンスを受信。
業務エラー
更新リクエストをサーバ側は業務エラー※と判定し、サーバAがレスポンス受信
※業務エラーの例
更新権限のないクライアントからの発信
更新リクエストのパラメータが正しくない(シンタックスエラー)
など
更新系APIのタイムアウト
ネットワーク起因で更新リクエストのレスポンスを受信できないケースを整理する。
リクエストがサーバBに通知されない(ケース①)
リクエストがなんらかのネットワーク起因でサーバBに通知されないケースでは、更新処理は行われない（サーバにリクエストが通知されないため、当然サーバはレスポンスを送信しない）
レスポンスがサーバAに通知されない(ケース②)
レスポンスがなんらかのネットワーク起因でサーバAに通知されないケースでは、更新処理は行われるが処理結果がサーバAに通知されない。
OKレスポンスがクライアントへ未通知(ケース②-1)
業務エラーのNGレスポンスがサーバAへ未通知(ケース②-2)
結論 更新系APIのタイムアウトで発生する課題
サーバAがタイムアウトエラーを検知した際、サーバB側で更新しているケース②-1と、更新していないケース①,ケース②-1がある。サーバAでは、サーバBの状態が不明のため、サーバ間の状態が一致していない状態不整合が課題となる。
| ケース① | ケース②-1 | ケース②-2 | |
|---|---|---|---|
| 問題発生個所 | リクエスト | レスポンス | レスポンス |
| サーバA | レスポンスを受信せずタイムアウトエラーを検知し、状態は"不明" | 同左 | 同左 |
| サーバB | 処理なし | 処理済み | 処理なし |