Hurl - कमांड लाइन पर HTTP अनुरोध और टेस्टिंग के लिए टेक्स्ट-आधारित टूल

(github.com/Orange-OpenSource)

27 पॉइंट द्वारा GN⁺ 2025-06-21 | 3 टिप्पणियां | WhatsApp पर शेयर करें

सरल टेक्स्ट फ़ाइल फ़ॉर्मेट में HTTP अनुरोध चलाने, कई अनुरोधों को चेन करने, वैल्यू निकालने, और response body व headers पर query/validation करने वाला ओपन सोर्स कमांड लाइन टूल
REST, SOAP, GraphQL सहित विभिन्न API और HTML/XML/JSON-आधारित अनुरोधों को सपोर्ट करता है, और डेटा retrieval व HTTP session testing दोनों के लिए उपयुक्त है
request chaining, value capture, status code·header·body सहित विभिन्न validation संभव हैं, और Junit, TAP, HTML, JSON reports जैसे CI/CD integration व automation के लिए अनुकूल है
Rust में बना single executable file के रूप में वितरित होता है, इसलिए इंस्टॉलेशन आसान है, और अंदरूनी तौर पर libcurl engine का उपयोग करके तेज़ गति और मजबूत protocol compatibility देता है
प्रतिस्पर्धी टूल्स की तुलना में संक्षिप्त syntax, extensibility और विविध सुविधाओं वाला आधुनिक HTTP test automation tool माना जाता है
community-driven open source के रूप में, सहज और विस्तारयोग्य text-based format की वजह से डेवलपर्स और DevOps दोनों के लिए बेहद उपयोगी है

What's Hurl?

Hurl एक ऐसा टूल है जो स्पष्ट और सहज टेक्स्ट फ़ॉर्मेट में HTTP अनुरोध लिखकर उन्हें कमांड लाइन से चलाने देता है
कई अनुरोधों को chain की तरह जोड़कर, response से values निकालकर या विभिन्न queries (header·body·status code आदि) का उपयोग करके जटिल HTTP scenario testing की जा सकती है
libcurl engine आधारित होने के कारण यह विश्वसनीय है और IPv6, HTTP/3 जैसे आधुनिक protocols को सपोर्ट करता है
डेटा retrieval, scenario testing, performance measurement (जैसे response time) सभी को सपोर्ट करता है
report generation (Junit, TAP, HTML आदि) और CI/CD pipeline integration के लिए अनुकूलित है
REST, SOAP, GraphQL, HTML, XML, JSON जैसे विभिन्न API को संभालता है, और body parsing (जैसे XPath, JSONPath) भी सपोर्ट करता है
नीचे अन्य HTTP testing tools (जैसे Postman, curl आदि) की तुलना में Hurl की प्रमुख खूबियाँ दी गई हैं:
- plain text में लिखा जा सकता है, इसलिए version control और collaboration के लिए सुविधाजनक है
- Rust में लिखा गया single lightweight binary, किसी अलग runtime की ज़रूरत नहीं
- curl जैसे ही network engine (libcurl) पर आधारित, इसलिए विश्वसनीयता और अनेक protocols का समर्थन
- REST, SOAP, GraphQL, HTML जैसे अनेक formats का समर्थन और जटिल scenarios सेट करने की क्षमता
- CI/CD, test automation, और विस्तृत reports (JUnit, HTML, TAP आदि) के साथ आसान integration

मुख्य फीचर्स का सारांश

