curl チートシート：HTTP・API の 40+ コマンド例

SSH を 3 段重ねてステージング環境の奥まで潜り込んだら、ある API がおかしな値を返してきた。しかも入っている HTTP クライアントは curl だけ。サービスをヘルスチェックする CI スクリプトを読んでいて、-fsS が実際に何をしているのか知りたいこともある。同僚が Slack に貼ったワンライナーを自分の用途に直したいこともある。curl はどこにでもあるが、フラグは簡潔すぎて全部覚えている人はいない。

この curl チートシートは、そういう場面のために書いた。最初に日常的に使う十数個のフラグをまとめたクイックリファレンス表を置き、そのあとはよくあるタスクごとにコピペできるコマンド例を並べた。GET と POST リクエスト、ヘッダーの送信、Bearer トークン認証、ファイルのアップロードとダウンロード、スクリプト内での API テストまで一通りカバーする。どのコマンドも実際に実行できる本物の URL（httpbin.org か api.example.com のプレースホルダー）を使っているので、そのまま貼り付けて試せる。挙動は公式 curl ドキュメントと、現行の HTTP セマンティクス標準である RFC 9110 に従っている。

クイックリファレンス：実際に使う curl フラグ

日常的な curl の 9 割は十数個のフラグで片付く。この表はブックマークしておくといい。以降では、それぞれを実行可能な curl コマンド例とともに見ていく。

フラグ	意味	例
`-X`	HTTP メソッドを指定	`curl -X DELETE https://api.example.com/items/42`
`-H`	リクエストヘッダーを追加（繰り返し可）	`curl -H "Accept: application/json" https://httpbin.org/get`
`-d`	リクエストボディを送信（POST になる）	`curl -d "name=alice" https://httpbin.org/post`
`--json`	JSON ボディを送信し JSON ヘッダーを設定	`curl --json '{"id":1}' https://httpbin.org/post`
`-F`	multipart フォームフィールド／ファイルを送信	`curl -F "file=@report.pdf" https://httpbin.org/post`
`-o`	指定した名前のファイルに出力を保存	`curl -o page.html https://example.com`
`-O`	リモートのファイル名で保存	`curl -O https://example.com/archive.zip`
`-L`	リダイレクトを追う	`curl -L https://httpbin.org/redirect/2`
`-u`	Basic 認証 `user:pass`	`curl -u alice:s3cret https://httpbin.org/basic-auth/alice/s3cret`
`-i`	出力にレスポンスヘッダーを含める	`curl -i https://httpbin.org/get`
`-I`	ヘッダーのみ取得（HEAD）	`curl -I https://example.com`
`-v`	詳細表示：リクエスト + TLS ハンドシェイクを表示	`curl -v https://example.com`
`-s`	サイレント（プログレスメーターなし）	`curl -s https://httpbin.org/get`
`-w`	転送後に変数を出力	`curl -s -o /dev/null -w "%{http_code}" https://example.com`
`-b`	クッキーを送信（文字列またはファイル）	`curl -b cookies.txt https://httpbin.org/cookies`
`-c`	受信したクッキーを jar に保存	`curl -c cookies.txt https://httpbin.org/cookies/set/a/1`
`-k`	TLS 証明書の検証をスキップ	`curl -k https://self-signed.example.com`
`--http2`	HTTP/2 を要求	`curl --http2 https://example.com`
`--http3`	HTTP/3（QUIC）を要求	`curl --http3 https://example.com`
`-T`	PUT でファイルをアップロード	`curl -T backup.tar https://api.example.com/files/backup.tar`
`--data-urlencode`	ボディフィールドを URL エンコード	`curl --data-urlencode "q=hello world" https://httpbin.org/get -G`
`--max-time`	転送全体の最大秒数を制限	`curl --max-time 10 https://example.com`
`--connect-timeout`	接続確立の最大秒数を制限	`curl --connect-timeout 5 https://example.com`
`--retry`	失敗した転送を N 回リトライ	`curl --retry 3 https://example.com`
`--limit-rate`	転送帯域を制限	`curl --limit-rate 2M -O https://example.com/big.iso`

curl 構文の基礎：リクエストの構造

curl コマンドは、バイナリといくつかのフラグと URL でできている。URL はフラグの前でも後でもよく、順序は問われない。問われるのは、どのフラグがメソッドやボディを暗黙のうちに決めるかだ。そこが互いに影響し合う。

シンプルな GET リクエスト

