Hurl - コマンドラインで HTTP リクエストとテストを行うためのテキストベースツール

 (github.com/Orange-OpenSource)
27 ポイント 投稿者 GN⁺ 2025-06-21 | 3件のコメント | WhatsAppで共有
  • シンプルなテキストファイル形式で HTTP リクエストを実行でき、複数リクエストのチェーン、値の抽出、レスポンス本文やヘッダーに対するクエリ／検証が可能なオープンソースのコマンドラインツール
  • REST、SOAP、GraphQL など多様な API と HTML/XML/JSON ベースのリクエストをサポートし、データ取得と HTTP セッションテストの両方に適している
  • リクエストのチェーン、値のキャプチャ、ステータスコード・ヘッダー・本文などの多様な検証が可能で、Junit、TAP、HTML、JSON レポートなど CI/CD 連携と自動化に有利
  • Rust で実装された単一実行ファイルとして配布され、導入が簡単で、内部的にはlibcurl エンジンを使用して高速性と強力なプロトコル互換性を提供
  • 競合ツールと比べて簡潔な構文と拡張性、豊富な機能を備えたモダンな HTTP テスト自動化ツールと評価されている
  • コミュニティ主導のオープンソースとして、直感的で拡張可能なテキストベース形式のおかげで、開発者と DevOps の双方に高い実用性を示している

What's Hurl?

  • Hurl は明快で直感的なテキスト形式で HTTP リクエストを記述し、コマンドラインで実行できるツール
  • 複数のリクエストをチェーンのように接続し、レスポンスから値を抽出したり、さまざまなクエリ（ヘッダー・本文・ステータスコードなど）を使って複雑な HTTP シナリオテストが可能
  • libcurl エンジンベースで信頼性が高く、IPv6、HTTP/3 など最新プロトコルをサポート
  • データ取得、シナリオテスト、性能計測（応答時間など）をすべてサポート
  • レポート（Junit、TAP、HTML など）の生成と CI/CD パイプライン連携に最適化
  • REST、SOAP、GraphQL、HTML、XML、JSON など多様な APIに対応し、**本文解析（例: XPath、JSONPath）**もサポート
  • 以下は他の HTTP テストツール（例: Postman、curl など）と比べたHurl 独自の重要な強み:
    • プレーンテキストで記述できるため、バージョン管理とコラボレーションに適している
    • Rust 製の単一軽量バイナリを提供し、追加ランタイムが不要
    • curl と同じネットワークエンジン（libcurl）ベースで、信頼性と幅広いプロトコル対応を実現
    • REST、SOAP、GraphQL、HTML など多様な形式をサポートし、複雑なシナリオ設定が可能
    • CI/CD、テスト自動化、詳細レポート（JUnit、HTML、TAP など）との容易な統合

主な機能の概要

  • 基本動作

    • Hurl ファイル（.hurl）内に複数の HTTP リクエストを順番に記述して実行
    • 各リクエストのレスポンスから値を抽出し、条件を検証し、次のリクエストへデータを渡せる
    • REST/JSON、SOAP/XML、GraphQL、HTML など多様な形式に対応

  • チェーンと変数活用

    • 複数リクエストを 1 つのファイル内でチェーンとして記述
    • Captures 構文でレスポンスから値を抽出し、以後のリクエストに変数として注入
    • XPath、JSONPath、正規表現、本文構造などを通じたデータ抽出と活用

  • 多様なリクエストおよび検証方式

    • クエリパラメータ、ヘッダー、認証など多様なリクエスト仕様の設定をサポート
    • [Asserts] 構文または暗黙構文でステータスコード、本文、ヘッダー、Cookie、応答時間、ハッシュなどを検証
    • XPath、JSONPath を利用し、REST/GraphQL/SOAP と HTML コンテンツもテスト可能
    • 複数値の検証、レスポンス本文／ハッシュ／証明書属性、リクエスト／レスポンス遅延、バイナリデータ処理をサポート

  • テストレポートと自動化連携

    • 実行結果をテキスト、HTML、JUnit、TAP、JSON など多様な形式のレポートとして出力
    • CI/CD パイプラインに容易に統合可能

  • 高度な制御と便利機能

    • リクエスト間のデータ受け渡し（キャプチャ・変数化）
    • 動的データ生成関数（newUuid、newDate など）
    • リクエストごとのオプションカスタマイズ
    • ポーリング／リトライ、リクエスト遅延、スキップ、秘密値のマスキング（redact）
    • curl と同じオプションをサポート（curl オプションをそのまま使用可能）
    • AWS Sigv4 認証などクラウド向け機能を内蔵