बुनियादी कार्यप्रणाली
- Hurl फ़ाइल (.hurl) के अंदर कई HTTP अनुरोध क्रम से लिखकर चलाए जा सकते हैं
- हर अनुरोध के response से values निकालना, conditions validate करना, और डेटा को अगले अनुरोध तक पहुँचाना संभव है
- REST/JSON, SOAP/XML, GraphQL, HTML आदि कई formats का समर्थन
chaining और variables का उपयोग
- एक ही फ़ाइल में कई अनुरोध chain के रूप में लिखे जा सकते हैं
- Captures syntax से response से values निकालकर बाद के अनुरोधों में variables के रूप में inject किया जा सकता है
- XPath, JSONPath, regular expressions, body structure आदि के माध्यम से डेटा extraction और उपयोग
विभिन्न request और validation तरीके
- query parameters, headers, authentication आदि सहित विभिन्न request specifications सेट करने का समर्थन
- [Asserts] syntax या implicit syntax से status code, body, header, cookie, response time, hash आदि validate किए जा सकते हैं
- XPath, JSONPath का उपयोग, और REST/GraphQL/SOAP के साथ HTML content भी टेस्ट किया जा सकता है
- multi-value validation, response body/hash/certificate properties, request/response delay, binary data handling का समर्थन
test reports और automation integration
- execution results को text, HTML, JUnit, TAP, JSON आदि कई report formats में आउटपुट किया जा सकता है
- CI/CD pipelines में आसानी से integrate किया जा सकता है
advanced control और उपयोगी सुविधाएँ
- अनुरोधों के बीच डेटा ट्रांसफर (capture·variableization)
- dynamic data generation functions (newUuid, newDate आदि)
- प्रति अनुरोध option customization
- polling/retry, request delay, skip, secret value masking (redact)
- curl जैसे ही options का समर्थन (curl options सीधे इस्तेमाल किए जा सकते हैं)
- AWS Sigv4 authentication जैसी cloud-specific सुविधाएँ built-in

उपयोग उदाहरण

सरल GET/POST requests और multi-step request chaining को एक साधारण टेक्स्ट फ़ाइल में परिभाषित किया जा सकता है
- sample.hurl फ़ाइल लिखें, और $ hurl sample.hurl कमांड चलाकर उन अनुरोधों को एक साथ execute करें

