世界を動かす技術を、日本語で。

Hurl: プレーンテキストでHTTPリクエストを実行・テストする

概要

Hurl は、シンプルなテキスト形式でHTTPリクエストを定義・実行できる CLIツール。 APIテストやデータ取得、パフォーマンス検証など多用途に対応。 REST/GraphQL/SOAP/HTML/XML/JSON など幅広いAPI形式をサポート。 チェーンリクエスト、値のキャプチャ、レスポンスの検証が可能。 CI/CD統合・レポート出力 も容易な軽量ツール。

Hurlとは何か

  • コマンドラインツール でHTTPリクエストを実行
  • シンプルなテキストファイル でリクエストを定義
  • リクエストの連携値のキャプチャレスポンス検証 機能
  • HTML、REST、SOAP、GraphQL、XML、JSON など多様なAPIに対応
  • データ取得HTTPセッションテスト 両方に利用可能

基本的な使い方

  • GET/POST/PUT/HEAD など各種HTTPメソッドに対応

  • テキストファイル(例:sample.hurl)でリクエスト内容を記述

  • $ hurl sample.hurl で実行、--testでテスト出力

  • 複数リクエストのチェーン 実行が簡単

  • [Captures] で値を取得し、次のリクエストに利用

    • 例:CSRFトークンの取得と利用

レスポンス検証とアサート

  • HTTPステータス、ヘッダー、ボディ の検証
  • XPath/JSONPath によるボディ検証
  • 正規表現値の件数 のチェック
  • Set-Cookie属性バイト列のSHA256 検証も可能
  • パフォーマンステスト (レスポンス時間の検証)

多様なデータ送信

  • クエリパラメータHTTPヘッダー の設定
  • Basic認証フォームデータ、マルチパートデータ 送信
  • JSON/XML/GraphQL のボディ送信、テンプレート変数の利用
  • ダイナミックデータ (UUIDや日付)の生成

CI/CD・レポート機能

  • JUnit/TAP/HTML/JSON 形式のレポート出力
  • 単一バイナリ でインストール容易、依存ランタイム不要
  • libcurl ベースで高速・高信頼性
  • Docker/npx/各種パッケージマネージャ対応 で導入簡単

Hurlの特徴・メリット

  • テキスト形式 で開発者・運用者双方に直感的
  • 高速CLI でローカル開発・CI統合に最適
  • Rust製の軽量バイナリ、ランタイム不要
  • curlのパワー を活かしつつ、テスト・自動化に特化
  • IPv6/HTTP3 対応

サンプル・ユースケース

  • GET/POST/PUT/HEAD リクエストの記述例
  • ヘッダー/クエリ/認証/データ送信 の各サンプル
  • 値のキャプチャとリクエスト間の受け渡し
  • JSON/XML/GraphQL ボディのテンプレート利用
  • レスポンス検証パフォーマンステスト の記述例
  • ファイル/ディレクトリ単位 でのテスト実行

インストール方法

  • Linux/macOS/Windows 各種パッケージ・バイナリ配布
  • Homebrew/Chocolatey/Scoop/Docker/npm など幅広い対応
  • Cargo/conda-forge/ビルド手順 も用意

まとめ

  • Hurl はHTTPリクエストの自動化・テストに最適なCLIツール
  • シンプルな記法 でAPIテストやデータ取得・検証が可能
  • CI/CD統合レポート出力 も充実
  • curl互換の信頼性・速度Rustの安全性 を両立
  • 公式ドキュメントやGitHub で詳細情報・サンプル入手可能

参考リソース

  • 公式サイトGitHubドキュメント(HTML/PDF/Markdown)
  • サンプル集インストールガイドチュートリアル
  • フィードバックバグ報告 はGitHubで受付

Hackerたちの意見

Hurlに足りないのはスナップショットテストだね。instaでAPIのテストを使ったら、もう戻れないよ。

これって https://insta.rs/ のこと?スナップショットテストの利点は何か見つけた?

スナップショットの価値提案は何?フルボディチェックでそれが満たせない理由は?

Kreyaのためにスナップショットテストを進めてるよ、8月にリリース予定。チェックしてみてね :)

こんにちは、Hurlのメンテナーです!質問があればどんどん聞いてね、フィードバックも大歓迎!

