Hurl - Komut satırında HTTP istekleri ve testleri için metin tabanlı araç

 (github.com/Orange-OpenSource)
27 puan yazan GN⁺ 2025-06-21 | 3 yorum | WhatsApp'ta paylaş
  • HTTP isteklerini basit bir metin dosyası biçimiyle çalıştıran, birden fazla isteği zincirleyebilen, değer çıkarabilen ve yanıt gövdesi ile başlıklarında sorgu/doğrulama yapabilen açık kaynaklı bir komut satırı aracı
  • REST, SOAP, GraphQL gibi çeşitli API'ler ile HTML/XML/JSON tabanlı istekleri destekler; hem veri sorgulama hem de HTTP oturum testi için uygundur
  • İstek zincirleme, değer yakalama, durum kodu·başlık·gövde gibi çeşitli doğrulamalar yapabilir ve Junit, TAP, HTML, JSON raporları gibi CI/CD entegrasyonu ve otomasyon için avantaj sağlar
  • Rust ile geliştirilmiş tek bir çalıştırılabilir dosya olarak dağıtılır; bu da kurulumu kolaylaştırır. Dahili olarak libcurl motorunu kullanır, böylece yüksek hız ve güçlü protokol uyumluluğu sunar
  • Rakip araçlara kıyasla sade sözdizimi ve genişletilebilirliğiyle, çeşitli özelliklere sahip modern bir HTTP test otomasyon aracı olarak değerlendirilir
  • Topluluk odaklı açık kaynak bir proje olarak, sezgisel ve genişletilebilir metin tabanlı formatı sayesinde hem geliştiriciler hem de DevOps ekipleri için yüksek kullanım değeri sunar

What's Hurl?

  • Hurl, HTTP isteklerini açık ve sezgisel bir metin biçiminde yazarak komut satırında çalıştırmayı sağlayan bir araçtır
  • Birden fazla isteği zincir gibi bağlayabilir, yanıtlardan değer çıkarabilir veya çeşitli sorgular (başlık·gövde·durum kodu vb.) kullanarak karmaşık HTTP senaryolarını test edebilir
  • libcurl motoru tabanlıdır; bu sayede güvenilirdir ve IPv6, HTTP/3 gibi modern protokolleri destekler
  • Veri sorgulama, senaryo testi ve performans ölçümü (yanıt süresi vb.) desteği sunar
  • Rapor oluşturma (Junit, TAP, HTML vb.) ve CI/CD pipeline entegrasyonu için optimize edilmiştir
  • REST, SOAP, GraphQL, HTML, XML, JSON gibi çeşitli API'leri destekler ve gövde ayrıştırma (ör. XPath, JSONPath) da sağlar
  • Aşağıdakiler, diğer HTTP test araçlarına (ör. Postman, curl vb.) kıyasla Hurl'ün öne çıkan güçlü yönleridir:
    • Düz metinle yazılabildiği için sürüm kontrolü ve iş birliği açısından elverişlidir
    • Rust ile yazılmış tek ve hafif bir binary sunar; ek runtime gerekmez
    • curl ile aynı ağ motoru olan libcurl tabanlı olduğu için güvenilirlik ve geniş protokol desteği sunar
    • REST, SOAP, GraphQL, HTML gibi farklı formatları destekler ve karmaşık senaryolar kurmaya uygundur
    • CI/CD, test otomasyonu ve ayrıntılı raporlarla (JUnit, HTML, TAP vb.) kolay entegre olur