メソッドフラグがなければ、curl は GET を送る。これがコマンドのすべてだ。

curl https://httpbin.org/get

httpbin はリクエストをそのまま JSON で返すので、テストに向いている。クエリ文字列はブラウザと同じ要領で付け加える。

curl "https://httpbin.org/get?page=2&sort=desc"

URL は引用符で囲むこと。むき出しの & はシェルにコマンドのバックグラウンド実行を指示し、その後ろを黙って捨ててしまう。curl で最もよくあるミスの一つで、後述の落とし穴セクションで扱う。

レスポンスを見る：ボディ、ヘッダー、その両方

デフォルトでは curl はレスポンスボディだけを表示する。表示内容を変えるフラグが 3 つある。

# ボディ + ステータスライン + レスポンスヘッダー
curl -i https://httpbin.org/get

# ヘッダーのみ — HEAD リクエストを送信、ボディなし
curl -I https://example.com

# 完全なトレース：リクエストライン、リクエストヘッダー、TLS ハンドシェイク、レスポンス
curl -v https://example.com

ボディに加えて Content-Type や Set-Cookie をさっと確認したいときは -i を使う。ダウンロードせずにリソースを調べたいとき（ファイルサイズ、最終更新日時、リダイレクト先）は -I。何かおかしくて、curl が実際に何を送ったのかを正確に見たいときは -v の出番だ。

リダイレクトを追う

curl は指示しない限りリダイレクトを追わない。-L なしで 301 や 302 を返す URL を叩くと、リダイレクト先ではなくリダイレクトレスポンスそのものが返ってくる。

# 302 で止まり、有用なものは何も表示しない
curl https://httpbin.org/redirect/1

# 連鎖を最後の 200 まで追う
curl -L https://httpbin.org/redirect/1

リクエストがどこに着地するか分からないときは、-IL が各ホップのステータスコードを表示する。それぞれのコードの意味と、301 と 302 を取り替えてはいけない理由は、HTTPステータスコード早見表で確認できる。

curl での HTTP メソッド（GET、POST、PUT、PATCH、DELETE）

curl はフラグからメソッドを自動で選ぶ。-d や --json は POST を、素の URL は GET を意味する。-X を使うのは、送るボディに合わないメソッドが必要なときだけでいい。

クエリパラメータ付きの GET

値にスペースや & が混じると、クエリ文字列を手で組み立てるのはミスのもとだ。-G を付けると、curl は --data-urlencode のフィールドを、正しくエンコードしたクエリ文字列として URL に付け足す。

curl -G https://httpbin.org/get \
  --data-urlencode "q=hello world" \
  --data-urlencode "tag=c++"

これで ?q=hello%20world&tag=c%2B%2B ができる。パーセントエンコーディングは curl 側が処理するので、壊れた URL を送らずに済む。

POST：フォームデータ vs JSON

curl post request には、よくある形が 2 つある。フォームエンコード（古典的な HTML フォームのボディ）はこうだ。

curl -d "name=alice&role=admin" https://httpbin.org/post

-d は Content-Type: application/x-www-form-urlencoded を設定し、メソッドを POST に切り替える。JSON API には、代わりに JSON を送る。

curl -d '{"name":"alice","role":"admin"}' \
  -H "Content-Type: application/json" \
  https://httpbin.org/post

これにはもっとすっきりした方法がある。次のセクションで扱う。

PUT と PATCH

PUT はリソースを置き換え、PATCH はその一部を更新する。PUT は冪等だ。2 回送っても同じ状態になる。

# リソース全体を置き換え
curl -X PUT -d '{"name":"alice","role":"owner"}' \
  -H "Content-Type: application/json" \
  https://api.example.com/users/7

# フィールドを 1 つ更新
curl -X PATCH -d '{"role":"owner"}' \
  -H "Content-Type: application/json" \
  https://api.example.com/users/7

DELETE

DELETE は通常ボディを持たないので、-X だけで十分だ。

curl -X DELETE https://api.example.com/users/7

ヘッダーと JSON ボディの送信

実際の API 作業はほとんどがヘッダーと JSON だ。主役になるフラグは -H と --json の 2 つである。

`-H` でのカスタム curl ヘッダー

-H はヘッダーを 1 つ追加する。必要なだけ繰り返せる。Accept、Authorization、カスタムの X- ヘッダー、リクエスト ID を設定するのはこうやる。

curl https://httpbin.org/headers \
  -H "Accept: application/json" \
  -H "X-Request-Id: 9f3c1a" \
  -H "User-Agent: my-cli/1.0"

