コンテンツにスキップ

フロントエンド・バックエンド間通信

非同期処理

フロントエンド・バックエンド間の通信にはFetch APIを使います。 Fetch APIは非同期でリクエストを送信するため、レスポンスの待機中もフロントエンドの処理は継続されます。

Fetch APIを使うのではなく、サードパーティ製のライブラリを使用することも考えられますが、その場合でも非同期で処理されることが一般的です。

リトライ

フロントエンド・バックエンド間の通信では失敗に備えてリトライの機構を用意することで、より安定した通信を行えます。

例えば次に示すHTTPステータスコードが返却された場合に失敗とみなします。

  • 500 Internal Server Error
  • 503 Service Unavailable

リトライはインターバルを置いて失敗時とまったく同じHTTPリクエストを送信します。 どの程度のインターバルを置くかは切り捨て型指数バックオフを用いて算出するのがよいでしょう。 算出方法は次の通りです(単位は秒)。

  • (失敗も含めて)HTTPリクエストを送信した回数をmとする
  • 0から1までのランダム値をnとする
  • 2のm乗 + nとあらかじめ定めた最大インターバルのうち小さい方の値を選択する

例えばHTTPリクエストを送信した回数を4(つまり、これから4回目のリトライを行う)、このときに得られたランダム値を0.5、最大インターバルを32とするとインターバルは16.5秒となります。

リトライの最大回数を決めておき、それを超えて失敗した場合はエラーが発生したことをユーザーへ知らせて処理を終了します。

リトライにおけるバックエンド実装の注意点

HTTPリクエストがバックエンドに到達し、適切に処理された後に何かしらの要因で前段のサーバーなどでエラーになる可能性があります。 そういった場合にリトライされると、同じ内容のHTTPリクエストが複数回バックエンドで処理されることになります。

APIが次に示す特徴のうちどちらかを備えていれば前述のような状況になっても問題はありません。

  • 状態が変更されない(主にGETメソッドで行われるデータ取得系のAPI)
  • 同じ内容のHTTPリクエストであれば何度処理しても同じ結果になる(冪等性)

APIがこれらの性質を持たない場合、アプリケーションに不正な状態をもたらす可能性があります。 そのため、二重送信を防止する仕組みなどを取り入れて対策する必要があります。


※ このドキュメントはFintan コンテンツ 使用許諾条項の下に提供されています。

※ このドキュメントに記載されている会社名、製品名は、各社の登録商標または商標です。