はじめに
今回はAIに書かせたコードと勉強中に出てきたコードを見比べてみてaxiosについて理解を深めることを目的としています。
間違っている箇所がありましたら、ぜひコメントで訂正していただけると幸いです。
二つのコードを見比べてみた
今回見比べるコードは以下のコードになります。AIが書いたコードAと,勉強中に出会ったコードBです。
// コードA
import axios from "axios";
export const API_BASE_URL =
import.meta.env.VITE_API_BASE_URL || "http://localhost:5001";
export const api = axios.create({
baseURL: API_BASE_URL,
headers: { "Content-Type": "application/json" },
timeout: 10000,
});
// コードB
import axios from 'axios';
const baseURL = import.meta.env.VITE_API_URL;
const api = axios.create({baseURL});
api.defaults.headers.common['Content-Type'] = 'application/json';
export default api;
主な違い
論理ORについて
コードAでは環境変数がない場合の処理として論理ORを使用しています。||を境に左側がnull or undefinedなら右側を使うという構文です。
API_BASE_URLをexportしている点
これは外でAPI_BASE_URLを使うという意味です。axios以外でも同じAPIの起点を使いたい時です。主に以下の四つの場面が想定されます。
- fetch を直接使うとき（通信の入口が複数ある場合）
- WebSocket / EventSource（axiosでは扱えない通信）
- テスト / デバッグ表示
- モック・スタブ切り替え（環境判定ロジック）
axiosの通信形態は以下の特徴を持ちます。
- HTTP
- Request → Response
- 一発通信
- 状態を持たない
逆にWebSocketは以下になります。 - 接続を張りっぱなし
- 双方向
- イベント駆動
- 状態を共有
timeoutについて
timeoutとはどれだけ待つかの制限時間です。通信を送った時に予期せぬ事態により通信が帰ってこない時にエラーを投げる構文になります。もしtimeoutがない場合、ずっとレスポンスを待つことになります。
ヘッダーの指定方法
ヘッダーの指定方法における静的な設定（create）と動的な設定（defaults）の違いになります。
コードAについて
コードAはインスタンスが生成された瞬間に設定が固定されます。
コードBについて
コードBは設定された後にデフォルト値を書き換えています。リスクとして他のファイルで
api.defaults.headers.common['Authorization'] = 'Bearer token'
のように書き換えた場合、その影響がプロジェクト全体に波及します。そのため複数のAPIエンドポイント（外部サービスなど）を使い分ける際、特定の通信だけに設定したつもりのヘッダーが、予期せず他の通信にまで混入してしまうバグの原因になります。
補足：api.defaults.headers.common["Content-Type"] = 'application/json' について
このコードは、Axiosの階層を深いところまで指定して設定を書き換えています。
- api: axios.create() で作った、あなた専用の通信マシン（インスタンス）です
- defaults: そのマシンが標準（デフォルト）で持っている設定ファイルを開いています
- headers: 設定ファイルの中の「ヘッダー（手紙の宛名や形式）」セクションです
- common: ここが肝です。GET、POST、PUT、DELETEなど、すべてのメソッドに共通してという意味です
- ='application/json': その値を「JSON形式ですよ」と決定しています
結論
AIに書いてもらったコードはとても実践的で拡張性もあると感じました。しかし、一方で意図しない拡張要素が含まれていたり、しっかりと見直す必要があると感じました。私はまだ初心者ですが、これからも日々コードの理解を深めていきたいと思います。