本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
REST API監視とデータ整合性検証の堅牢な自動化
【導入と前提】 APIレスポンスの検証とデータ抽出を自動化し、システム間の不整合やサイレントフェイルを防ぐ堅牢なパイプラインを構築します。
OS: Linux (Ubuntu 22.04+, RHEL 8+等)
ツール:
curl(7.68.0+),jq(1.6+)
【処理フローと設計】
graph TD
A["Start Script"] --> B["Execute curl with Retry"]
B --> C{"HTTP Status 200?"}
C -- No --> D["Error Notification & Exit"]
C -- Yes --> E["Validate JSON Schema with jq"]
E --> F{"Valid Data?"}
F -- No --> G["Log Invalid Response"]
F -- Yes --> H["Process Data / Success"]
H --> I["Cleanup Temporary Files"]
APIの死活監視だけでなく、ペイロード内の特定フィールドの存在や値をjqの終了ステータスで評価し、パイプラインの停止判断を行います。
【実装：堅牢な自動化スクリプト】
#!/usr/bin/env bash
# set -e: エラー発生時に即座に終了
# set -u: 未定義変数参照時にエラー
# set -o pipefail: パイプライン内のエラーを伝播
set -euo pipefail
# 設定
API_URL="https://api.example.com/v1/health"
EXPECTED_VERSION="1.2.0"
TMP_FILE=$(mktemp /tmp/api_res.XXXXXX)
# 終了時に一時ファイルを確実に削除
trap 'rm -f "$TMP_FILE"' EXIT
echo "Starting API validation for: $API_URL"
# 1. curlによるリクエスト実行
# -s: 進捗バー非表示, -S: エラー時のみメッセージ表示
# -L: リダイレクト追従, --retry: 一時的エラー時の再試行
# -w: HTTPステータスコードのみを抽出
HTTP_STATUS=$(curl -sS -L \
--retry 3 \
--retry-delay 2 \
-o "$TMP_FILE" \
-w "%{http_code}" \
"$API_URL")
# 2. HTTPステータスコードの検証
if [ "$HTTP_STATUS" -ne 200 ]; then
echo "Error: API returned status $HTTP_STATUS" >&2
exit 1
fi
# 3. jqによるペイロード検証
# -e: フィルタの結果がfalseまたはnullの場合、終了コードを1にする
if ! jq -e ".status == \"ok\" and .version == \"$EXPECTED_VERSION\"" "$TMP_FILE" > /dev/null; then
echo "Error: Invalid JSON schema or unexpected version." >&2
cat "$TMP_FILE" >&2
exit 1
fi
# 4. データの抽出と利用
DATA_VALUE=$(jq -r '.data.value' "$TMP_FILE")
echo "Validation Success: Data value is $DATA_VALUE"
定期実行が必要な場合は、以下のsystemdユニットを設定します。
# /etc/systemd/system/api-checker.service [Unit] Description=API Health Checker After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/api_check.sh User=nobody Group=nogroup # /etc/systemd/system/api-checker.timer [Timer] OnCalendar=minutely Unit=api-checker.service [Install] WantedBy=timers.target
【検証と運用】
正常系確認: スクリプトを手動実行し、
$?（終了ステータス）が0であることを確認します。異常系確認: 無効なURLや不正なJSONを返すモックサーバーに対して実行し、非ゼロの終了ステータスとエラーメッセージが標準エラー出力（stderr）に出ることを確認します。
ログ確認:
journalctl -u api-checker.serviceを使用して、systemd経由の実行ログを確認します。
【トラブルシューティングと落とし穴】
レート制限: 短時間の頻繁なリクエストはAPI側でブロックされる可能性があります。
curl --retryだけでなく、適切な実行間隔を設定してください。環境変数の秘匿: APIキーが必要な場合は、スクリプトに直書きせず、
EnvironmentFileやexportを介して環境変数から読み込むように設計してください。jqのパースエラー: 入力が巨大なJSONや壊れたJSONの場合、
jq自体がメモリを消費したりクラッシュしたりする可能性があるため、--max-depthなどの制限も検討してください。
【まとめ】
ステータスコードだけでなく内容を検証:
jq -eを使い、ビジネスロジック的に正しいレスポンスかを確認する。パイプラインの安全確保:
set -euo pipefailにより、隠れたエラーによる不正な後続処理を防ぐ。副作用の管理:
trapを利用して、検証用の一時ファイルがシステムに残らないように制御する。
