Hurl - Alat berbasis teks untuk permintaan dan pengujian HTTP dari command line

 (github.com/Orange-OpenSource)
27 poin oleh GN⁺ 2025-06-21 | 3 komentar | Bagikan ke WhatsApp
  • Alat command line open-source untuk menjalankan permintaan HTTP dengan format file teks sederhana, serta mendukung chaining beberapa permintaan, ekstraksi nilai, dan query/validasi pada body maupun header respons
  • Mendukung beragam API dan permintaan berbasis HTML/XML/JSON seperti REST, SOAP, dan GraphQL, sehingga cocok untuk pengambilan data maupun pengujian sesi HTTP
  • Mendukung chaining permintaan, penangkapan nilai, serta berbagai validasi seperti status code, header, dan body, serta memudahkan integrasi CI/CD dan otomasi melalui laporan seperti Junit, TAP, HTML, dan JSON
  • Didistribusikan sebagai file eksekusi tunggal yang diimplementasikan dengan Rust, sehingga mudah dipasang, dan secara internal menggunakan engine libcurl untuk memberikan kecepatan tinggi dan kompatibilitas protokol yang kuat
  • Dinilai sebagai alat otomasi pengujian HTTP modern dengan sintaks ringkas, dapat diperluas, dan memiliki beragam fitur dibanding alat pesaing
  • Sebagai open-source yang digerakkan komunitas, format berbasis teks yang intuitif dan dapat diperluas membuatnya sangat berguna baik bagi developer maupun tim DevOps

What's Hurl?

  • Hurl adalah alat untuk menulis permintaan HTTP dalam format teks yang jelas dan intuitif lalu mengeksekusinya dari command line
  • Dapat merangkai beberapa permintaan seperti rantai, mengekstrak nilai dari respons, dan menggunakan berbagai query (header, body, status code, dll.) untuk menguji skenario HTTP yang kompleks
  • Berbasis engine libcurl sehingga andal dan mendukung protokol modern seperti IPv6 dan HTTP/3
  • Mendukung pengambilan data, pengujian skenario, dan pengukuran performa (seperti waktu respons)
  • Sangat cocok untuk pembuatan laporan (Junit, TAP, HTML, dll.) dan integrasi pipeline CI/CD
  • Mendukung beragam API seperti REST, SOAP, GraphQL, HTML, XML, dan JSON, serta juga mendukung parsing body (misalnya XPath, JSONPath)
  • Berikut beberapa keunggulan penting Hurl dibanding alat pengujian HTTP lain (misalnya Postman, curl, dll.):
    • Dapat ditulis dalam plain text sehingga memudahkan version control dan kolaborasi
    • Menyediakan binary tunggal ringan yang ditulis dengan Rust, tanpa memerlukan runtime terpisah
    • Berbasis engine jaringan yang sama dengan curl (libcurl), sehingga andal dan mendukung berbagai protokol
    • Mendukung beragam format seperti REST, SOAP, GraphQL, dan HTML serta memungkinkan penyusunan skenario kompleks
    • Mudah diintegrasikan dengan CI/CD, otomasi pengujian, dan laporan detail (JUnit, HTML, TAP, dll.)

Ringkasan fitur utama

  • Cara kerja dasar

    • Menulis beberapa permintaan HTTP secara berurutan dalam file Hurl (.hurl) lalu mengeksekusinya
    • Dapat mengekstrak nilai dari respons tiap permintaan, memvalidasi kondisi, dan meneruskan data ke permintaan berikutnya
    • Mendukung berbagai format seperti REST/JSON, SOAP/XML, GraphQL, dan HTML

  • Chaining dan penggunaan variabel

    • Menulis beberapa permintaan sebagai rantai dalam satu file
    • Menggunakan sintaks Captures untuk mengekstrak nilai dari respons lalu menyuntikkannya sebagai variabel ke permintaan berikutnya
    • Mendukung ekstraksi dan pemanfaatan data melalui XPath, JSONPath, regular expression, struktur body, dan lainnya

  • Beragam metode permintaan dan validasi

    • Mendukung pengaturan berbagai spesifikasi permintaan seperti query parameter, header, dan autentikasi
    • Menggunakan sintaks [Asserts] atau sintaks implisit untuk memvalidasi status code, body, header, cookie, waktu respons, hash, dan lainnya
    • Mendukung XPath dan JSONPath, serta dapat menguji konten REST/GraphQL/SOAP maupun HTML
    • Mendukung validasi multi-nilai, properti body/hash/sertifikat, delay permintaan/respons, dan penanganan data biner

  • Laporan pengujian dan integrasi otomasi

    • Hasil eksekusi dapat dikeluarkan sebagai laporan dalam berbagai format seperti teks, HTML, JUnit, TAP, dan JSON
    • Dapat dengan mudah diintegrasikan ke pipeline CI/CD

  • Kontrol lanjutan dan fitur berguna

    • Transfer data antarpermintaan (capture dan variabelisasi)
    • Fungsi pembuatan data dinamis (newUuid, newDate, dll.)
    • Kustomisasi opsi per permintaan
    • Polling/retry, delay permintaan, skip, masking nilai rahasia (redact)
    • Mendukung opsi yang sama seperti curl (opsi curl dapat digunakan apa adanya)
    • Fitur bawaan khusus cloud seperti autentikasi AWS Sigv4