Temel özellik özeti

  • Temel çalışma şekli

    • Hurl dosyası (.hurl) içinde birden fazla HTTP isteği sıralı olarak yazıp çalıştırır
    • Her isteğin yanıtından değer çıkarabilir, koşul doğrulayabilir ve veriyi sonraki isteğe aktarabilir
    • REST/JSON, SOAP/XML, GraphQL, HTML gibi çeşitli formatları destekler

  • Zincirleme ve değişken kullanımı

    • Birden fazla isteği tek dosya içinde zincir halinde yazabilir
    • Captures sözdizimiyle yanıttan değer çıkarır, ardından bunu sonraki isteklere değişken olarak enjekte eder
    • XPath, JSONPath, düzenli ifadeler ve gövde yapısı üzerinden veri çıkarma ve kullanımını destekler

  • Çeşitli istek ve doğrulama yöntemleri

    • Sorgu parametreleri, başlıklar, kimlik doğrulama gibi çeşitli istek özelliklerini ayarlamayı destekler
    • [Asserts] sözdizimi veya örtük sözdizimi ile durum kodu, gövde, başlık, çerez, yanıt süresi, hash vb. doğrulamalar yapabilir
    • XPath ve JSONPath kullanımıyla REST/GraphQL/SOAP ile birlikte HTML içeriğini de test edebilir
    • Çoklu değer doğrulama, yanıt gövdesi/hash/sertifika özellikleri, istek/yanıt gecikmesi ve ikili veri işleme desteği sunar

  • Test raporları ve otomasyon entegrasyonu

    • Çalıştırma sonuçlarını metin, HTML, JUnit, TAP, JSON gibi çeşitli rapor formatlarında çıktılayabilir
    • CI/CD pipeline'larına kolayca entegre edilebilir

  • Gelişmiş kontrol ve faydalı özellikler

    • İstekler arasında veri aktarımı (capture·değişkenleştirme)
    • Dinamik veri üretme işlevleri (newUuid, newDate vb.)
    • İstek bazında seçenek özelleştirme
    • Polling/yeniden deneme, istek gecikmesi, atlama, gizli değer maskeleme (redact)
    • curl ile aynı seçenekleri destekler (curl seçenekleri doğrudan kullanılabilir)
    • AWS Sigv4 kimlik doğrulaması gibi buluta özel işlevler dahildir

Kullanım örneği

  • Basit GET/POST istekleri ve çok adımlı istek zincirleme işlemlerini basit bir metin dosyasında tanımlayabilirsiniz
    • sample.hurl dosyasını yazıp $ hurl sample.hurl komutunu çalıştırarak ilgili istekleri toplu halde çalıştırabilirsiniz
  • Örnek: 
      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
  • Birden fazla API endpoint'ini test etme ve yanıt değerlerini karşılaştırma, zincirlenmiş değerleri kullanma (token vb.), durum kodu·başlık·gövde verisi gibi alanları doğrulama mümkündür

Öne çıkan kullanım örnekleri

  • REST/GraphQL/HTML/JSON/SOAP gibi çeşitli API'leri test etme
  • CSRF token, kimlik doğrulama ve yetkilendirme gibi değerleri çıkarma ve yeniden kullanma
  • Durum kodu, başlıklar, gövde verisi, çerezler, SSL sertifikası gibi alanlarda ayrıntılı doğrulama
  • Gerçek servis senaryolarını (giriş~iş akışı gibi) otomatikleştirme ve izleme
  • Çoklu platform ve çeşitli kurulum yöntemleri desteği (Linux, macOS, Windows, Docker, npm, Cargo vb.)

CLI temel seçenekleri

  • --test: test modu (özet ve rapor çıktısı)
  • --report-html, --report-json, --report-junit, --report-tap: çeşitli rapor formatlarını destekler
  • --parallel, --jobs N: paralel çalıştırma
  • --retry, --retry-interval: otomatik yeniden deneme/bekleme
  • -u, --user: kimlik doğrulama bilgisi girme
  • --variable, --variables-file: değişken belirtme
  • -o, --output: yanıt dosyasını kaydetme
  • --json: çalıştırma sonucunu JSON biçiminde çıktıla

Kurulum yöntemi

  • Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm vb. birçok yöntemle kurulabilir
  • Tek binary olduğu için ek runtime gerekmez
  • Örnek: 
    brew install hurl
    veya 
    cargo install --locked hurl

