MakeのHTTPモジュールの使い方｜API認証・JSON応答・ページ取得

最初は読取専用のAPIを選ぶ

完成条件は、管理者が許可したAPIから練習用レコードを取得し、IDと状態を表へ保存することです。API提供元の文書でエンドポイント、認証方式、返却形式、制限を確認します。最初から作成・削除を行うAPIへ進まず、少量のGETで接続と応答を見分けられるようにします。例示用URLをそのまま動く実サービスとは扱いません。

HTTP Version 4で認証を登録する

HTTPのMake a requestを追加し、提供元の仕様に合うAPI key、Basic Auth、OAuth 2.0などを選びます。Version 4では専用のCredentials欄を使い、秘密値をクエリや通常のヘッダーへ直書きしない方法が案内されています。URLは許可したHTTPSの接続先に固定し、外部入力から自由に変更させません。

メソッドと検索条件を設定する

MethodをGETにし、必要な条件だけをQuery parametersで指定します。取得上限や対象期間を小さく設定し、1回の確認で大量データを読まないようにします。認証済みでも対象資源の権限がなければ失敗するため、接続成功と業務データの取得成功を別に確認してください。

JSON応答を読み取る

Parse responseを有効にして小さな応答を確認し、status、items、next_cursorなど実際の返却項目を調べます。200でもHTMLのログイン画面が返っている場合や、JSON内のエラー項目で失敗が示される場合があります。応答コードだけで判断せず、Content-Typeと必要なフィールドの存在・型を確認してから保存先へ割り当てます。

ページ分割をAPIの仕様に合わせる

全件取得が必要ならページ番号、offset、次ページURL、カーソルなどAPI側の方式に合わせます。先頭ページだけで完了と扱わず、終了条件と最大ページ数を決めてください。次ページURL方式では認証情報を別のホストへ送らないよう、接続先の扱いを確認します。更新中の一覧では、対象期間や並び順を固定して欠落を調べます。

制限とタイムアウトから復旧する

401・403は認証や対象権限、429は取得速度、5xxは相手側障害の可能性を分けて調べます。提供元が示す待機条件に従い、再試行回数に上限を設けます。読取の再試行と書込の再試行は同じではありません。POSTなどへ広げるときは、応答が来なかった場合でも作成済みかもしれないことを前提に重複対策を設計します。

取得件数と保存件数を比べる

1件、空の結果、2ページ以上、権限不足を確認用のケースにします。取得したIDの集合と保存先を比較し、ページ境界の欠落・重複を点検してください。認証やページ処理を含むMakeの利用量と、API提供元の料金を分けて見積もります。公式アプリで同じ処理ができる場合は、保守しやすい方を選びます。

• MakeでJSONを解析する方法｜オブジェクト・配列・空欄の違い
• Makeのエラー対応｜履歴・未完了実行・安全な再実行の手順
• Makeのクレジット計算｜定期実行・複数行・再実行を数える