Contoh penggunaan

  • Mendefinisikan permintaan GET/POST sederhana dan chaining permintaan multi-tahap dalam file teks sederhana
    • Buat file sample.hurl, lalu jalankan semua permintaan tersebut sekaligus dengan perintah $ hurl sample.hurl
  • Contoh: 
      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
  • Dapat digunakan untuk menguji beberapa endpoint API dan membandingkan nilai respons, memakai nilai hasil chaining (seperti token), serta memvalidasi status code, header, dan data body

Contoh penggunaan utama

  • Pengujian berbagai API seperti REST/GraphQL/HTML/JSON/SOAP
  • Ekstraksi dan penggunaan ulang nilai seperti token CSRF, autentikasi, dan otorisasi
  • Validasi presisi untuk status code, header, data body, cookie, sertifikat SSL, dan lainnya
  • Otomasi dan monitoring skenario layanan nyata (login hingga alur kerja bisnis, dll.)
  • Mendukung multi-platform dan berbagai metode instalasi (Linux, macOS, Windows, Docker, npm, Cargo, dll.)

Opsi CLI utama

  • --test: mode pengujian (menampilkan ringkasan dan laporan)
  • --report-html, --report-json, --report-junit, --report-tap: mendukung berbagai format laporan
  • --parallel, --jobs N: eksekusi paralel
  • --retry, --retry-interval: retry/tunggu otomatis
  • -u, --user: memasukkan informasi autentikasi
  • --variable, --variables-file: menetapkan variabel
  • -o, --output: menyimpan file respons
  • --json: menampilkan hasil eksekusi dalam format JSON

Cara instalasi

  • Dapat dipasang dengan berbagai cara seperti Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, dan npm
  • Karena berupa binary tunggal, tidak memerlukan runtime terpisah
  • Contoh: 
    brew install hurl
    atau 
    cargo install --locked hurl

Keunggulan dibanding alat pesaing

  • Lebih unggul untuk basis teks, version control, dan integrasi CI/CD dibanding alat GUI seperti Postman dan Insomnia
  • Lebih terfokus pada pengujian, eksekusi skenario, validasi, dan otomasi laporan dibanding curl
  • Memiliki learning curve yang rendah berkat format milik sendiri yang intuitif dibanding DSL kompleks seperti YAML atau JSON

Bacaan terkait

3 komentar

 
seunggi 2025-07-04

Bruno - klien API open source yang cepat dan ramah Git (alternatif Postman)
https://id.news.hada.io/topic?id=13730
 
xguru 2025-06-21

Rilis Hurl 4.0.0
Dua tahun lalu masih 4.0, tetapi sekarang sudah sampai 6.1.1.
 