उदाहरण:

  GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath &quot;string(//meta[@name='_csrf_token']/@content)&quot;  

  POST https://example.org/login?user=toto&amp;password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302

कई API endpoints की testing और response values की तुलना, chained values (जैसे token) का उपयोग, और status code·header·body data आदि का validation संभव है

प्रमुख उपयोग परिदृश्य

REST/GraphQL/HTML/JSON/SOAP जैसे विभिन्न APIs की testing
CSRF token, authentication·authorization जैसे values निकालना और दोबारा उपयोग करना
status code, headers, body data, cookies, SSL certificates आदि का सटीक validation
वास्तविक service scenarios (login~business actions आदि) का automation और monitoring
multi-platform और अनेक installation methods का समर्थन (Linux, macOS, Windows, Docker, npm, Cargo आदि)

CLI मुख्य options

--test: test mode (summary और report output)
--report-html, --report-json, --report-junit, --report-tap: कई report formats का समर्थन
--parallel, --jobs N: parallel execution
--retry, --retry-interval: automatic retry/wait
-u, --user: authentication info इनपुट
--variable, --variables-file: variables सेट करना
-o, --output: response फ़ाइल सेव करना
--json: execution result को JSON format में आउटपुट करना

इंस्टॉलेशन तरीका

Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm आदि कई तरीकों से इंस्टॉल किया जा सकता है
single binary होने के कारण किसी अलग runtime की ज़रूरत नहीं

उदाहरण:

brew install hurl

या

cargo install --locked hurl

प्रतिस्पर्धी टूल्स पर फायदे

Postman, Insomnia जैसे GUI tools की तुलना में text-based workflow, version control, और CI/CD integration के लिए अधिक उपयुक्त
curl की तुलना में testing, scenario execution, validation, और report automation के लिए अधिक विशेषीकृत
YAML, JSON जैसी जटिल DSL के बजाय सहज अपने फ़ॉर्मेट के कारण learning curve कम

3 टिप्पणियां

seunggi 2025-07-04

Bruno - तेज़ और Git-फ्रेंडली ओपन सोर्स API क्लाइंट (Postman का विकल्प)
https://hi.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 का इस्तेमाल शुरू किया है
यह बात मुझे बहुत पसंद है कि इसमें test suite mode और individual call mode दोनों इस्तेमाल किए जा सकते हैं
मैं CI में HTTP request test suite चलाने के लिए इसका उपयोग करता हूँ
मुझे लगता है कि इसकी configuration language के blocks बहुत intuitive नहीं हैं, और supported assertions से जुड़ा documentation भी थोड़ा कमज़ोर है
कुल मिलाकर, यह टूल अपने आप में बहुत value देता है
POC काम करते समय मैंने interface testing शुरू की, और पता चला कि यह तरीका LLM-आधारित development में मदद कर सकता है
जब tests सीधे HTTP methods पर लिखे जाते हैं, तो project के evolve होने के दौरान tests और implementation को ज़्यादा लचीले ढंग से अलग रखा जा सकता है
tests के अलग होने से interface और implementation के बीच की सीमा भी ज़्यादा स्पष्ट हो जाती है
hurl अपनाने से पहले मैं service language के test framework में test code लिखता था, लेकिन hurl-आधारित tests के साथ मैं सख्ती से 'client perspective' बनाए रख पाता हूँ
backdoor data access जैसी चीज़ों के बिना, interface, tests और implementation पूरी तरह अलग रहते हैं, इसलिए भरोसा बना रहता है
- मैं hurl का developer हूँ
  feedback के लिए धन्यवाद
  6–7 साल पहले जब मैंने शुरुआती development शुरू किया, तब पहले JSON और फिर YAML format आज़माया था, लेकिन धीरे-धीरे यक़ीन हो गया कि नया file format सीधे खुद बनाना चाहिए
  मुझे पूरी तरह समझ है कि user के नज़रिए से यह अटपटा लग सकता है
  मैंने कोशिश की कि आसान cases के लिए आसान syntax हो, लेकिन हो सकता है वह परफेक्ट न हो
  documentation में जहाँ कमी हो या सुधार की गुंजाइश हो, वहाँ मैं सक्रिय रूप से feedback लेना और उसे बेहतर बनाना चाहता हूँ
Hurl वाकई शानदार टूल है
पहले जब मैंने Python में लिखी web service को Rust में port किया था, तब सख्त public API tests बहुत मददगार साबित हुए
language-independent integration test environment की वजह से API या website को जस का तस रखते हुए सिर्फ backend बदला जा सका
Rust में Hurl इस्तेमाल करने का एक और खास फ़ायदा है
इसे cargo test के साथ जोड़कर hurl library सीधे इस्तेमाल की जा सकती है, और .hurl files भी वैसे ही दोबारा उपयोग की जा सकती हैं
डेमो: https://github.com/perrygeo/axum-hurl-test
मैंने Hurl का इस्तेमाल सितंबर 2023 से शुरू किया
पहले Runscope से test suite चलाता था, लेकिन यह बहुत परेशान करने वाला था कि changes version control में नहीं आते थे
कुछ बुनियादी तैयारी के बाद मैंने Hurl पर switch कर लिया और Runscope छोड़ दिया
अब कौन, कब, क्यों और क्या बदला, यह एक नज़र में दिख जाता है, इसलिए मैं काफ़ी संतुष्ट हूँ
- मुझे भी Runscope में changes का version control न होना सच में बहुत बुरा लगता था
  हमारी टीम ने भी उस समस्या को हल करने की कोशिश करते-करते project की रफ़्तार खो दी
concept अच्छा लगता है, लेकिन फिर भी सोचता हूँ कि ‘इसे क्यों इस्तेमाल करूँ’
मैं Django में development करता हूँ, और framework की built-in testing capabilities पहले से ही बहुत मज़बूत हैं
ऐसा tool लाना जो मेरे backend को नहीं जानता और सिर्फ बाहर से access करता है, मुझे लगता है sync का बोझ ही बढ़ाएगा
कुछ गड़बड़ हो तो सीधे debugger में कूद पड़ने की सुविधा भी नहीं रहेगी
test code और backend code को साफ़ अलग रखना चाहिए, यह तर्क अपनी जगह है, लेकिन व्यवहार में maintenance cost ज़्यादा लगती है
आख़िरकार native test suite भी चलानी ही पड़ेगी, इसलिए कई external tools साथ लेकर चलना थोड़ा अटपटा लगता है
हाँ, अगर मकसद यह जाँचना है कि API कितनी general-purpose तरह से काम करती है, तो यह उपयोगी हो सकता है
- यह सवाल कि ऐसा tool क्यों इस्तेमाल करें जो मेरे backend को नहीं जानता और सिर्फ sync का काम बढ़ाता है, मैंने भी बहुत सोचा है
  मैंने hurl इस्तेमाल नहीं किया, लेकिन language-agnostic API testing tools कई बार इस्तेमाल किए हैं और एक खुद बना भी रहा हूँ
  मुझे ये tools अच्छे लगने के कारण हैं
  - इन्हें internal implementation जानने की ज़रूरत नहीं होती, और यही इनकी ताकत है
    input-output validation पर आधारित structure की वजह से ये internal logic पर निर्भर नहीं होते
  - language-independent होने के कारण इन्हें दूसरी teams के साथ share किया जा सकता है, या OpenAPI spec की जगह documentation की तरह भी इस्तेमाल किया जा सकता है
  - क्योंकि ये API contract को ही test करते हैं, इसलिए बड़े migration के दौरान भी इन्हें दोबारा इस्तेमाल किया जा सकता है
    उदाहरण के लिए, अगर public API को Perl से Go में migrate किया जा रहा हो, तो मौजूदा Perl API को non-regression test की तरह इस्तेमाल करके वही tests Go API पर चलाए जा सकते हैं, जिससे भरोसा बढ़ता है
  - जब developers ऐसे tests लिखते हैं, तो वे थोड़ी देर के लिए खुद को API consumer की स्थिति में रख पाते हैं, और इससे अक्सर बेहतर quality के tests लिखे जाते हैं
- इसे Postman जैसे product के विकल्प की तरह समझें
  कुछ साधारण HTTP request tests के लिए electron-आधारित भारी window खोलने की ज़रूरत नहीं
  यह curl scripts और Postman के बीच कहीं आता है, इसलिए जिन लोगों को हल्कापन और convenience दोनों चाहिए, उनके लिए यह बढ़िया है
- हमने ktor web server से spring boot-आधारित code (Java/Kotlin stack) पर migration करते समय Hurl का इस्तेमाल किया
  server stack से स्वतंत्र spec-level test suite चलाने की वजह से transition बहुत आसान रहा
  साथ ही, क्योंकि हम production में docker images इस्तेमाल करते हैं, implementation पर ज़रूरत से ज़्यादा निर्भर tools की जगह Hurl से integration tests बहुत हल्के और स्वतंत्र ढंग से चल सके
samples section(https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) उन लोगों के लिए बहुत persuasive है जो 5 मिनट में समझना चाहते हैं कि टूल का फ़ायदा क्या है, यानी जो पहले से जल्दी राय बना लेते हैं
मैं भी कभी-कभी ऐसा ही होता हूँ, और यह सच में प्रभावशाली लगा
मैं Hurl का maintainer हूँ
सवाल या feedback कभी भी स्वागत है
- मेरे सहित आसपास के कई developers का एक आम pattern है कि हम VS Code या IDEA की IDE extensions से चलने वाली .http files में tests लिखते हैं
  example format कुछ ऐसा होता है
```
POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }
```
  फिर output को expected.json file से one-to-one compare करके integration test करते हैं
  इन files को cURL और bespoke bash scripts से चलाया जाता है, और jq से results compare करके success/failure console में log किया जाता है
  जानना चाहता हूँ कि क्या Hurl में भी IDE के अंदर example HTTP requests और JSON file-आधारित expected results इस तरह define किए जा सकते हैं
  और क्या Hurl किसी folder के अंदर कई files को अपने आप चला सकता है
- Hurl को HTTP-level test suites को सुंदर और maintainable तरीके से लिखने की क्षमता के लिए जितनी पहचान मिलनी चाहिए, उतनी नहीं मिली है
  ऐसा टूल बनाने के लिए धन्यवाद
- Hurl नाम का चुनाव मुझे बेहद पसंद आया
  developer की समझदारी काबिले-तारीफ़ है
- मैंने कुछ समय Hurl इस्तेमाल किया और बाद में इसमें खुद योगदान भी दिया
  जानना चाहता हूँ कि include feature देने की संभावना क्या है
- लगातार maintenance के लिए धन्यवाद
  2 साल बाद Hurl की vision और future को आप कैसे देखते हैं, यह जानना चाहता हूँ
इस project से प्रेरणा लेकर मैंने खुद एक HTTP testing tool डिज़ाइन किया
हमें सैकड़ों tests को तेज़ी से parallel में चलाने की ज़रूरत थी, इसलिए अगर आपको Hurl पसंद है तो Nap भी दिलचस्प लग सकता है
- जानना चाहता हूँ कि इसकी config syntax या contents Hurl जैसी हैं या नहीं, और क्या फर्क हैं
  अगर differences को संक्षेप में दिखाने वाला कोई page है, तो कृपया बताइए
दिलचस्प लग रहा है
मैं पहले लंबे समय तक Vscode-restclient इस्तेमाल करता था, लेकिन scripting और CLI उपयोग के लिए हाल में httpyac पर जा रहा हूँ
मैं यह भी देखूँगा कि Hurl मेरी ज़रूरतों पर कितना फिट बैठता है
testing tools में एक परेशानी यह है कि .http files में एक request का result अगले request के input के रूप में refer करने के लिए अब तक कोई standard नहीं है
मैंने अब तक जो तीन tools इस्तेमाल किए हैं, उन सबका तरीका अलग है
- hurl में [Captures]
- Vscode-restclient में variable declarations में request name का reference
- httpyac में @ref syntax
  हर tool की syntax अलग होने से, एक के लिए लिखा गया content दूसरे में टूट जाता है
  संबंधित reference links
  hurl capture documentation
  Vscode-restclient
  httpyac ref documentation
- एक और file format बना देने के लिए माफ़ कीजिए!
  इस समस्या को थोड़ा कम करने के लिए hurlfmt इस्तेमाल किया जा सकता है
  hurlfmt Hurl files को JSON में export कर सकता है
  इस JSON result का इस्तेमाल करके दूसरे tools के साथ conversions भी बनाए जा सकते हैं
  यह कोई जादुई और परफेक्ट समाधान नहीं है, लेकिन Hurl से दूसरे formats में जाने में थोड़ी मदद कर सकता है
- Visual Studio Code और Visual Studio दोनों .HTTP files को support करते हैं, लेकिन दोनों आपस में compatible नहीं हैं
  यह Conway's Law के व्यवहारिक रूप में दिखने का दिलचस्प उदाहरण लगता है
थोड़ा मिलता-जुलता लगता है
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
यह VS Code extension HTTP-संबंधित testing के लिए बहुत शक्तिशाली है
- editor-independent होकर इस्तेमाल किया जा सकना ही असली बड़ा फ़र्क है
- IntelliJ में भी मिलती-जुलती सुविधा है
  https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html
- मैंने भी Hurl इस्तेमाल किया है और यह काफ़ी अच्छा लगा
  लेकिन हाल में मैं .http approach को ज़्यादा पसंद करने लगा हूँ
  यह IntelliJ में built-in है, ऊपर linked plugin भी है, और CLI में मैंने httpYac भी इस्तेमाल किया है
  इसमें vendor lock-in नहीं है, और source control या copy-paste से share करना भी बहुत आसान है
JVM पर मैं integration testing के लिए Karate इस्तेमाल करता हूँ
https://github.com/karatelabs/karate
क्योंकि इसमें मनमाने ढंग से JavaScript शामिल किया जा सकता है, request/validation को काफ़ी लचीले ढंग से लिखा जा सकता है

Hurl - कमांड लाइन पर HTTP अनुरोध और टेस्टिंग के लिए टेक्स्ट-आधारित टूल

What's Hurl?

मुख्य फीचर्स का सारांश

बुनियादी कार्यप्रणाली

chaining और variables का उपयोग

विभिन्न request और validation तरीके

test reports और automation integration

advanced control और उपयोगी सुविधाएँ