Rakip araçlara göre avantajları

  • Postman, Insomnia gibi GUI araçlara kıyasla metin tabanlı yapı, sürüm kontrolü ve CI/CD entegrasyonu açısından daha avantajlıdır
  • curl'e kıyasla testler, senaryo yürütme, doğrulama ve rapor otomasyonuna daha çok odaklanır
  • YAML, JSON gibi karmaşık DSL'ler yerine sezgisel kendi formatını kullandığı için öğrenme eğrisi daha düşüktür

İlgili okumalar

3 yorum

 
seunggi 2025-07-04

Bruno - hızlı ve Git dostu açık kaynaklı API istemcisi (Postman alternatifi)
https://tr.news.hada.io/topic?id=13730
 
xguru 2025-06-21

Hurl 4.0.0 sürümü yayınlandı
2 yıl önce 4.0 sürümüydü, şu anda ise 6.1.1 sürümüne kadar gelmiş.
 
GN⁺ 2025-06-21
Hacker News yorumu

  • Son birkaç aydır hurl kullanmaya başladım
    Hem test paketi modunu hem de tekil çağrı modunu kullanabilmek beni çok memnun ediyor
    CI içinde HTTP istek test paketlerini çalıştırmak için kullanıyorum
    Yapılandırma dili blokları sezgisel gelmiyor ve desteklenen assertion’larla ilgili dokümantasyonun da biraz yetersiz olduğunu düşünüyorum
    Genel olarak araç kendi başına çok büyük bir değer sağlıyor
    POC çalışmaları yaparken arayüz testleri yazmaya başladım ve bunun LLM tabanlı geliştirmeye yardımcı olabildiğini fark ettim
    Testleri doğrudan HTTP metodlarına yazınca, projenin evrimi sırasında testlerle uygulama daha esnek biçimde ayrışıyor
    Testlerin ayrılması sayesinde arayüz ile uygulama arasındaki sınır daha belirgin hale geliyor
    hurl kullanmaya başlamadan önce servis dilinin test framework’üyle test kodu yazıyordum ama hurl tabanlı testler sayesinde 'istemci bakış açısını' çok daha sıkı koruyabiliyorum
    Arka kapı veri erişimi gibi şeyler olmadan, arayüz, test ve uygulama tamamen ayrıldığı için içim rahat ediyor

    • hurl’ün geliştiricisiyim
      Geri bildirim için teşekkürler
      İlk geliştirmeye 6-7 yıl önce başladığımda önce JSON’u, sonra YAML formatını denedim ama zamanla yeni bir dosya formatını doğrudan kendim oluşturmam gerektiğine ikna oldum
      Bunun kullanıcı açısından biraz garip gelebileceğini gayet iyi anlıyorum
      Daha basit durumlarda daha basit bir sözdizimi uygulamaya çalıştım ama kusursuz olmayabilir
      Dokümantasyonda eksik olan ya da iyileştirilebilecek noktalar varsa aktif olarak geri bildirim alıp geliştirmeyi umuyorum

  • Hurl gerçekten harika bir araç
    Bir zamanlar Python ile yazılmış bir web servisini Rust’a taşırken katı public API testleri çok yardımcı olmuştu
    Dilden bağımsız entegrasyon test ortamı sayesinde API’yi ya da web sitesini olduğu gibi bırakıp sadece backend’i değiştirebildik
    Rust içinde Hurl kullanmanın bir özel avantajı daha var
    cargo test ile entegre edip hurl kütüphanesini doğrudan kullanabiliyorsunuz ve .hurl dosyalarını aynen yeniden kullanabiliyorsunuz
    Demo: https://github.com/perrygeo/axum-hurl-test

  • Hurl kullanmaya 2023 Eylül’ünde başladım
    Test paketlerini Runscope üzerinden çalıştırıyordum ama değişikliklerin versiyon kontrolüne girmemesi çok can sıkıcıydı
    Biraz temel çalışma yaptıktan sonra Hurl’e geçtim ve Runscope’u bıraktım
    Artık kimin neyi ne zaman neden değiştirdiğini tek bakışta görebildiğim için memnunum

    • Runscope’ta değişikliklerin versiyon kontrolüne girmemesinden gerçekten nefret ediyordum
      Bizim ekip de o sorunu çözmeye çalışırken projenin ivmesini kaybetti

  • Fikir olarak iyi buluyorum ama “neden kullanayım ki” diye düşündürüyor
    Ben Django’da geliştiriyorum ve framework’ün yerleşik test özellikleri zaten oldukça güçlü
    Kendi backend’imi tanımayan ve ona sadece dışarıdan erişen bir araç eklemek bana sadece senkronizasyon yükü getirirmiş gibi geliyor
    Bir şey tuhafsa doğrudan debugger’a atlama imkanım da ortadan kalkıyor
    Test kodu ile backend kodunu net biçimde ayırmak gerektiğine dair bir mantık var ama pratikte bakım maliyeti daha da artıyor
    Sonuçta native test paketini de çalıştırmak gerekecek, o yüzden birden fazla harici aracı birlikte yürütmek bana garip geliyor
    Ama API’nin ne kadar genel çalıştığını doğrulamak için kullanışlı olabilir diye düşünüyorum

    • Neden backend’imi tanımayan bir araç kullanıp senkronizasyon zahmetini artırayım sorusu üzerine ben de çok düşündüm
      hurl’ü kullanmadım ama dilden bağımsız API test araçlarını defalarca kullandım, hatta birini geliştiriyorum
      Bu tür araçların cazip görünmesinin nedenleri şunlar

      • İç uygulamayı bilmemesi aslında bir avantaj
        Sadece input-output doğrulayan yapı sayesinde iç mantığa bağımlı olmuyor
      • Dilden bağımsız olduğu için başka ekiplerle paylaşırken (veya OpenAPI tanımının yerine) doküman gibi kullanılabiliyor
      • API sözleşmesini test ettiği için büyük ölçekli migration’larda da yeniden kullanılabiliyor
        Örneğin public API’yi Perl’den Go’ya taşırken mevcut Perl API’yi regresyonsuzluk testi olarak kullanıp aynı testleri Go API’sinde de aynen çalıştırarak güven artırılabiliyor
      • Geliştirici bu tür testleri yazarken kısa süreliğine API’nin doğrudan tüketicisi gibi düşünmek zorunda kaldığı için daha kaliteli testler yazabiliyor

    • Bunu Postman gibi ürünlere alternatif olarak düşünebilirsiniz
      Sadece birkaç HTTP istek testi yapmak için Electron tabanlı ağır bir pencere açmanız gerekmiyor
      curl script’leriyle Postman arasında bir yerde duruyor; hem hafiflik hem rahatlık isteyenler için ideal

    • Biz ktor web sunucusundan spring boot tabanlı koda (Java/Kotlin yığını) migration yaparken Hurl kullandık
      Sunucu stack’inden bağımsız olarak spesifikasyon seviyesinde bir test paketi işletebildiğimiz için geçiş çok sorunsuz oldu
      Ayrıca Docker image’ını production’da kullanıyoruz; bu yüzden uygulamaya fazla bağımlı araçlar yerine Hurl kullanarak entegrasyon testlerini çok hafif ve bağımsız tutabildik

  • Örnekler bölümü(https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) bu aracın ne işe yaradığını 5 dakikada anlamak isteyen, yani hızlı hüküm veren tipte insanlar için çok ikna edici geliyor
    Ben de bazen öyle oluyorum ve gerçekten etkileyici buldum

  • Hurl’ün maintainer’ıyım
    Sorulara ya da geri bildirimlere her zaman açığım

    • Benim de dahil olduğum çevrede geliştiricilerin sık kullandığı bir kalıp şu: VS Code veya IDEA’nın IDE eklentileriyle çalıştırılabilen .http dosyalarıyla test yazıyoruz
      Örnek format şöyle

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

      Sonra çıktıyı expected.json dosyasıyla bire bir karşılaştırarak entegrasyon testi yapıyoruz
      Bu dosyaları cURL ve özel bash script’leriyle çalıştırıyor, sonucu da jq ile karşılaştırıp başarı/başarısızlığı konsola yazıyoruz
      Hurl ile de IDE içinde bu şekilde örnek HTTP istekleri ve JSON dosyası tabanlı beklenen sonuçlar tanımlamak mümkün mü merak ediyorum
      Bir de Hurl klasör içindeki birden çok dosyayı otomatik çalıştırabiliyor mu?

    • Hurl, HTTP seviyesinde test paketlerini temiz ve bakımı kolay biçimde yazdırdığı için yeterince değer görmüyor
      Böyle bir araç geliştirdiğiniz için teşekkürler

    • Hurl adını seçmiş olmanıza bayıldım
      Geliştiricinin zekâsına hayran kaldım

    • Bir süre Hurl kullandım ve hatta katkıda da bulundum
      include özelliği ekleme ihtimali nedir, merak ediyorum

    • Sürekli bakımını yaptığınız için teşekkür ederim
      2 yıl sonra Hurl’ün vizyonunu ve geleceğini nasıl görüyorsunuz?

  • Bu projeden çok ilham alıp kendim bir HTTP test aracı tasarladım
    Yüzlerce testi hızlıca paralel çalıştırmamız gerekiyordu; Hurl hoşunuza gittiyse Nap adlı araç da ilginizi çekebilir

    • Yapılandırma sözdizimi ya da içeriği Hurl ile aynı mı, hangi yönleri farklı merak ediyorum
      Farkları özetleyen bir sayfa varsa paylaşmanızı isterim

  • İlginç görünüyor
    Ben uzun süredir Vscode-restclient kullanıyordum ama script ve CLI amaçları için son zamanlarda httpyac’a geçiyorum
    Hurl’ün de istediğim koşullara uyup uymadığına bakmayı planlıyorum
    Test araçlarında can sıkıcı bulduğum şeylerden biri, .http dosyasında bir isteğin sonucunu sonraki isteğin girdisi olarak referanslamanın henüz standart bir yolu olmaması
    Şimdiye kadar kullandığım üç aracın da yöntemi farklı

    • hurl’de [Captures]

    • Vscode-restclient’ta istek adını değişken tanımında referanslama

    • httpyac’ta @ref sözdizimi
      Sözdizimleri farklı olduğu için bir araç için yazılan şey diğerinde bozuluyor
      İlgili bağlantılar
      hurl capture dokümantasyonu
      Vscode-restclient
      httpyac ref dokümantasyonu

    • Bir dosya formatı daha ürettiğimiz için özürler!
      Bu sorunu biraz hafifletmenin bir yolu olarak hurlfmt kullanılabilir
      hurlfmt, Hurl dosyalarını JSON olarak dışa aktarmayı sağlıyor
      Bu JSON çıktısını kullanarak başka araçlarla karşılıklı dönüştürme de yapılabilir
      Mucizevi, eksiksiz bir çözüm değil ama Hurl’den başka formatlara geçerken biraz yardımcı olabilir

    • Visual Studio Code ile Visual Studio’nun ikisi de .HTTP dosyalarını destekliyor ama birbirleriyle uyumlu değiller
      Conway's Law’un pratikte yeniden canlanmış hâli gibi, ilginç bir örnek

  • Biraz benziyor
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    Bu VS Code eklentisi HTTP ile ilgili testler için oldukça güçlü

    • Editörden bağımsız kullanılabilmesi asıl büyük fark

    • IntelliJ’de de benzer bir özellik var
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • Ben de Hurl kullandım ve oldukça iyi buldum
      Ama son zamanlarda .http yaklaşımını daha çok tercih etmeye başladım
      IntelliJ’de yerleşik geliyor, yukarıda bağlantısı verilen eklenti de var, CLI tarafında da httpYac kullandım
      Vendor lock-in yok ve source control üzerinden ya da kopyala-yapıştır ile paylaşmak da çok kolay

  • JVM tarafında entegrasyon testleri için Karate kullanıyorum
    https://github.com/karatelabs/karate
    İstediğiniz gibi JavaScript ekleyebildiğiniz için istekleri/doğrulamaları esnek biçimde yazabiliyorsunuz