GN⁺ 2025-06-21
Komentar Hacker News

  • Saya mulai memakai Hurl dalam beberapa bulan terakhir
    Saya sangat suka karena bisa dipakai baik dalam mode test suite maupun mode pemanggilan individual
    Saya memakainya untuk menjalankan test suite request HTTP di CI
    Menurut saya bahasa konfigurasinya tidak terlalu intuitif dalam bentuk blok, dan dokumentasi soal assertion yang didukung juga agak kurang
    Secara keseluruhan, alat ini memberi nilai yang besar
    Saya mulai menguji antarmuka saat mengerjakan POC, dan sadar bahwa pendekatan ini bisa membantu pengembangan berbasis LLM
    Dengan menulis test langsung pada method HTTP, test dan implementasi jadi lebih fleksibel terpisah saat proyek berkembang
    Pemisahan test ini membuat batas antara antarmuka dan implementasi jadi lebih jelas
    Sebelum mengadopsi Hurl, saya menulis kode test dengan framework test dari bahasa layanan yang dipakai, tetapi dengan test berbasis Hurl saya jadi benar-benar menjaga 'sudut pandang klien'
    Tanpa akses data backdoor dan semacamnya, antarmuka, test, dan implementasi benar-benar terpisah sehingga terasa lebih aman

    • Saya pengembang Hurl
      Terima kasih atas masukannya
      Saat mulai mengembangkannya pertama kali 6~7 tahun lalu, saya sempat mencoba format JSON lalu YAML, tetapi perlahan saya yakin untuk membuat format file baru sendiri
      Saya sangat paham bahwa ini bisa terasa canggung dari sudut pandang pengguna
      Saya berusaha menerapkan sintaks yang sederhana untuk kasus yang lebih sederhana, tetapi mungkin belum sempurna
      Untuk dokumentasi, kalau ada kekurangan atau hal yang bisa ditingkatkan, saya berharap bisa menerima masukan secara aktif dan memperbaikinya

  • Hurl benar-benar alat yang keren
    Dulu saat mem-porting layanan web yang ditulis dengan Python ke Rust, pengujian public API yang ketat sangat membantu
    Berkat lingkungan integration test yang independen dari bahasa, API atau situs web bisa dibiarkan tetap sama dan hanya backend yang diganti
    Ada satu keuntungan khusus lagi saat memakai Hurl di Rust
    Hurl bisa langsung dipakai bersama cargo test, dan file .hurl bisa digunakan ulang apa adanya
    Demo: https://github.com/perrygeo/axum-hurl-test

  • Saya mulai memakai Hurl sejak September 2023
    Sebelumnya saya menjalankan test suite lewat Runscope, tetapi sangat tidak nyaman karena perubahan tidak dikelola dalam version control
    Setelah menyiapkan dasar-dasarnya, saya beralih ke Hurl dan meninggalkan Runscope
    Sekarang saya puas karena bisa langsung melihat siapa mengubah apa, kapan, dan kenapa

    • Saya juga sangat benci bahwa perubahan di Runscope tidak dikelola dalam version control
      Tim kami juga kehilangan momentum proyek saat mencoba menyelesaikan masalah itu

  • Konsepnya sendiri menurut saya bagus, tetapi saya jadi berpikir 'kenapa harus dipakai'
    Saya mengembangkan dengan Django, dan fitur test bawaan framework itu sendiri sudah sangat lengkap
    Menambahkan alat yang tidak mengenal backend saya dan hanya mengakses dari luar rasanya justru menambah beban sinkronisasi
    Kalau ada yang aneh, saya juga tidak bisa langsung lompat ke debugger
    Memang ada logika bahwa kode test dan kode backend harus dipisahkan dengan jelas, tetapi secara praktis biaya pemeliharaannya terasa lebih besar
    Pada akhirnya saya tetap harus menjalankan native test suite juga, jadi memakai beberapa alat eksternal sekaligus terasa canggung
    Tapi, kalau dipakai untuk memverifikasi seberapa generik sebuah API bekerja, mungkin ada gunanya

    • Saya juga banyak memikirkan pertanyaan kenapa harus memakai alat yang tidak mengenal backend saya dan hanya menambah repot sinkronisasi
      Saya belum pernah memakai Hurl, tetapi saya sudah beberapa kali memakai alat untuk menguji API secara agnostik terhadap bahasa, dan bahkan sedang mengembangkannya sendiri
      Alasan alat seperti ini terlihat menarik adalah

      • Justru ini kelebihannya, karena tidak perlu tahu implementasi internal
        Karena strukturnya hanya memverifikasi input-output, alat ini tidak bergantung pada logika internal
      • Karena independen dari bahasa, ini bisa dibagikan ke tim lain dan dipakai seperti dokumentasi (atau sebagai pengganti spesifikasi OpenAPI)
      • Karena yang diuji adalah kontrak API itu sendiri, alat ini juga bisa dipakai ulang saat migrasi besar
        Misalnya, saat memindahkan public API dari Perl ke Go, API Perl lama bisa dijadikan test non-regresi, lalu test yang sama dipakai apa adanya untuk API Go sehingga tingkat kepercayaannya tinggi
      • Saat pengembang menulis test seperti ini, mereka bisa sesaat berpindah ke sudut pandang konsumen API secara langsung, sehingga bisa menulis test dengan kualitas lebih tinggi

    • Ini bisa dilihat sebagai pengganti produk seperti Postman
      Tidak perlu membuka jendela berat berbasis Electron hanya untuk mengetes beberapa request http sederhana
      Letaknya di antara skrip curl dan Postman, jadi sangat pas bagi orang yang butuh ringan sekaligus nyaman dipakai

    • Kami memakai Hurl saat bermigrasi dari server web ktor ke kode berbasis spring boot (stack Java/Kotlin)
      Karena bisa menjalankan test suite di level spesifikasi tanpa bergantung pada stack server, transisinya jadi sangat mulus
      Selain itu, karena kami memakai image Docker di produksi, kami bisa menjalankan integration test dengan sangat ringan dan independen menggunakan Hurl, bukan alat yang terlalu bergantung pada implementasi

  • Bagian sample (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) terasa sangat meyakinkan bagi orang yang ingin memahami kelebihan alat ini hanya dalam 5 menit, yaitu tipe orang yang cenderung menilai lebih dulu
    Saya sendiri kadang juga seperti itu, dan menurut saya ini sangat mengesankan

  • Saya maintainer Hurl
    Pertanyaan atau masukan selalu disambut

    • Ini pola yang cukup sering dipakai oleh saya dan para pengembang di sekitar saya: kami menulis test dalam file ".http" yang bisa dijalankan lewat ekstensi IDE seperti VS Code atau IDEA
      Format contohnya adalah

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

      Lalu output-nya dibandingkan 1:1 dengan file expected.json untuk menjalankan integration test
      File-file ini dijalankan dengan cURL dan skrip bash khusus, lalu hasilnya dibandingkan dengan jq dan status sukses/gagal dicatat ke konsol
      Saya penasaran apakah dengan Hurl kita juga bisa mendefinisikan contoh request HTTP dan hasil yang diharapkan berbasis file JSON seperti ini langsung dari IDE
      Dan saya juga ingin tahu apakah Hurl bisa menjalankan banyak file dalam satu folder secara otomatis

    • Hurl kurang mendapat apresiasi untuk kemampuan menulis test suite level HTTP yang rapi dan mudah dirawat
      Terima kasih sudah membuat alat seperti ini

    • Saya sangat suka pemilihan nama Hurl
      Selera pengembangnya patut dikagumi

    • Saya pernah memakai Hurl cukup lama lalu ikut berkontribusi juga
      Saya penasaran bagaimana kemungkinan menyediakan fitur include

    • Ucapan terima kasih karena terus merawat proyek ini
      Saya penasaran bagaimana Anda melihat visi dan masa depan Hurl dalam 2 tahun ke depan

  • Saya banyak terinspirasi dari proyek ini lalu merancang alat test HTTP saya sendiri
    Kami perlu menjalankan ratusan test dengan cepat secara paralel, jadi kalau Anda suka Hurl, mungkin alat bernama Nap juga menarik

    • Saya penasaran apakah sintaks atau isi konfigurasi(config)-nya sama dengan Hurl, dan apa saja perbedaannya
      Kalau ada halaman yang merangkum perbedaannya, saya ingin mengetahuinya

  • Terlihat menarik
    Saya awalnya lama memakai Vscode-restclient, tetapi untuk skrip dan CLI belakangan ini saya mulai beralih ke httpyac
    Saya juga berencana melihat apakah Hurl cocok dengan kebutuhan saya
    Salah satu hal yang tidak nyaman saat memakai alat test adalah belum ada standar untuk merujuk hasil dari satu request sebagai input bagi request berikutnya di file .http
    Tiga alat yang pernah saya pakai sejauh ini semuanya punya caranya sendiri

    • Hurl memakai [Captures]

    • Vscode-restclient merujuk nama request dalam deklarasi variabel

    • httpyac memakai sintaks @ref
      Karena sintaksnya berbeda-beda, kalau ditulis untuk satu alat maka akan rusak di alat lain
      Tautan referensi terkait
      dokumentasi capture Hurl
      Vscode-restclient
      dokumentasi ref httpyac

    • Maaf sudah membuat format file lain lagi!
      Salah satu cara untuk sedikit mengurangi masalah ini adalah memakai hurlfmt
      hurlfmt memungkinkan file Hurl diekspor ke JSON
      Dengan hasil JSON ini, mungkin bisa dibuat konversi timbal balik dengan alat lain
      Ini memang bukan solusi ajaib yang sempurna, tetapi mungkin sedikit membantu saat berpindah dari Hurl ke format lain

    • Visual Studio Code dan Visual Studio sama-sama mendukung file .HTTP, tetapi keduanya tidak kompatibel satu sama lain
      Menarik melihat ini sebagai contoh Conway's Law yang terjadi di dunia nyata

  • Kelihatannya agak mirip
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    Ekstensi VS Code ini sangat kuat untuk pengujian terkait HTTP

    • Perbedaan besarnya adalah bisa dipakai secara independen dari editor

    • IntelliJ juga punya fitur serupa
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • Saya juga pernah memakai Hurl dan menurut saya cukup bagus
      Tetapi belakangan ini saya lebih menyukai pendekatan .http
      IntelliJ sudah punya bawaan, ada plugin yang ditautkan di atas, dan di CLI saya juga pernah memakai httpYac
      Tidak ada vendor lock-in, dan sangat mudah dibagikan lewat source control atau copy-paste

  • Di JVM saya menjalankan integration test dengan Karate
    https://github.com/karatelabs/karate
    Karena bisa menyisipkan JavaScript secara bebas, request dan verifikasi bisa ditulis dengan fleksibel