ありがとう!これを維持してくれて!今後2年でHurlはどうなると思う?

Hurlは、いい感じでメンテナブルなHTTPレベルのテストスイートを書くのに過小評価されてるよね。ツールをありがとう!

自分や知り合いの多くは、VS CodeやIDEAのIDE拡張で実行できる「.http」ファイルの形式でテストを書くようになったよ。基本的に、POST http://localhost:8080/api/foo Content-Type: application/json { "some": "body" } みたいな感じ。そして、統合テスト用の「expected.json」出力との1対1のマッピングがある。これらの.httpファイルをcURLで実行するために特注のbashスクリプトを使って、出力をjqで比較して、成功/失敗をコンソールにログ出力して、「actual.json」を書き込んでる。HURLを似たような形で使えるかな?要するに、期待される出力としてJSONファイルを参照するIDEで実行可能なHTTPリクエストの例として?それから、これらのファイルのディレクトリに対してHURLを実行できる?

VSCodeのrest clientの人たちと協力して、httpファイルの標準を作れないかな?

こんな感じかな? https://marketplace.visualstudio.com/items?itemName=humao.re... これはHTTPのテストにめちゃくちゃ便利なVS Codeの拡張機能だよ。

IntelliJにもあるよ https://www.jetbrains.com/help/idea/http-client-in-product-c...

そうそう、エディタに依存しないのが大きいと思う!

うん、Hurlを使ったことがあるけど、最近はもっと.httpの方に傾いてる。IntelliJには組み込まれてるし、リンクしてくれたプラグインもあるし、CLIではhttpYacを使ってる。ほんとに「ベンダーロックイン」がないから、コピー&ペーストやソース管理で簡単に共有できるよ。

Hurl大好き!2023年9月から使い始めたんだ。Runscopeを使ったテストスイートがあったけど、変更がバージョン管理されてないのが嫌だった。ちょっと手間がかかったけど、Hurlに移行したよ(AIはどこにいたの?)そしてRunscopeをやめた。今は誰がいつ何を変更したかが分かるから、すごくいい感じ。

自動テストにはHurlを使ってるけど、個人的な開発ロードマップは別のツールを作ることなんだ。クライアントの状態管理に関するHurlの欠点は簡単には解決できない。完全なクライアント状態の管理と、より良い変数管理が欲しい。前のプロジェクトではPythonでテストを書いたけど、最初はうまくいってたみたい。今後のメンテナンスがどうなるかは分からないな。

JVMプロジェクトでは、統合テストにKarateを使ってるよ:https://github.com/karatelabs/karate リクエストとアサーションの構築を完全にコントロールできるから、テストシナリオには任意のJavaScriptを含めることができる。

こういうツール(簡単でシンプルでCLI)が大好き!https://httpie.io/cli や https://jqlang.org/ のことを思い出すな。

これ面白そうだね。Vscode-restclientを長いこと使ってたけど、最近はスクリプトやCLI用途でhttpyacに移行中なんだ。hurlが合うかどうか見てみるよ。これらのツールをテストしてて気になったのは、.httpファイルで一つのリクエストの結果を別のリクエストの入力として使うための標準がまだできてないこと。例えば、この3つのツールはそれぞれ違う方法を使ってるんだ。* hurlは[Captures]を使う。* Vscode-restclientはリクエスト名を変数宣言で参照する方法(例えば、@token = {{loginAPI.response.body.token}}みたいに)。* 一方、httpyacは@ref構文を使う。ちょっとテストした感じだと、一つの構文を使うと他のツールが壊れちゃうかもしれないね。

また新しいHTTPクライアント用のフォーマットを作っちゃったのは罪だね!この問題を「軽減」するために、hurlfmt(hurlと一緒に配布されてるやつ)を使うと、HurlファイルをJSONにエクスポートできるよ。そのJSONから別のものに変換することもできるし…魔法ではないけど、Hurlから別のものに移行する時には役立つかも。

本当に特別なのは、Visual Studio CodeとVisual Studioの両方に.HTTPファイルがあること…でも互換性がないんだよね。コンウェイの法則が実践されてるね、みんな。

これ面白いね。どれくらいプログラム可能なのか気になるな。このプロジェクト(または似たようなもの)は、フィールドが「now()」に設定されたJSONペイロードをPOSTできるのかな?