Hurl - เครื่องมือแบบข้อความสำหรับการส่งคำขอ HTTP และการทดสอบบนคอมมานด์ไลน์

 (github.com/Orange-OpenSource)
27 คะแนน โดย GN⁺ 2025-06-21 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือคอมมานด์ไลน์โอเพนซอร์ส ที่สามารถ ส่งคำขอ HTTP ด้วยรูปแบบไฟล์ข้อความที่เรียบง่าย พร้อมทั้งเชื่อมหลายคำขอเข้าด้วยกัน ดึงค่าจากผลลัพธ์ และทำคิวรี/ตรวจสอบเนื้อหาและเฮดเดอร์ของการตอบกลับได้
  • รองรับ API หลากหลายประเภท เช่น REST, SOAP, GraphQL รวมถึงคำขอที่อิงกับ HTML/XML/JSON และเหมาะทั้งสำหรับ การดึงข้อมูลและการทดสอบ HTTP session
  • รองรับ การเชื่อมคำขอ การจับค่า และการตรวจสอบหลากหลายรูปแบบ เช่น สถานะโค้ด เฮดเดอร์ และบอดี อีกทั้งยังเหมาะกับ การเชื่อมต่อ CI/CD และงานอัตโนมัติ ผ่านรายงานแบบ Junit, TAP, HTML, JSON เป็นต้น
  • แจกจ่ายในรูปแบบ ไฟล์รันได้เดี่ยวที่พัฒนาด้วย Rust จึง ติดตั้งได้ง่าย และภายในใช้ เอนจิน libcurl เพื่อมอบ ความเร็วสูงและความเข้ากันได้ของโปรโตคอลที่แข็งแกร่ง
  • ได้รับการประเมินว่าเป็น เครื่องมืออัตโนมัติสำหรับการทดสอบ HTTP ยุคใหม่ ที่มีทั้งไวยากรณ์กระชับ ความสามารถในการขยาย และฟีเจอร์ที่หลากหลาย เมื่อเทียบกับเครื่องมือคู่แข่ง
  • ในฐานะ โอเพนซอร์สที่ขับเคลื่อนโดยชุมชน รูปแบบ ข้อความที่เข้าใจง่ายและขยายได้ ทำให้ทั้งนักพัฒนาและ DevOps ใช้งานได้อย่างมีประสิทธิภาพสูง

Hurl คืออะไร?

  • Hurl เป็นเครื่องมือที่ให้เขียนคำขอ HTTP ในรูปแบบข้อความที่ชัดเจนและเข้าใจง่าย แล้วรันผ่านคอมมานด์ไลน์ได้
  • สามารถ เชื่อมหลายคำขอเข้าด้วยกันเหมือนเป็นสายงาน, ดึงค่าจากผลลัพธ์ หรือใช้คิวรีหลากหลายแบบ (เช่น เฮดเดอร์ บอดี สถานะโค้ด) เพื่อ ทดสอบสถานการณ์ HTTP ที่ซับซ้อน ได้
  • สร้างบนพื้นฐาน เอนจิน libcurl จึงมีความน่าเชื่อถือสูง และ รองรับโปรโตคอลสมัยใหม่อย่าง IPv6, HTTP/3
  • รองรับทั้ง การดึงข้อมูล การทดสอบสถานการณ์ และการวัดประสิทธิภาพ (เช่น เวลาตอบสนอง)
  • เหมาะอย่างยิ่งสำหรับ การสร้างรายงาน (Junit, TAP, HTML ฯลฯ) และการเชื่อมเข้ากับ CI/CD pipeline
  • รองรับ API หลายประเภท เช่น REST, SOAP, GraphQL, HTML, XML, JSON และยังรองรับ การพาร์สบอดี (เช่น XPath, JSONPath)
  • ต่อไปนี้คือ จุดแข็งสำคัญของ Hurl เมื่อเทียบกับเครื่องมือทดสอบ HTTP อื่น ๆ (เช่น Postman, curl):
    • เขียนเป็น plain text ได้ จึงเหมาะกับการจัดการเวอร์ชันและการทำงานร่วมกัน
    • มีไบนารีเดี่ยวขนาดเล็กที่เขียนด้วย Rust โดยไม่ต้องใช้รันไทม์เพิ่มเติม
    • ใช้เอนจินเครือข่ายเดียวกับ curl (libcurl) จึงเชื่อถือได้และรองรับโปรโตคอลหลากหลาย
    • รองรับรูปแบบหลากหลาย เช่น REST, SOAP, GraphQL, HTML และตั้งค่าสถานการณ์ที่ซับซ้อนได้
    • ผสานเข้ากับ CI/CD, ระบบทดสอบอัตโนมัติ และรายงานแบบละเอียด (JUnit, HTML, TAP ฯลฯ) ได้ง่าย