curl が本来送るデフォルトのヘッダーを消すには、空の値を与える（-H "User-Agent:"）。値のないヘッダーを送るには、セミコロンを使う（-H "X-Empty;"）。

POST JSON：`-d` vs モダンな `--json` フラグ

curl 7.82 以降は、--json が JSON の curl post request を送る慣用的なやり方だ。これは 3 つの仕事を一度にこなす。Content-Type: application/json と Accept: application/json を設定し、ボディをそのまま送る。

# 冗長な古いやり方 — 同期させるべき 3 つのピース
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name":"alice"}' \
  https://httpbin.org/post

# モダンな同等版
curl --json '{"name":"alice"}' https://httpbin.org/post

--json は繰り返すと連結され、--json @file.json ならファイルからボディを読み込む。JSON API にはこちらを使おう。

Content-Type と Accept

この 2 つのヘッダーが、415 や 406 エラーの発生源になる。Content-Type は送るボディを表し、Accept は受け取りたいものを伝える。フォームデータしか受け付けないエンドポイントに JSON を送ると 415 Unsupported Media Type が返り、JSON 専用 API に XML を求めると 406 Not Acceptable が返ることがある。（これらのコードは HTTPステータスコード早見表で解説している。）

レスポンスが圧縮された JSON の壁になって返ってきたら、JSON整形ツールで整形するか、jq にそのままパイプしてフィールドを 1 つ抜き出そう。

curl -s https://httpbin.org/json | jq '.slideshow.title'

jq フィルターの全体（API レスポンスの選択、マッピング、再構成）については、jq チートシートにまとめてある。

curl での認証

4 つの認証スタイルを押さえれば、ほぼすべての API に対応できる。Basic 認証、Bearer トークン、API キー、クッキーだ。

Basic 認証（`-u user:pass`）

-u は、Base64 エンコードした認証情報を持つ HTTP の Authorization: Basic ヘッダーを送る。

curl -u alice:s3cret https://httpbin.org/basic-auth/alice/s3cret

パスワードを省くと（-u alice）、curl がパスワードを対話で尋ねるので、シェル履歴に残らずに済む。

Bearer トークンと OAuth

モダンな API のほとんどは curl bearer token を使う。OAuth 2.0 のアクセストークンや API トークンを Authorization ヘッダーに入れる方式だ。curl には --oauth2-bearer というショートハンドがあり、ヘッダーを手書きするのと同じ結果になる。

# 明示的なヘッダー
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc" \
  https://api.example.com/me

# ショートハンド
curl --oauth2-bearer "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc" \
  https://api.example.com/me

バックエンドがトークンを拒否したら、curl を疑う前に JWTデコーダーでデコードして、exp（有効期限）、aud（オーディエンス）、iss（発行者）のクレームを確認しよう。原因はたいてい、期限切れかオーディエンス違いのトークンだ。

API キー（ヘッダー vs クエリパラメータ）

キーをヘッダーに入れさせる API もあれば、クエリパラメータに入れさせる API もある。URL はログやブラウザ履歴に漏れるので、ヘッダーのほうが安全だ。

# 推奨：キーをヘッダーに入れる
curl -H "X-API-Key: sk_live_a1b2c3" https://api.example.com/data

# 安全性が低い：キーを URL に入れる（アクセスログに残る）
curl "https://api.example.com/data?api_key=sk_live_a1b2c3"

クッキー（送信は `-b`、保存は `-c`）

-c はクッキー jar を書き出し、-b はそれを読み戻す。複数のリクエストをまたいでセッションを引き継ぐにはこうする。

# ログインしてセッションクッキーを保存
curl -c jar.txt -d "user=alice&pass=s3cret" https://httpbin.org/cookies/set/session/abc123

# 次の呼び出しで再利用
curl -b jar.txt https://httpbin.org/cookies

セキュリティ上の注意： トークンや認証情報は HTTPS 接続でのみ扱うこと。TLS はヘッダーを暗号化するが、平文の HTTP は暗号化しない。シークレットをコマンドラインに直接書くのも避けよう。シェル履歴や ps の出力に残ってしまう。ヘッダーは -H @authfile でファイルから読むか、環境変数から値を引いてくるとよい（-H "Authorization: Bearer $TOKEN"）。

ファイルのダウンロードとアップロード

