Hurl: Run and test HTTP requests with plain text

Original Article ↗ Hacker News Discussion ↗

Snapshot testing and desired features

  • Several commenters want built-in snapshot testing similar to insta: auto-generating expected outputs, reviewing diffs, and accepting/rejecting changes instead of hand-writing assertions.
  • Snapshot masking of non-deterministic fields (timestamps, IDs) is seen as a big benefit.
  • Hurl currently doesn’t have snapshot support; other tools (e.g., Kreya) are adding it.

Positioning vs other HTTP tools

  • Many see Hurl more as a Postman/Runscope replacement than a curl replacement: persistent, shareable test suites in plain text, under version control.
  • Compared against IDE HTTP clients (VS Code REST Client, IntelliJ, Neovim plugins, httpYac, Bruno). Hurl’s advantages: editor-independent, CLI-first, text files committed directly, no GUI export/import.
  • Some users still prefer .http-file ecosystems due to existing IDE integration.

Workflow, syntax, and capabilities

  • Users like the ability to:
    • Capture values from responses ([Captures]) and reuse them in later requests.
    • Reference external files as bodies and as expected outputs.
    • Use environment files and template variables for profiles.
    • Assert on status, body, headers; use it in CI and as API documentation.
  • Status-code assertions living next to the request (HTTP 200) rather than in [Asserts] confuse some, but maintainers say HTTP also serves as response-section marker.
  • Hurl is HTTP-only: no JS engine, no browser interactions; it simulates only the underlying HTTP traffic.

Integrations, packaging, and roadmap

  • Maintainer mentions goals: better IDE integration, gRPC and WebSocket support, and official distro packages (Debian/Fedora).
  • There is already .netrc support; a dedicated config/rc file is planned.
  • Rust users highlight reusing .hurl files via a Rust library and cargo test, and wrapping libhurl for things like Lambda-based monitors.

Critiques, limitations, and open questions

  • Missing features or pain points: snapshot testing, includes/fixtures reuse, SSE/stream testing, regex backreferences, richer client state management, rc file.
  • Some find the DSL non-intuitive compared to a general-purpose language or framework (e.g., Django tests, Karate), and question why not “just use a scripting language.”
  • Others argue language-agnostic, black-box API tests are a feature: better contract testing, easier migrations, and clearer separation between implementation and interface.

Standardization and interoperability

  • Multiple tools (.http formats, capture syntaxes) are incompatible; a few wish for a shared standard.
  • Hurl offers hurlfmt → JSON export as a partial mitigation for migrating between tools.