สรุปฟีเจอร์หลัก

  • การทำงานพื้นฐาน

    • เขียนคำขอ HTTP หลายรายการต่อเนื่องกันในไฟล์ Hurl (.hurl) แล้วรันตามลำดับ
    • ดึงค่าจากการตอบกลับของแต่ละคำขอ ตรวจสอบเงื่อนไข และส่งต่อข้อมูลไปยังคำขอถัดไปได้
    • รองรับรูปแบบหลากหลาย เช่น REST/JSON, SOAP/XML, GraphQL, HTML

  • การเชื่อมคำขอและการใช้ตัวแปร

    • เขียนหลายคำขอแบบ chain ภายในไฟล์เดียว
    • ใช้ไวยากรณ์ Captures เพื่อดึงค่าจากการตอบกลับ แล้วนำไปใส่เป็นตัวแปรในคำขอถัดไป
    • ดึงและใช้งานข้อมูลผ่าน XPath, JSONPath, regular expression, โครงสร้างของบอดี เป็นต้น

  • รูปแบบคำขอและการตรวจสอบที่หลากหลาย

    • รองรับการตั้งค่ารายละเอียดคำขอหลากหลาย เช่น query parameter, header, การยืนยันตัวตน
    • ใช้ไวยากรณ์ [Asserts] หรือไวยากรณ์แบบ implicit เพื่อตรวจสอบสถานะโค้ด บอดี เฮดเดอร์ คุกกี้ เวลาตอบสนอง แฮช ฯลฯ
    • ใช้ XPath, JSONPath ได้ และสามารถทดสอบทั้ง REST/GraphQL/SOAP รวมถึงเนื้อหา HTML
    • รองรับการตรวจสอบหลายค่า บอดี/แฮชของการตอบกลับ คุณสมบัติของใบรับรอง การหน่วงของคำขอ/การตอบกลับ และการจัดการข้อมูลไบนารี

  • รายงานการทดสอบและการเชื่อมต่อระบบอัตโนมัติ

    • แสดงผลลัพธ์การรันเป็นรายงานได้หลายรูปแบบ เช่น text, HTML, JUnit, TAP, JSON
    • ผสานเข้ากับ CI/CD pipeline ได้อย่างง่ายดาย

  • การควบคุมขั้นสูงและฟังก์ชันที่มีประโยชน์

    • ส่งต่อข้อมูลระหว่างคำขอ (capture และการทำเป็นตัวแปร)
    • ฟังก์ชันสร้างข้อมูลแบบไดนามิก (newUuid, newDate เป็นต้น)
    • ปรับแต่งตัวเลือกแยกตามคำขอ
    • รองรับ polling/retry, delay ของคำขอ, skip, การปกปิดค่าลับ (redact)
    • รองรับตัวเลือกแบบเดียวกับ curl (ใช้ curl option เดิมได้เลย)
    • มีฟีเจอร์เฉพาะคลาวด์ในตัว เช่น การยืนยันตัวตนแบบ AWS Sigv4

ตัวอย่างการใช้งาน

  • กำหนด คำขอ GET/POST แบบง่าย และ การเชื่อมคำขอหลายขั้นตอน ด้วยไฟล์ข้อความเรียบง่าย
    • เขียนไฟล์ sample.hurl แล้วรันคำสั่ง $ hurl sample.hurl เพื่อส่งคำขอทั้งหมดในคราวเดียว
  • ตัวอย่าง: 
      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
  • สามารถ ทดสอบหลาย API endpoint และเปรียบเทียบค่าการตอบกลับ, ใช้ค่าที่ส่งต่อกันใน chain (เช่น token), และ ตรวจสอบสถานะโค้ด เฮดเดอร์ รวมถึงข้อมูลในบอดี ได้