curl が「client URL」と名付けられたのは、ファイルの移動が本来の仕事だからだ。ダウンロードにもアップロードにも、覚えておく価値のあるフラグがいくつかある。

ダウンロード：`-O` vs `-o` vs `-C -`

-O（大文字の O）はファイルをリモートの名前で保存する。-o（小文字）は名前を自分で選べる。-C - は中断したダウンロードを途中から再開する。

# リモートのファイル名で保存：archive.zip
curl -O https://example.com/downloads/archive.zip

# 自分で選んだ名前で保存
curl -o backup.zip https://example.com/downloads/archive.zip

# 中断したダウンロードを再開
curl -C - -O https://example.com/downloads/archive.zip

# リダイレクトを追って本物のファイルへ（CDN でよくある）
curl -OL https://example.com/latest/archive.zip

リダイレクトの先にある curl download file のコンテンツを取りに行くには -L を付ける。リリースページや CDN リンクはほぼ必ずリダイレクトする。

アップロード：`-T` vs `-F`

-T は PUT でファイルをアップロードし、生のバイト列をボディとして送る（オブジェクトストレージや REST のファイルエンドポイントでよくある）。-F は multipart/form-data リクエストを送る。ブラウザがファイル入力に使うのと同じ形式だ。

# 生のバイト列を PUT
curl -T report.pdf https://api.example.com/files/report.pdf

# multipart/form-data アップロード（@ プレフィックスに注意）
curl -F "file=@report.pdf" -F "title=Q2 report" https://httpbin.org/post

@ プレフィックスは、ファイルの中身を読むよう curl に指示する。これがないと、-F "file=report.pdf" はファイルではなく report.pdf という文字列リテラルを送ってしまう。

`--data-urlencode` とパーセントエンコーディング

値にスペース、&、=、非 ASCII 文字が混じると、-d はそれをそのまま送ってリクエストを壊す。--data-urlencode なら正しくエンコードされる。

# 間違い：& がボディを分断し、スペースは不正
curl -d "q=hello world&filter=a&b" https://httpbin.org/post

# 正しい：各フィールドがパーセントエンコードされる
curl --data-urlencode "q=hello world" \
  --data-urlencode "filter=a&b" \
  https://httpbin.org/post

その %20 や %26 というシーケンスの意味を知りたいときや、二重エンコードされた値をデバッグしたいときは、URLエンコード・デコードに貼り付けるか、URLエンコード・デコード実践ガイドのバイトレベルの解説を読むといい。

API テストとレスポンスの検査

curl はスクリプトと CI で真価を発揮する。-w が転送に関するあらゆる数値を引き出し、終了コードで失敗を検出できるからだ。

ステータスコードだけ

HTTP ステータスだけを取得するには、-o /dev/null でボディを捨て、-w でコードを出力する。

curl -s -o /dev/null -w "%{http_code}\n" https://httpbin.org/status/204
# → 204

これがあらゆる curl api testing ヘルスチェックの中核になる。返ってきた数字の解釈には、HTTPステータスコード早見表が全範囲をカバーしている。

タイミングの内訳

-w はタイミング変数を出力するので、時間がどこで消費されているか（DNS、TCP 接続、TLS、それともサーバー自体か）を見られる。

curl -s -o /dev/null \
  -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n" \
  https://example.com
# → dns=0.004s connect=0.021s tls=0.058s total=0.142s

time_appconnect が大きければ TLS を、time_starttransfer が大きければ遅いバックエンドを指している。

サイレントでもエラーは表示する

-s はプログレスメーターを隠すが、エラーメッセージまで隠してしまう。スクリプトでの落とし穴だ。-S と組み合わせれば、成功時は静かなまま、失敗だけはきちんと報告される。

curl -sS https://api.example.com/health

CI／スクリプトでの curl：HTTP エラーで失敗させる

デフォルトでは、curl は 404 や 500 でも終了コード 0 を返す。転送そのものは成功しているからだ。ヘルスチェックでは、これは望みとは正反対の挙動になる。-f（fail）を付けると、curl は HTTP エラーで非ゼロ終了するので、パイプライン側でそれを捕まえられる。

# エンドポイントが 4xx/5xx を返したらビルドを失敗させる
curl -fsS https://api.example.com/health || exit 1

-fsS（fail、silent、show-errors）が定番のヘルスチェックの組み合わせだ。もっと詳しい診断情報が欲しければ、--fail-with-body（curl 7.76+）が終了前にエラーレスポンスを表示する。

タイムアウトとリトライ

