はじめに
更新系APIにおける参照リクエストに必要な機能をメモする。
参照リクエストの目的の定義
シーケンス図は上記のように単純ではあるが、参照リクエスト単独で考えるのではなく、具体的な利用するシナリオを定義すると、多くの必要な機能があることがわかる。
ここでは、次の2つのシナリオに対して参照リクエストに必要な機能を検討する。
- 更新系APIの状態不整合の解決策 参照リクエスト＆リトライ (A03)
- 取消リクエストのタイムアウトによる状態不整合
目的外利用の例
- 不整合が発生していないかを確認するために、定期的にサーバAの保持するすべてのRequestIDの参照リクエストを送信する。
→一気に大量の参照リクエストを送信されるとサーバBの性能問題の原因になる。
必要な機能
必要なパラメータ
参照リクエストにRequestIDを設定すると、サーバBの状態を返却する。
RequestID vs TransactionID
以下の例のように、更新リクエストのレスポンスにTransactionIDが設定されるとしても、レスポンスが通知されないシナリオ（ 更新系APIの状態不整合の解決策 参照リクエスト＆リトライ (A03)）考慮すると、参照リクエストをRequestIDキーでリクエストできるようにするのはマストである。
状態「処理中」が必要な理由
更新リクエストをサーバBで処理中に、参照リクエストを送信した際のレスポンス値について、定義しておくこと。
ここでは、更新リクエストが、「処理済み」or「業務エラー」に処理が完了するまでは、「更新処理中」で返却すると定義する。
「処理中」の実装の難易度が高い場合、「更新リクエスト送信後、X秒間隔をあけてから参照リクエストを送信してください。」とAPI仕様書に明記することで、実装しないことも考えられるが、何秒開ければ確実に処理されるかわからないことが課題となる。
例えば、サーバBが更新リクエストを3秒で確実に処理できるとしても、ネットワークが混雑していて更新リクエストがサーバBに届くのに時間を要することを考えると、x秒を定義できない。