ตัวอย่างการใช้งานที่พบได้บ่อย

  • ทดสอบ API หลายประเภท เช่น REST/GraphQL/HTML/JSON/SOAP
  • ดึงและนำค่ากลับมาใช้ซ้ำ เช่น CSRF token, ข้อมูลยืนยันตัวตนและสิทธิ์การเข้าถึง
  • ตรวจสอบอย่างละเอียด เช่น สถานะโค้ด เฮดเดอร์ ข้อมูลในบอดี คุกกี้ ใบรับรอง SSL
  • ทำงานอัตโนมัติและมอนิเตอร์สถานการณ์ของบริการจริง (เช่น ตั้งแต่ล็อกอินไปจนถึงการทำงานทางธุรกิจ)
  • รองรับหลายแพลตฟอร์มและหลายวิธีติดตั้ง (Linux, macOS, Windows, Docker, npm, Cargo เป็นต้น)

ตัวเลือก CLI ที่สำคัญ

  • --test: โหมดทดสอบ (แสดงสรุปและรายงาน)
  • --report-html, --report-json, --report-junit, --report-tap: รองรับรูปแบบรายงานหลากหลาย
  • --parallel, --jobs N: รันแบบขนาน
  • --retry, --retry-interval: retry/รออัตโนมัติ
  • -u, --user: ป้อนข้อมูลการยืนยันตัวตน
  • --variable, --variables-file: กำหนดตัวแปร
  • -o, --output: บันทึกการตอบกลับเป็นไฟล์
  • --json: แสดงผลลัพธ์การรันในรูปแบบ JSON

วิธีติดตั้ง

  • ติดตั้งได้หลายวิธี เช่น Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm
  • เป็นไบนารีเดี่ยวจึงไม่ต้องใช้รันไทม์เพิ่มเติม
  • ตัวอย่าง: 
    brew install hurl
    หรือ 
    cargo install --locked hurl

ข้อได้เปรียบเมื่อเทียบกับเครื่องมือคู่แข่ง

  • ได้เปรียบกว่าเครื่องมือ GUI อย่าง Postman, Insomnia ในด้านการทำงานแบบข้อความ การจัดการเวอร์ชัน และการเชื่อมกับ CI/CD
  • เฉพาะทางมากกว่า curl สำหรับการทดสอบ การรันสถานการณ์ การตรวจสอบ และการทำรายงานอัตโนมัติ
  • มีเส้นโค้งการเรียนรู้ต่ำกว่า เมื่อเทียบกับ DSL ที่ซับซ้อนอย่าง YAML หรือ JSON เพราะใช้ฟอร์แมตเฉพาะที่เข้าใจง่าย

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
seunggi 2025-07-04