永遠にハングするヘルスチェックは、すぐ失敗するものより厄介だ。スクリプト化したリクエストには必ず --max-time（転送全体の上限）と --connect-timeout（接続確立だけの上限）を付けて上限を設ける。

# 接続 5 秒、合計 10 秒で打ち切る
curl --connect-timeout 5 --max-time 10 -fsS https://api.example.com/health

ネットワークが不安定なときは、--retry が指数バックオフで失敗した転送を再試行する。デフォルトでは一時的な失敗（タイムアウト、5xx）だけを再試行するが、--retry-all-errors を加えれば接続拒否も再試行できる。

# 最大 3 回、間隔を空けて再試行
curl --retry 3 --retry-all-errors --max-time 30 -fsS https://api.example.com/health

スクリプトで大きなファイルを取得しつつ回線を飽和させたくない場合は、--limit-rate が帯域を制限する。--limit-rate 2M で 2 MB/s に抑える。

curl での HTTP/1.1、HTTP/2、HTTP/3

curl は ALPN を介して TLS 上で HTTP バージョンをネゴシエートする。特定のプロトコルパスをテストしたいときは、バージョンを強制できる。

`--http2` と `--http3`

# HTTP/2 を要求（利用できなければ 1.1 にフォールバック）
curl --http2 https://example.com

# QUIC 上で HTTP/3 を要求
curl --http3 https://example.com

HTTP/3 は QUIC 上で動き、TLS 1.3 を必要とする。動くのは、手元の curl が HTTP/3 対応のバックエンドでビルドされていて、なおかつサーバーが Alt-Svc ヘッダーでそれを告知している場合だけだ。curl --version を実行して、features 行に HTTP3 が出るか確認しよう。なければ --http3 はエラーになる。

詳細な TLS／ALPN 情報

-v はネゴシエートされたプロトコルと TLS ハンドシェイクを表示する。バージョンが実際に効いたかどうかは、これで確認する。

curl -v --http2 https://example.com 2>&1 | grep -i "ALPN\|HTTP/2"
# → * ALPN: server accepted h2
# → > GET / HTTP/2

ハンドシェイク出力で ALPN: server accepted h2（HTTP/2）か h3（HTTP/3）を探そう。

よくある curl の落とし穴 8 つ（とその直し方）

この 8 つには、誰もがいずれ引っかかる。

シングルクォート vs ダブルクォート。 ダブルクォートはシェルに $VARS を展開させ、シングルクォートはすべてをそのまま渡す。JSON ボディにはシングルクォートを使って $ や ! が解釈されないようにする：curl --json '{"price":"$5"}'。展開をさせたいときはダブルクォートを使う：-H "Authorization: Bearer $TOKEN"。
-d は URL エンコードしない。 -d の値にスペースや & があるとボディが壊れる。まだエンコードされていない値には --data-urlencode に切り替えよう。
-d に添える冗長な -X POST。 -d はすでに POST を意味する。-X POST -d ... と書いても害はないが冗長だ。もっと厄介なのは -X GET -d ... で、GET でボディを送るため、一部のサーバーが面食らう。メソッドはボディフラグに決めさせよう。
ファイルから読むときの @ の付け忘れ。 -d @body.json はファイルを読むが、-d body.json は body.json という文字列リテラルを送る。-F "file=@upload.png" 対 -F "file=upload.png" も同じ落とし穴だ。
証明書エラーですぐ -k に手を伸ばす。 -k は TLS 検証を無効にし、本当の問題（期限切れの証明書、ホスト名違い、中間証明書の欠落）を覆い隠す。根本原因を直そう。--cacert ca.pem で CA を入れるか、システムのトラストストアを更新する。-k は、自分で完全に管理している自己署名の開発サーバー用に取っておこう。
-s がエラーを飲み込む。 サイレントモードはスクリプト内の失敗を隠す。常に -sS を使い、エラーが表に出るようにしよう。
URL 内の [ ] { } がグロブされる。 curl は [1-5] や {a,b} を URL の範囲やリストとして扱う。リテラルなブラケットを含む URL（arr[]=1 のような配列クエリパラメータでよくある）は壊れる。-g でグロブを無効にしよう：curl -g "https://api.example.com/items?id[]=1&id[]=2"。
ヘッダーの大文字小文字と重複。 HTTP のヘッダー名は大文字小文字を区別しないが、同じヘッダーを 2 回送ると、ふつうは両方が送られる。最初を取るサーバーもあれば、最後を取るサーバーも、拒否するサーバーもある。User-Agent のようなデフォルトを上書きするなら、順序に頼らず -H で一度だけ設定しよう。