使用例

  • シンプルな GET/POST リクエストと多段階リクエストチェーンを簡単なテキストファイルで定義
    • sample.hurl ファイルを作成し、$ hurl sample.hurl コマンドを実行することで、該当リクエストを一括実行
  • 例: 
      GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath "string(//meta[@name='_csrf_token']/@content)"  

  POST https://example.org/login?user=toto&password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302
  • 複数 API エンドポイントのテストとレスポンス値の比較、チェーンされた値の利用（トークンなど）、ステータスコード・ヘッダー・本文データなどの検証が可能

代表的な活用例

  • REST/GraphQL/HTML/JSON/SOAP など多様な API テスト
  • CSRF トークン、認証・認可などの値抽出と再利用
  • ステータスコード、ヘッダー、本文データ、Cookie、SSL 証明書などの精密検証
  • 実サービスのシナリオ（ログイン〜業務処理など）の自動化とモニタリング
  • マルチプラットフォームと多様なインストール方法をサポート（Linux、macOS、Windows、Docker、npm、Cargo など）

CLI 主なオプション

  • --test: テストモード（要約とレポート出力）
  • --report-html, --report-json, --report-junit, --report-tap: 多様なレポート形式をサポート
  • --parallel, --jobs N: 並列実行
  • --retry, --retry-interval: 自動リトライ／待機
  • -u, --user: 認証情報を入力
  • --variable, --variables-file: 変数指定
  • -o, --output: レスポンスファイル保存
  • --json: 実行結果を JSON 形式で出力

インストール方法

  • Homebrew、apt、yum、pacman、cargo、choco、scoop、Docker、npm など多様な方法でインストール可能
  • 単一バイナリのため追加ランタイム不要
  • 例: 
    brew install hurl
    または 
    cargo install --locked hurl

競合ツールに対する利点

  • Postman、Insomnia などの GUI ツールより、テキストベース・バージョン管理・CI/CD 統合に有利
  • curl よりテストやシナリオ実行、検証、レポート自動化に特化
  • YAML、JSON などの複雑な DSL の代わりに直感的な独自フォーマットで学習コストが低い

関連記事

3件のコメント

 
seunggi 2025-07-04

Bruno - 高速でGitフレンドリーなオープンソースAPIクライアント（Postmanの代替）
https://ja.news.hada.io/topic?id=13730
 
xguru 2025-06-21

Hurl 4.0.0 リリース
2年前には4.0でしたが、現在は6.1.1まで出ていますね。
 