Bruno - ไคลเอนต์ API โอเพนซอร์สที่รวดเร็วและเป็นมิตรกับ Git (ทางเลือกแทน Postman)
https://th.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 และโหมดเรียกใช้งานทีละคำขอ
    ผมใช้มันรันชุดทดสอบ HTTP requests ใน CI
    รู้สึกว่าภาษาคอนฟิกแบบบล็อกยังไม่ค่อย intuitive และเอกสารเกี่ยวกับ assertion ที่รองรับก็ยังขาดไปนิดหน่อย
    โดยรวมแล้วตัวเครื่องมือมีคุณค่ามาก
    ตอนทำ POC ผมเริ่มทดสอบ interface ด้วยวิธีนี้ และพบว่ามันช่วยงานพัฒนาแบบอิง LLM ได้ด้วย
    พอเขียนเทสต์ไว้ตรงกับ HTTP method โดยตรง เทสต์กับ implementation ก็แยกจากกันได้ยืดหยุ่นขึ้นระหว่างที่โปรเจ็กต์ค่อย ๆ เปลี่ยนแปลง
    การแยกเทสต์ออกมาทำให้เส้นแบ่งระหว่าง interface กับ implementation ชัดขึ้น
    ก่อนใช้ hurl ผมเขียนเทสต์ด้วย testing framework ของภาษาที่ใช้ทำ service แต่พอเปลี่ยนมาใช้เทสต์แบบ hurl ก็ทำให้ยึดมุมมองแบบ 'ฝั่ง client' ได้อย่างเคร่งครัด
    ไม่มีการเข้าถึงข้อมูลแบบ backdoor อะไรทำนองนั้น ทำให้ interface, test และ implementation ถูกแยกจากกันชัดเจนและวางใจได้

    • ผมเป็นผู้พัฒนาของ hurl
      ขอบคุณสำหรับฟีดแบ็ก
      ตอนเริ่มพัฒนาครั้งแรกเมื่อ 6~7 ปีก่อน ผมลองทั้ง JSON แล้วก็ตามด้วย YAML แต่สุดท้ายก็ค่อย ๆ มั่นใจว่าควรทำ file format ใหม่ขึ้นมาเอง
      ผมเข้าใจดีว่าจากมุมผู้ใช้มันอาจดูแปลก ๆ
      ผมพยายามใช้ไวยากรณ์ที่เรียบง่ายกับเคสที่ง่ายกว่า แต่ก็อาจยังไม่สมบูรณ์
      เรื่องเอกสาร ถ้ามีจุดที่ยังขาดหรือควรปรับปรุง ก็หวังว่าจะได้รับความคิดเห็นอย่างเต็มที่และนำไปพัฒนาต่อ

  • Hurl เป็นเครื่องมือที่ยอดเยี่ยมมาก
    ตอนก่อนหน้านี้ผมพอร์ตเว็บเซอร์วิสที่เขียนด้วย Python ไปเป็น Rust แล้วการมี public API tests ที่เข้มงวดช่วยได้มาก
    เพราะสภาพแวดล้อม integration test ไม่ผูกกับภาษา เราเลยคง API หรือเว็บไซต์เดิมไว้ได้ แล้วเปลี่ยนแค่ backend
    มีข้อดีพิเศษอีกอย่างเวลาใช้ Hurl กับ Rust
    คือมันผสานกับ cargo test ได้ และใช้ hurl library ได้ตรง ๆ พร้อม reuse ไฟล์ .hurl เดิมได้เลย
    เดโม: https://github.com/perrygeo/axum-hurl-test

  • ผมเริ่มใช้ Hurl ตั้งแต่เดือนกันยายน 2023
    ก่อนหน้านี้รัน test suite ผ่าน Runscope แต่รำคาญมากที่การเปลี่ยนแปลงไม่ถูกจัดการด้วย version control
    หลังจากเตรียมพื้นฐานแล้วก็ย้ายมาใช้ Hurl และเลิกใช้ Runscope ไปเลย
    ตอนนี้ผมพอใจมาก เพราะดูออกได้ทันทีว่าใครเปลี่ยนอะไร เมื่อไร และทำไม

    • ผมก็เกลียดมากเหมือนกันที่ Runscope ไม่ทำ version control ให้กับการเปลี่ยนแปลง
      ทีมเราก็เคยพยายามแก้ปัญหานั้น แล้วโปรเจ็กต์ก็เสีย momentum ไปเลย

  • ผมคิดว่าแนวคิดนี้ดี แต่ก็ยังอดคิดไม่ได้ว่า ‘ทำไมต้องใช้มัน’
    ผมพัฒนาใน Django ซึ่งความสามารถทดสอบที่มากับ framework ก็ครบมากอยู่แล้ว
    การเพิ่มเครื่องมือจากภายนอกที่ไม่รู้จัก backend ของผมเลย ดูเหมือนจะเพิ่มภาระเรื่อง sync มากกว่า
    และถ้ามีอะไรแปลก ๆ ก็จะกระโดดเข้า debugger ทันทีไม่ได้
    แน่นอนว่ามีเหตุผลเรื่องการแยก test code กับ backend code ให้ชัดเจน แต่ในทางปฏิบัติค่าใช้จ่ายในการดูแลก็มากขึ้น
    สุดท้ายก็คงต้องรัน native test suite อยู่ดี เลยรู้สึกแปลก ๆ ถ้าต้องใช้หลายเครื่องมือภายนอกควบคู่กัน
    แต่ถ้าใช้เพื่อตรวจสอบว่า API ทำงานได้ทั่วไปแค่ไหน มันก็น่าจะมีประโยชน์

    • ผมก็คิดหนักเหมือนกันกับคำถามที่ว่า ทำไมต้องใช้เครื่องมือที่ไม่รู้จัก backend ของตัวเองแล้วเพิ่มภาระการ sync
      ผมไม่เคยใช้ hurl แต่เคยใช้เครื่องมือทดสอบ API แบบไม่ผูกกับภาษามาหลายครั้ง และตอนนี้ก็กำลังพัฒนาอยู่เองด้วย
      เหตุผลที่เครื่องมือแบบนี้ดูน่าสนใจก็คือ

      • มันไม่จำเป็นต้องรู้ implementation ภายใน ซึ่งกลับเป็นข้อดี
        เพราะโครงสร้างที่ตรวจแค่ input-output ทำให้ไม่ต้องพึ่งพา logic ภายใน
      • มันเป็นอิสระจากภาษา เลยแชร์กับทีมอื่นได้ หรือใช้เป็นเอกสารแทน OpenAPI spec ได้ด้วย
      • มันทดสอบตัว API contract เอง จึงนำกลับมาใช้ซ้ำได้แม้ตอน migration ครั้งใหญ่
        เช่น เวลาย้าย public API จาก Perl ไป Go ก็ใช้ Perl API เดิมเป็น non-regression tests แล้วเอาเทสต์ชุดเดิมไปรันกับ Go API ได้ตรง ๆ ทำให้มั่นใจขึ้นมาก
      • เวลานักพัฒนาเขียนเทสต์แบบนี้ จะได้สลับมุมมองมาเป็นผู้ใช้ API ชั่วคราว จึงเขียนเทสต์ที่มีคุณภาพสูงขึ้นได้

    • มองมันเป็นตัวแทนของผลิตภัณฑ์อย่าง Postman ก็ได้
      ถ้าต้องการแค่ทดสอบ http requests ง่าย ๆ ไม่กี่รายการ ก็ไม่จำเป็นต้องเปิดหน้าต่างหนัก ๆ ที่สร้างบน Electron
      มันอยู่กึ่งกลางระหว่าง curl script กับ Postman และเหมาะมากสำหรับคนที่ต้องการทั้งความเบาและความสะดวก

    • ตอนที่เราย้ายจาก ktor web server ไปเป็นโค้ดที่อิง spring boot (สแตก Java/Kotlin) เราใช้ Hurl
      เพราะเราสามารถดูแล test suite ระดับสเปกได้โดยไม่ขึ้นกับ server stack การย้ายจึงราบรื่นมาก
      อีกอย่าง เราใช้ Docker image ใน production ด้วย เลยใช้ Hurl ทำ integration tests ให้เบาและเป็นอิสระได้มาก แทนที่จะใช้เครื่องมือที่ผูกกับ implementation มากเกินไป

  • ส่วน samples (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) ให้ความรู้สึกโน้มน้าวมากสำหรับคนที่อยากเข้าใจจุดเด่นของเครื่องมือใน 5 นาที หรือคนที่ชอบตัดสินล่วงหน้า
    บางครั้งผมก็เป็นแบบนั้นเหมือนกัน และมันน่าประทับใจจริง ๆ

  • ผมเป็น maintainer ของ Hurl
    ยินดีรับคำถามหรือฟีดแบ็กเสมอ

    • เป็นแพตเทิร์นที่ทั้งผมและนักพัฒนารอบตัวใช้กันบ่อย คือเขียนเทสต์เป็นไฟล์ ".http" ที่รันได้ผ่าน IDE extension ของ VS Code หรือ IDEA
      รูปแบบตัวอย่างคือ

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

      จากนั้นก็เทียบ output แบบ 1:1 กับไฟล์ "expected.json" เพื่อทำ integration test
      เรารันไฟล์เหล่านี้ด้วย cURL และ bespoke bash scripts แล้วใช้ jq เทียบผล พร้อม log success/failure ลง console
      อยากรู้ว่าใน Hurl สามารถกำหนดตัวอย่าง HTTP requests และ expected results แบบอิงไฟล์ JSON ใน IDE ได้ประมาณนี้ไหม
      แล้ว Hurl สามารถรันหลายไฟล์ในโฟลเดอร์แบบอัตโนมัติได้หรือเปล่า

    • Hurl ถูกประเมินค่าต่ำเกินไปในแง่ที่ทำให้เขียน HTTP-level test suite ได้อย่างสวยงามและดูแลง่าย
      ขอบคุณที่พัฒนาเครื่องมือแบบนี้ขึ้นมา

    • ผมชอบชื่อ Hurl มาก
      รู้สึกได้เลยว่าคนตั้งชื่อมีเซนส์สุด ๆ

    • ผมใช้ Hurl อยู่พักหนึ่งแล้วก็เคยมีส่วนร่วมพัฒนาโดยตรงด้วย
      อยากรู้ว่ามีโอกาสจะมีฟีเจอร์ "include" ไหม

    • ขอบคุณที่ดูแลโครงการนี้อย่างต่อเนื่อง
      อยากรู้ว่าวิสัยทัศน์และอนาคตของ Hurl ในอีก 2 ปีข้างหน้ามองไว้แบบไหน

  • ผมได้รับแรงบันดาลใจจากโปรเจ็กต์นี้มากจนออกแบบเครื่องมือทดสอบ HTTP ของตัวเอง
    เราจำเป็นต้องรันเทสต์หลายร้อยรายการแบบขนานอย่างรวดเร็ว และถ้าคุณชอบ Hurl เครื่องมือชื่อ Nap ก็น่าจะน่าสนใจเหมือนกัน

    • อยากรู้ว่า syntax หรือเนื้อหาของ config เหมือน Hurl ไหม และต่างกันตรงไหน
      ถ้ามีหน้าที่สรุปความแตกต่างไว้ก็ช่วยบอกที

  • ดูน่าสนใจดี
    เดิมทีผมใช้ Vscode-restclient มานาน แต่ช่วงหลังเริ่มย้ายไปใช้ httpyac สำหรับงาน script และ CLI
    ผมตั้งใจจะดูว่า Hurl ตรงกับสิ่งที่ผมต้องการไหม
    เรื่องหนึ่งที่ทำให้ใช้เครื่องมือเทสต์แล้วติดขัดคือ ในไฟล์ .http ยังไม่มีมาตรฐานสำหรับอ้างอิงผลลัพธ์จากคำขอหนึ่งไปเป็นอินพุตของคำขอถัดไป
    เครื่องมือทั้งสามที่ผมเคยใช้มาทำเรื่องนี้คนละแบบหมด

    • hurl ใช้ [Captures]

    • Vscode-restclient อ้างชื่อคำขอจากการประกาศตัวแปร

    • httpyac ใช้ไวยากรณ์ @ref
      syntax ของแต่ละตัวต่างกันหมด พอเขียนให้เครื่องมือหนึ่ง อีกที่ก็มักใช้ไม่ได้
      ลิงก์อ้างอิงที่เกี่ยวข้อง
      เอกสาร capture ของ hurl
      Vscode-restclient
      เอกสาร ref ของ httpyac

    • ขอโทษที่ต้องสร้าง file format ขึ้นมาอีกแบบ!
      วิธีหนึ่งที่อาจช่วยลดปัญหานี้ได้บ้างคือใช้ hurlfmt
      hurlfmt สามารถ export ไฟล์ Hurl ออกมาเป็น JSON ได้
      คุณอาจใช้ผลลัพธ์ JSON นี้ไปทำตัวแปลงไปมาระหว่างเครื่องมืออื่น ๆ ได้
      มันไม่ใช่คำตอบวิเศษที่แก้ได้ทุกอย่าง แต่ก็น่าจะช่วยได้บ้างเวลาอยากย้ายจาก Hurl ไปยังฟอร์แมตอื่น

    • ทั้ง Visual Studio Code และ Visual Studio ต่างก็รองรับไฟล์ .HTTP แต่กลับเข้ากันไม่ได้
      น่าสนใจดีในฐานะตัวอย่างของ Conway's Law ที่เกิดขึ้นจริง

  • ดูคล้ายกันอยู่บ้าง
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    VS Code extension ตัวนี้ทรงพลังมากสำหรับการทดสอบเกี่ยวกับ HTTP

    • ความแตกต่างสำคัญมากคือมันใช้งานได้แบบไม่ผูกกับ editor

    • IntelliJ ก็มีความสามารถคล้ายกัน
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • ผมก็เคยใช้ Hurl และรู้สึกว่ามันค่อนข้างดี
      แต่ช่วงหลังผมกลับชอบแนวทาง .http มากกว่า
      ใน IntelliJ ก็มีมาให้ในตัว มีปลั๊กอินที่ลิงก์ไว้ด้านบน และบน CLI ผมก็เคยใช้ httpYac
      ไม่มี vendor lock-in และแชร์ผ่าน source control หรือ copy-paste ได้ง่ายมาก

  • บน JVM ผมทำ integration tests ด้วย Karate
    https://github.com/karatelabs/karate
    เพราะมันสามารถฝัง JavaScript ตามต้องการได้ เลยเขียน request/validation ได้ยืดหยุ่นมาก