ターミナルで作業するが、curlの構文が扱いにくく、生の出力が読みにくいと感じるなら、curlieは知っておく価値がある。これは、curlをラップし、HTTPieのより親しみやすい構文と色付き出力を取り入れた小さなコマンドラインHTTPクライアントだ。これにより、curlの強力さを犠牲にすることなく、読みやすいレスポンスが得られる。このガイドでは、curlieとは何か、そのインストール方法と使用方法、curlおよびHTTPieとの関連性、そしてアドホックなターミナル呼び出しから保存可能で再現性のあるワークフローへ移行するタイミングについて説明する。
curlieとは何か
curlieはcurlのフロントエンドである。HTTPを再実装しているわけではない。よりシンプルなHTTPieスタイルのコマンドを解析し、同等のcurl呼び出しを構築し、実際の要求をマシン上のcurlバイナリに渡す。結果はシンタックスハイライトと整形されたJSONで返される。
この設計上の選択は重要だ。curlがネットワーク処理を行うため、curlieはcurlのプロトコルサポート、TLS処理、プロキシ動作、そして既知のフラグを継承する。ネイティブなcurlのフラグはそのまま渡すことができる。curlieは、一般的なケースであるリクエストの送信とレスポンスの読み取りをはるかに容易にする。
このプロジェクトは、GitHubでメンテナンスされている単一のGoバイナリとして提供される。インストールするランタイムも、Python環境も、プラグインも不要だ。バイナリをPATHに配置するだけで準備完了だ。
簡単に言えば、curlieはターミナル用の対話型アドホックHTTPクライアントである。エンドポイントを試したり、レスポンスを調べたり、次に進んだりしたいときにこれを使う。テストランナーではなく、そのように設計されているわけでもない。
人々がcurlieを使う理由
curlはどこにでもあるが、その出力は生のバイト列を画面にダンプする。JSONは整形されていない1行で表示され、フラグを追加しない限りヘッダーとボディが混同してしまう。HTTPieは、クリーンな構文と色付き出力で読みやすさの問題を解決したが、それは独自の動作と依存関係を持つ別のPythonツールである。
curlieは両者の中間に位置する。curlのエンジンを基盤に、HTTPieの操作性を得られる。開発者がこれを好む理由はいくつかある。
- デフォルトで読みやすい。レスポンスは色付けされ、JSONは整形されて表示され、ヘッダーは明確に区切られる。
- 馴染みやすい構文。ヘッダー、クエリパラメータ、JSONフィールドの設定には、
-Hや-dフラグを重ねる代わりに、コンパクトなHTTPieスタイルが使われる。 - 基盤はcurl。どのcurlフラグも機能する。curlを知っていれば、curlieのほとんどを知っていることになる。
- 依存関係なし。単一の静的バイナリ。バイナリ自体以外に更新し続けるものはない。
- 詳細モードでcurl呼び出しを表示。
-vオプションで実行すると、ヘッダーと基盤となるリクエストを確認でき、優れた教育ツールとしても機能する。
curlieのインストール
curlieは、プリビルドされたバイナリとして、また一般的なパッケージマネージャーを通じて配布されている。正確なコマンドは時間とともに変わるため、現在の方法はGitHubのリリースぺージで確認してほしいが、一般的な方法は次のようになる。
Homebrewを使用したmacOSの場合：
brew install curlie
Goがインストールされている場合：
go install github.com/rs/curlie@latest
または、リリースぺージからお使いのプラットフォーム用のバイナリをダウンロードし、PATHに移動する：
# 例: ダウンロードしたバイナリをPATH上のどこかに配置
mv curlie /usr/local/bin/
curlie --version
curlieはcurlを呼び出すため、システムにcurlが利用可能である必要がある。macOSおよびほとんどのLinuxディストリビューションでは、curlはすでに存在している。
基本的な使い方
HTTPieを使ったことがあれば、その構文は馴染み深く感じるだろう。GETリクエストはURLと同じくらい短く書ける：
curlie httpbin.org/get
メソッドを指定しない場合、curlieはGETを仮定し、スキームを省略した場合はhttp://を補完する。レスポンスは色付きのヘッダーと整形されたJSONで表示される。
JSONを送信するには、key=valueのペアを使用する。curlieはContent-Type: application/jsonヘッダーを設定し、ボディを構築する：
curlie POST httpbin.org/post name=apidog role=platform
これにより、{"name": "apidog", "role": "platform"}がリクエストボディとして送信される。Header:value形式でヘッダーを追加し、param==valueでクエリパラメータを追加する：
curlie GET httpbin.org/get \
Authorization:"Bearer token123" \
search==apidog
基盤でcurlが実行されているため、短い構文だけでは不十分な場合は、いつでもネイティブなフラグを混ぜて使うことができる：
curlie -v --max-time 5 httpbin.org/get
-vフラグは習慣にする価値がある。これによりリクエストヘッダーとレスポンスヘッダーが出力され、実際に何が通信されたかを正確に確認できる。基盤となるツールについてさらに深く理解したい場合は、curl REST APIガイドがcurlieがラップしている生のフラグについて解説している。
curlie vs curl vs HTTPie
これら3つはすべてターミナルからHTTPリクエストを送信する。違いは構文、出力、そして内部で何が動いているかにある。
| 項目 | curl | HTTPie | curlie |
|---|---|---|---|
| エンジン | libcurl | Python (requestsスタイル) | curl (ラップ) |
| 構文 | フラグ多用 (-X, -H, -d) |
コンパクト (key=value) |
コンパクト、HTTPieスタイル |
| 出力 | 生、整形なし | 色付け、整形済みJSON | 色付け、整形済みJSON |
| インストール | ほぼどこでもプリインストール | Pythonパッケージ | 単一Goバイナリ |
| ネイティブcurlフラグ | あり | なし | あり (パススルー) |
| 依存関係 | なし | Pythonランタイム | curlバイナリ |
| 用途 | スクリプト作成およびアドホック呼び出し | 親しみやすいアドホック呼び出し | 親しみやすいアドホック呼び出し |
率直なまとめ：HTTPieとcurlieは、読みやすさと操作性という同じ問題を異なる方法で解決する。HTTPieは独自の機能セットを持つPythonでの完全な再実装である。curlieは、curlを使い続けるための薄いラッパーだ。チームがcurlのフラグを標準化している場合や、すべてのcurlオプションにパススルーでアクセスしたい場合は、curlieがぴったりだ。HTTPieのより広範な機能面を好み、Pythonの依存関係を気にしないのであれば、HTTPieも良い選択肢となる。弊社のHTTPieチュートリアルではそのツールを詳しく解説しており、どちらを選ぶか迷っている場合は、curlとHTTPieの比較で両者の構文が対応付けられている。
これら3つ以外のターミナルおよびGUIオプションを広く見渡したい場合は、REST APIテスト用curl代替ツールのまとめを参照してほしい。
curlieが適切なツールである場合とそうでない場合
curlieは、迅速な対話型作業でその真価を発揮する：
- エンドポイントが稼働しており、期待する形式を返しているかを確認する。
jqを介してパイプすることなく、JSONレスポンスを目視で確認する。- 開発中にヘッダーや認証をデバッグする。
-vで実際のリクエストを表示するため、HTTPの教育やデモンストレーションに使う。
しかし、繰り返したり、共有したり、自動的に検証したりする必要があるものに対しては、その有用性は薄れる。curlieには保存されたリクエストという概念がない。ステージング環境と本番環境を切り替える環境もない。ステータスコードが200であることや、フィールドが期待値と等しいことをチェックするアサーションもない。パイプラインで午前3時に何かが壊れても、その報告はない。
これはcurlieを非難するものではない。それはアドホックな作業をうまくこなすアドホックなツールだ。しかし、同じcurlieコマンドをドキュメントに貼り付けたり、手書きのgrepチェックを伴うシェルスクリプトにコピーしたりするようになったら、インタラクティブクライアントの本来の用途を超えているということだ。
アップグレードパス：使い捨ての呼び出しから保存可能で再現性のあるワークフローへ
ここでワークフローは自然に分岐する。探索にはcurlieを使い続ける。リクエストをどこかに保存したり、再利用したり、CIで実行したりする必要がある場合は、そのためのプラットフォームに移行する。
Apidogは、まさにこの移行のための永続化およびコラボレーション層である。これはcurlieの直接的なターミナル代替品ではない。ターミナル後の次のステップだ。Apidogを使えば、次のことができる：
- リクエストを保存する：シェルの履歴を再入力したり探し回ったりする代わりに、整理されたコレクションに保存する。
- 環境を管理する：変数を切り替えるだけで、同じリクエストをローカル、ステージング、本番環境に対して実行できる。
- アサーションを追加する：ステータスコード、レスポンスフィールド、スキーマをチェックし、手動での目視確認を自動化する。
- CIでテストを実行する：
apidog runというコマンドラインランナーを使って、保存されたテストシナリオをパイプラインで実行し、合否を報告する。 - チームと共有する：共同作業スペースを通じて、一度デバッグしたリクエストを誰もが再利用できるようにする。
実践的なパターンとして、curlieでエンドポイントを理解できるまで探索し、その後、Apidogでアサーション付きの保存されたリクエストとして再作成する。探索は迅速で使い捨てのままだ。検証は永続的かつ自動化される。チームがエンドポイントの検証方法を正式化する場合、APIテストガイドでは、アサーションとテストシナリオの背後にある概念を網羅している。
よくある質問
curlieはcurlの代替となるのか？
厳密には違う。curlieはcurlの上で動作するため、代替というよりも、より親しみやすいフロントエンドと言える。コンパクトな構文をcurl呼び出しに変換し、出力を整形する。curl自体がエンジンであり、ネイティブなcurlのすべてのフラグはcurlieを通じて引き続き機能する。
curlieはCI/CDパイプラインで機能するのか？
スクリプト内でcurlieを呼び出すことはできるが、自動テスト用には構築されていない。アサーションも、保存されたテストシナリオも、構造化されたレポートもない。パイプライン作業では、レスポンスをチェックし、問題があればビルドを失敗させるランナーが必要となる。Apidogのapidog runコマンドがその役割を担い、主要なAPIテストクライアントのリストでは、再現性がありCIに適したテストのための他のオプションを紹介している。
curlieはHTTPieとどう違うのか？
curlieがHTTPieの構文と色付き出力を模倣しているため、両者は似ていると感じられる。違いはエンジンにある。HTTPieは独自の実装を持つスタンドアロンのPythonツールである。curlieはcurlを薄くラップしたGo製ツールなので、curlの動作を継承し、curlのフラグを直接受け入れる。curlを使い続けたい場合はcurlieを選び、スタンドアロンの機能セットを好む場合はHTTPieを選べばよい。
curlieが実行する実際のcurlコマンドを見ることはできるか？
できる。curlieを-v (詳細表示) フラグ付きで実行すると、リクエストとレスポンスのヘッダー、および基盤となるリクエストの詳細が出力される。これはcurlのフラグを学ぶのに便利な方法であり、何が正確に送信されたかを確認するのにも役立つ。
結論
curlieは賢い小さなツールだ。HTTPieの読みやすい構文と色付き出力を持ち、その裏でcurlが実際の作業を行っている。エンドポイントを試したり、JSONレスポンスを読んだり、ターミナルで認証をデバッグしたりする際に、生のcurlよりも生活の質を向上させる真のアップグレードとなる。ただし、それが何であるかを覚えておいてほしい。それはインタラクティブなクライアントであり、テストランナーではない。
リクエストを保存し、共有し、アサートし、CIで実行する必要がある場合、それは次のレイヤーに進む合図だ。Apidogをダウンロードして、ターミナルで探索したエンドポイントを、チーム全体が信頼できる保存されたリクエスト、環境、および自動テストに変えよう。素早い作業にはcurlieを使い続け、繰り返し行うべき作業はApidogに任せよう。