GN⁺ 2025-06-21
Hacker Newsの意見

  • ここ数か月で hurl を使い始めた
    テストスイートモードと個別呼び出しモードの両方を使える点にとても満足している
    CI で HTTP リクエストのテストスイートを実行するために使っている
    設定言語のブロックは直感的ではなく、サポートされている assertion 関連のドキュメントもやや不足していると感じる
    全体として、このツール自体は大きな価値を提供している
    POC 作業の際にインターフェーステストを始め、このやり方が LLM ベースの開発を助けることに気づいた
    テストを HTTP メソッドに直接書くことで、プロジェクトの進化の過程でテストと実装をより柔軟に分離できる
    テストを分離したおかげで、インターフェースと実装の境界がより明確になった
    hurl を導入する前はサービス言語のテストフレームワークでテストコードを書いていたが、hurl ベースのテストによって「クライアント視点」を厳格に保てるようになった
    バックドア的なデータアクセスのようなものなしに、インターフェース、テスト、実装が徹底して分離されているので安心できる

    • hurl の開発者です
      フィードバックありがとうございます
      6〜7年前に最初の開発を始めたときは JSON、その次に YAML フォーマットにも挑戦したが、次第に新しいファイルフォーマットを自分で作るべきだと確信するようになった
      これがユーザー視点ではぎこちなく感じられることは十分理解している
      もっと単純なケースに単純な文法を適用しようと努力したが、完璧ではないかもしれない
      ドキュメントについて不足や改善点があれば、ぜひ意見をもらって改善していきたい

  • Hurl は本当に素晴らしいツールだ
    以前、Python で書かれた Web サービスを Rust に移植したとき、厳格な public API テストが大いに役立った
    言語に依存しない統合テスト環境のおかげで、API や Web サイトはそのままに、バックエンドだけを置き換えればよかった
    Rust で Hurl を使うときだけの特別な利点がもう 1 つある
    cargo test と連携して hurl ライブラリを直接使え、.hurl ファイルもそのまま再利用できる
    デモ: https://github.com/perrygeo/axum-hurl-test

  • 2023年9月から Hurl を使い始めた
    以前は Runscope でテストスイートを回していたが、変更内容がバージョン管理されないのがとても不便だった
    下準備を進めて Hurl に切り替え、Runscope は捨てた
    今では誰がいつなぜ何を変えたのかを一目で確認できるようになり、満足している

    • Runscope で変更がバージョン管理されない点は本当に嫌だった
      うちのチームもその問題を解決しようとしているうちに、プロジェクトの勢いが失われた

  • コンセプト自体は良いと思うが、「なぜ使うべきなのか」と考えてしまう
    自分は Django で開発しているが、フレームワーク内蔵のテスト機能がすでに非常に充実している
    自分のバックエンドを知らず外側からしか触れないツールを導入すると、かえって同期の負担が増えるように思える
    おかしいと感じても、すぐにデバッガへ飛び込むこともできない
    テストコードとバックエンドコードを明確に分離すべきだという理屈はあるが、実際には管理コストが大きくなる
    結局はネイティブのテストスイートも回すことになるので、外部ツールを複数並行して使うのは不自然に感じる
    ただし、API がどれだけ汎用的に動くかを検証する用途なら使えるかもしれない

    • なぜ自分のバックエンドを知らないツールを使って同期の手間を増やすのか、という問いには自分もかなり悩んだ
      hurl は使ったことがないが、言語に依存せず API をテストするツールはいくつも使ってきたし、自分でも開発中だ
      こうしたツールが良さそうに見える理由は次の通り

      • 内部実装を知らなくてよいこと自体が、むしろ利点になる
        入力と出力だけを検証する構造なので、内部ロジックに依存しない
      • 言語非依存なので、他チームと共有するときに（あるいは OpenAPI 仕様の代わりとして）ドキュメントのように使える
      • API 契約そのものをテストするため、大規模な移行時にも再利用できる
        たとえば public API を Perl から Go に移す際、既存の Perl API をリグレッション防止テストとして使い、同じテストを Go API でもそのまま使えるので信頼性が高まる
      • 開発者がこうしたテストを書くと、一時的に API の利用者の立場へ視点を切り替えられるため、より質の高いテストを書けるようになった

    • Postman のような製品の代替として見るとよい
      ちょっとした HTTP リクエストのテストをするためだけに、Electron ベースの重いウィンドウを立ち上げる必要はない
      curl スクリプトと Postman の中間あたりに位置し、軽さと利便性の両方が必要な人には最適だ

    • 我々は ktor Web サーバーから spring boot ベースのコード（Java/Kotlin スタック）へ移行する際に Hurl を活用した
      サーバースタックに関係なく、仕様レベルのテストスイートを運用できるので、移行は非常にスムーズだった
      また、本番では Docker イメージを使っているが、実装に依存しすぎるツールではなく Hurl を使うことで、統合テストを非常に軽量かつ独立して行えた

  • サンプルセクション(https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples)は、このツールの利点を 5 分で把握したい人、つまり先に判断したがるタイプの人にとって非常に説得力があると感じる
    自分も時々そういうタイプだが、本当に印象的だ

  • Hurl のメンテナーです
    質問やフィードバックはいつでも歓迎します

    • 自分を含め周囲の開発者がよく使うパターンだが、VS Code や IDEA の IDE 拡張で実行できる ".http" ファイルでテストを書く
      フォーマット例は

      POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }

      その後、output を "expected.json" ファイルと 1 対 1 で比較して統合テストを行う
      これらのファイルは cURL と bespoke な bash スクリプトで実行し、jq で結果を比較して成功/失敗をコンソールにログ出力している
      Hurl でもこのように IDE 上でサンプル HTTP リクエストと JSON ファイルベースの期待結果を定義できるのか気になる
      そして Hurl でフォルダー内の複数ファイルを自動実行できるのかも気になる

    • Hurl は HTTP レベルのテストスイートを見栄えよく、保守しやすく書ける点で過小評価されている
      こんなツールを開発してくれてありがとう

    • Hurl という名前の付け方が素晴らしすぎる
      開発者のセンスに感心する

    • Hurl をしばらく使って、その後自分でも貢献したことがある
      "include" 機能が提供される可能性はあるのだろうか

    • 継続的にメンテナンスしてくれてありがとう
      2 年後の Hurl のビジョンや将来をどう見ているのか気になる

  • このプロジェクトから多くのインスピレーションを得て、自分でも HTTP テストツールを設計した
    我々は数百件のテストを高速に並列実行する必要があったので、Hurl が気に入るなら Nap というツールにも興味を持つかもしれない

    • 設定（config）の文法や内容が Hurl と同じなのか、どこが違うのか気になる
      違いを整理して見せるページがあれば教えてほしい

  • 面白そうだ
    自分はもともと Vscode-restclient を長く使っていたが、スクリプトや CLI 用途では最近 httpyac に移りつつある
    Hurl も自分の要件に合うか調べるつもりだ
    テストツールを使っていて不便な点の 1 つは、.http ファイルで 1 つのリクエストの結果を次のリクエストの入力として参照する標準がまだないことだ
    これまで使った 3 つのツールはいずれもやり方が違う

    • hurl は [Captures]

    • Vscode-restclient は変数宣言でリクエスト名を参照する

    • httpyac は @ref 構文
      それぞれ構文が異なるため、あるツール向けに書くと別の場所では壊れてしまう
      関連参考リンク
      hurl capture ドキュメント
      Vscode-restclient
      httpyac ref ドキュメント

    • また別のファイルフォーマットを作ってしまってごめん！
      この問題を少しでも減らす方法として hurlfmt を活用できる
      hurlfmt は Hurl ファイルを JSON としてエクスポートできる
      この JSON の結果を使って他ツールとの相互変換を作ることもできる
      魔法のように完璧な解決策ではないが、Hurl から別フォーマットへ移行するときに少しは役立つかもしれない

    • Visual Studio Code と Visual Studio はどちらも .HTTP ファイルをサポートしているが、互換性はない
      Conway's Law が実例として再現されたようで興味深い

  • 少し似ているように見える
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    この VS Code 拡張は HTTP 関連のテストに非常に強力だ

    • エディターに依存せず使えるという点が本当に大きな違いだ

    • IntelliJ にも似た機能がある
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • 自分も Hurl を使ったことがあり、かなり良いと感じた
      ただ最近は .http 方式のほうを好むようになった
      IntelliJ には内蔵されているし、上でリンクされたプラグインもあり、CLI では httpYac も使ってみた
      ベンダーロックインもなく、ソース管理やコピペで共有するのもとても簡単だ

  • JVM では Karate で統合テストをしている
    https://github.com/karatelabs/karate
    JavaScript を任意に埋め込めるので、リクエストや検証を柔軟に書ける