curl vs wget vs HTTPie：どれを使うか

3 つとも HTTP 経由で取得する点は同じだが、得意とする仕事が違う。curl vs wget（に HTTPie を加えた）判断を一目で見るとこうなる。

タスク	curl	wget	HTTPie
クイックな API 呼び出し／デバッグ	優秀	限定的	優秀
JSON ボディ	良好（`--json`）	不便	優秀（ネイティブ）
再帰的なサイトダウンロード／ミラーリング	不可	優秀（`-r`）	不可
大きなダウンロードの再開 + リトライ	良好（`-C -`）	優秀（組み込み）	不可
スクリプト／CI（終了コード、`-w`）	優秀	良好	良好
デフォルトで見やすい色付き出力	不可	不可	優秀
ほぼどこにでもプリインストール済み	はい	しばしば	まれ

手短に言えば、API のデバッグとスクリプトには curl（どこにでもあり、-w は他にない）、自分のマシンで読みやすい JSON の操作感が欲しいときは HTTPie、サイトのミラーリングや自動リトライ付きのファイル一括ダウンロードには wget を選ぶといい。

よくある質問

curl は何に使うのか？

curl は、HTTP、HTTPS、FTP をはじめ多くのプロトコルでサーバーとデータをやり取りするコマンドラインツールだ。開発者は API の呼び出しとデバッグ、ファイルのダウンロードとアップロード、スクリプトや CI パイプラインでのヘルスチェックに使う。

curl で POST リクエストを送るには？

フォームデータには -d、JSON には --json を使う：curl --json '{"name":"alice"}' https://httpbin.org/post。どちらのフラグもメソッドを自動的に POST に設定するので、-X POST は不要だ。

curl でヘッダーを追加するには？

-H "Name: value" を使い、ヘッダーが複数あれば繰り返す：curl -H "Accept: application/json" -H "X-Request-Id: 9f3c1a" https://httpbin.org/headers。-H を渡せる回数に上限はない。

curl で Bearer トークンを送るには？

Authorization ヘッダーを渡す：curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/me、またはショートハンドの --oauth2-bearer YOUR_TOKEN を使う。トークンは HTTPS 経由でのみ送り、デバッグ時は JWTデコーダーでデコードしよう。

curl でファイルをダウンロードするには？

リモートのファイル名を保つには -O、自分で名前を選ぶには -o name：curl -O https://example.com/archive.zip。リダイレクトを追うなら -L、中断したダウンロードを再開するなら -C - を付け加える。

curl で HTTP ステータスコードだけを見るには？

ボディを捨ててコードを出力する：curl -s -o /dev/null -w "%{http_code}" https://example.com。これがスクリプトでのヘルスチェックの標準的なパターンだ。

curl と wget の違いは？

curl は単一のリソースを転送し、デフォルトで標準出力に書き込むので、API 呼び出しやスクリプトに向く。wget はダウンロードに特化していて、再帰的なミラーリングや自動リトライを備える。API テストには curl を、ファイルの一括ダウンロードには wget を使おう。

curl は Windows で使えるか？

使える。curl は Windows 10（ビルド 1803+）と Windows 11 に同梱されていて、コマンドプロンプトでも PowerShell でも curl として呼べる。ただし PowerShell は昔から curl を Invoke-WebRequest のエイリアスにしているので、フラグの挙動がおかしいときは curl.exe を明示的に呼ぼう。

まとめ

curl は、少し覚えるだけで十分に元が取れる。冒頭のフラグ表が、打ち込むものの大半をカバーしている。あとは、どのフラグがメソッドを暗黙のうちに決めるか、どれが引用符を必要とするか、どれがスクリプトであなたを欺くか（むき出しの -s、お前のことだ）を押さえておけばいい。この curl チートシートは、ターミナルの隣に開いておこう。コマンドを視覚的に組み立てたい場合は、cURL コマンドビルダーも試してみてほしい。

API ワークフローの次の一手は、たいていクリック一つ先にある。curl でリクエストを送り、HTTPステータスコード早見表で返ってきたものを読み、JSON整形ツールで JSON を整形するか、jq チートシートでスライスする。オプションの全リストは curl マニュアルが網羅的で、MDN の HTTP リファレンスが各メソッドとヘッダーの背後にあるセマンティクスを説明している。