axiosのHTTP通信を設計するために確認したい機能と境界

ブラウザとNode.jsをまたぐ通信の土台

axiosは、ブラウザとNode.jsで使えるPromiseベースのHTTPクライアントです。READMEは、ブラウザ側ではXMLHttpRequest、Node.js側ではhttpリクエストを用いる構成として説明しています。呼び出し結果をPromiseで受け取れるため、async関数やtryとcatchを組み合わせて、成功時のデータ処理と失敗時の分岐を同じ流れに置けます。ここで提供されるのは通信のためのクライアントであり、認証基盤、キャッシュ層、業務リトライ方針まで自動で決める仕組みではありません。

READMEには、リクエストとレスポンスのインターセプト、データ変換、キャンセル、JSONのシリアライズとパース、multipart/form-dataやapplication/x-www-form-urlencodedのシリアライズが挙げられています。XSRFに対するクライアント側の保護も記載されています。Chrome、Firefox、Safari、Opera、Edgeのサポート表は最新版として示されていますが、各ブラウザの具体的な版やアプリのポリシーは別に確認する必要があります。

導入方法とモジュールの読み込み方

インストール手段は、npm、yarn、pnpm、bun、Denoに分かれています。READMEに示される例はnpm install axios、yarn add axios、pnpm add axios、bun add axios、deno add axiosです。ブラウザから直接使う場合の入口としてjsDelivrとunpkgも案内されています。プロジェクトのロックファイル、Node.jsの版、バンドラーの構成を確認し、自分の配布方法に合う一つの手段を選ぶのが扱いやすい進め方です。

ESモジュールではimport axios, { isCancel, AxiosError } from 'axios'の形が例示され、CommonJSではconst axios = require('axios')が示されています。READMEはrequireで取得できるのはデフォルトエクスポートだけだと説明しています。古い環境向けにはaxios/dist/browser/axios.cjsというブラウザー用CommonJSバンドルにも触れています。依存関係を追加しただけで対象ブラウザや実行環境が確定するわけではないため、ビルド後の成果物と実際の読み込み方法を確認すべきです。

GETとPOSTを失敗処理まで含めて書く

基本例では、tryとcatchの中でaxios.get('/user?ID=12345')を呼び出します。paramsオブジェクトを使えばクエリ値を設定でき、timeoutを5000ミリ秒に指定する例もあります。JSONのbodyを送るPOSTや、二つのGETのPromiseをPromise.allでまとめる並行リクエストもREADMEに掲載されています。APIの呼び出し部分だけを見れば短く書けますが、利用側ではタイムアウト、HTTPエラー、接続エラー、キャンセル後の画面状態を分けて扱う設計が必要です。

READMEはtimeoutの既定値が0で、設定しない通信が停滞したまま無限に待つ可能性を説明しています。したがって、サーバーの応答時間と利用者が待てる時間をもとに値を決めるべきです。asyncとawaitはECMAScript 2017の一部で、Internet Explorerでは対応されないという注意もあります。古いブラウザを対象にするなら、構文変換だけでなく実行時APIと配布物全体を確認してください。

インスタンスで通信先ごとの差を分離する

axiosは設定オブジェクトを直接渡すaxios({ method, url, data })と、URLおよび任意の設定を渡すaxios(url[, config])の二つの書き方を持ちます。request、get、delete、head、options、post、put、patchのエイリアスも用意されています。呼び出しの形を選べる一方、チーム内でどの形式を標準にするかを決めておかないと、認証やエラー処理の差が各画面に散らばります。

axios.create([config])では、baseURL、timeout、headersなどを持つ専用インスタンスを作れます。サービスごとに接続先や共通ヘッダーを分け、インターセプターを必要な範囲へ置くと、設定の責任を整理できます。インスタンスにはメソッドエイリアスとgetUriがあります。READMEはaxios.allとaxios.spreadを非推奨とし、並行処理にはPromise.allを使うよう説明しています。新しいコードではこの方針に合わせるのが自然です。

リクエスト設定を安全側から決める

リクエスト設定ではurlが必須で、既定のmethodはgetです。baseURL、transformRequest、transformResponse、headers、params、paramsSerializer、data、timeout、withCredentials、adapter、auth、responseType、maxContentLength、maxBodyLength、validateStatus、maxRedirects、sensitiveHeadersなどを指定できます。項目が多いからこそ、全設定を共通化するのではなく、公開API、社内API、ファイル取得のように通信の性質を分けて値を持つ方が確認しやすくなります。

セキュリティ上の注意として、READMEはmaxContentLengthとmaxBodyLengthの既定値が-1で無制限だと記載しています。圧縮された小さなbodyが展開後に巨大化する可能性があるため、受け取るデータと送るデータの上限を用途ごとに設定すべきです。baseURLも安全境界ではありません。相対URLに..の要素が入り得るという説明を踏まえ、URLの組み立てを入力値に任せない設計が必要です。paramsSerializerではRFC 3986に沿ったパーセントエンコードを設定できます。

レスポンスの形とHTTPエラーの読み分け

READMEのレスポンスオブジェクトにはdata、status、statusText、headers、config、requestの六つのフィールドがあります。dataはサーバーが返した内容、statusはHTTPステータスコード、statusTextはステータスの文字列です。headersの名前は小文字化され、configにはそのリクエストに使った設定が入ります。requestはNode.jsでは最後のClientRequest、ブラウザではXMLHttpRequestです。画面表示やログに必要な値だけを抽出し、レスポンス全体をそのまま外へ渡さない境界を設けると扱いやすくなります。

Promiseが解決したことと、業務上の処理が成功したことは同じではありません。statusの判定、dataの検証、空レスポンスの処理、再試行できる失敗かどうかをアプリ側で決める必要があります。AxiosErrorを読み込める例や、キャンセル判定用のisCancelもREADMEにあります。秘密情報を含むconfigやheadersをエラー画面とログへ出さないよう、記録項目を明示してから共通エラー処理を作るべきです。

HTTP/2と運用時の検証範囲

Node.jsアダプターにはHTTP/2の実験的サポートがあるとREADMEに記載されています。対応状況はランタイムとNode.jsのバージョンに依存し、リダイレクトや一部のアダプター動作がHTTP/1.1と異なる可能性があります。HTTP/2を使うと決めた場合は、開発時の成功例だけでは足りません。接続確立、証明書、リダイレクト、タイムアウト、ストリームの失敗を対象環境で確認し、HTTP/1.1へ戻す条件も決めておく必要があります。

導入前の確認は、第一に対象ブラウザとNode.jsの版で基本のGET、POST、キャンセルを実行すること、第二にtimeoutとボディサイズ上限が想定通り働くこと、第三にbaseURLへ依存したURL生成が入力値で崩れないことです。次に、インターセプターが認証情報を意図せずログへ送らないか、並行処理の一部失敗をどう表示するかを調べます。MITライセンス、現在の既定ブランチv1.x、公開リリース履歴も確認材料ですが、公開starやissue数だけで運用適性を決めることはできません。

編集部の結論

axiosは、ブラウザとNode.jsの両方で同じ考え方のHTTP処理を組み立てたいJavaScript開発者に向いています。採用時は、通信の失敗をどう扱うか、timeoutとボディサイズ上限を何にするか、baseURLを信頼境界とみなさない設計にできるかを先に決めてください。HTTP/2の挙動やブラウザの対応範囲は実行環境で検証し、READMEの例をそのまま本番設定にしない判断が必要です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes