ในการทำงานสาย Developer หรือ DevOps การรับส่งข้อมูลผ่าน Network หรือทดสอบ API ผ่าน Terminal เป็นงานที่ต้องทำอยู่เสมอ แม้ว่า curl จะเป็นเครื่องมือมาตรฐานที่มีติดมากับแทบทุกระบบปฏิบัติการ แต่ในปัจจุบันก็มีทางเลือกอื่นที่ถูกพัฒนาขึ้นมาเพื่อแก้จุดหงุดหงิดของ curl เช่น เรื่องความอ่านยากของ Syntax หรือการต้องจำ Flag เยอะ
5 เครื่องมือ Command Line น่าใช้สำหรับรับส่งข้อมูล Network
1. HTTPie (http) — อ่านง่าย เขียนง่ายที่สุด
เหมาะอย่างยิ่งสำหรับการยิงทดสอบ REST API แบบไว ๆ (Ad-hoc testing) เพราะใช้ Syntax ที่สั้น กระชับ และมีการจัด Format พร้อมแยกสี JSON ให้ทันทีโดยไม่ต้องใช้ jq ช่วย
ส่ง GET Request:http api.example.com/users
ส่ง POST Request พร้อม JSON Body:http POST api.example.com/users name="John" role="admin"
2. wget — เน้นดาวน์โหลดไฟล์และเว็บไซต์
เครื่องมือคลาสสิกที่เน้นงานดาวน์โหลดโดยเฉพาะ จุดเด่นคือความเสถียร สามารถดาวน์โหลดไฟล์ต่อจากที่ค้างไว้ได้ (Resume download) และรองรับการดูดข้อมูลทั้งเว็บไซต์แบบ Recursive
ดาวน์โหลดไฟล์:wget https://example.com/file.zip
ดาวน์โหลดไฟล์ต่อกรณีเน็ตหลุด (-c):wget -c https://example.com/large-file.zip
3. xh — เร็วและเบา (Alternative ของ HTTPie)
พัฒนาด้วยภาษา Rust ให้ผลลัพธ์การแสดงผลที่สวยงามและใช้งานง่ายคล้าย http แต่กินทรัพยากรน้อยกว่า และประมวลผลได้รวดเร็วกว่ามาก
ส่ง GET Request:xh api.example.com/items
4. curlie — การผสมผสานระหว่าง curl และ http
ใช้ Engine ของ curl อยู่เบื้องหลัง แต่ปรับส่วนโต้ตอบกับผู้ใช้ (User Interface) และการแสดงผลลัพธ์ให้อ่านง่ายเหมือน HTTPie
ใช้งานเหมือน curl แต่ได้ Output สวยงาม:curlie api.example.com/data
5. aria2c — เร่งความเร็วด้วย Multi-Connection
Download Utility ทรงพลังที่สามารถดึงไฟล์พร้อมกันได้หลาย Connection/Server ช่วยให้ดาวน์โหลดเต็มสปีด รองรับทั้งโปรโตคอล HTTP, HTTPS, FTP และ BitTorrent
ดาวน์โหลดไฟล์แบบแยก 4 Connection:aria2c -x4 https://example.com/file.iso
ตารางเปรียบเทียบการเลือกใช้งาน CLI Tools
| คำสั่ง | จุดเด่น | ลักษณะงานที่เหมาะสม |
curl | ติดตั้งมากับทุก OS, ปรับแต่งระดับลึกได้ละเอียด | Shell Scripting, CI/CD Automation |
http (HTTPie) | อ่านง่าย, ไม่ต้องจำ Flag เยอะ, แยกสีอัตโนมัติ | Quick REST API Testing |
wget | เสถียร, โหลดต่อได้เมื่อหลุด, โหลดได้ทั้งเว็บ | โหลดไฟล์ใหญ่, Web Scraping |
xh | ทำงานเร็วมาก (Rust), Output สวยงาม | เช็คผลลัพธ์ API แบบเร่งด่วน |
aria2c | ดึงข้อมูลแบบ Multi-connection ได้ | โหลดไฟล์ขนาดใหญ่มาก |
ทำไมเครื่องมือ CLI ข้างต้นถึง “ไม่นิยม” ใช้สำหรับ API Testing ในระดับโปรดักชัน?
แม้ว่าเครื่องมืออย่าง curl หรือ HTTPie จะดีสำหรับการยิง Request สรุปผลแบบเร่งด่วน แต่เมื่อขยับมาเป็นการ “ทดสอบ API แบบเป็นระบบ (Systematic API Testing)” เครื่องมือสาย Command Line กลับมีข้อจำกัดที่ชัดเจน ดังนี้:
- การจัดการ Payload ซับซ้อนได้ยาก: เมื่อต้องส่ง JSON Body ที่มีโครงสร้างซ้อนกันหลายชั้น การพิมพ์ลงใน Terminal มักเกิด Human Error ได้ง่าย เช่น การลืมปิดวงเล็บ หรือพิมพ์ Escape Character ผิด
- ขาดระบบจัดการ Environment & State: การทดสอบจริงต้องสลับระหว่าง Dev, UAT และ Production รวมถึงต้องดึง Token จาก API ตัวหนึ่งไปส่งต่อให้อีกตัวหนึ่ง ซึ่งเครื่องมือ CLI ต้องใช้วิธี Copy-Paste เอง หรือต้องเขียน Bash Script มาจัดการ
- ไม่มีการจัดกลุ่มและบันทึกประวัติ (Collections): เมื่อโปรเจกต์มี API ระดับสิบหรือร้อยตัว CLI ไม่สามารถจัดหมวดหมู่ให้ยิงซ้ำได้ง่าย ต้องคอยกดหาประวัติเก่าจาก Terminal History
- เขียนการตรวจสอบความถูกต้อง (Assertions) ลำบาก: การเช็ค Status Code หรือการตรวจว่า Data Type ถูกต้องหรือไม่ ถ้าทำบน CLI ต้องส่ง Output ไป Pipe ผ่านเครื่องมืออย่าง
jqหรือgrepเพิ่มเติม ต่างจากเครื่องมือทดสอบ API โดยเฉพาะที่มีระบบ Test Script ให้ในตัว - ไม่เอื้อต่อการทำงานร่วมกันในทีม (Collaboration): การแชร์เคสการทดสอบให้เพื่อนร่วมทีม เครื่องมือ CLI ทำได้แค่การส่งไฟล์ Text รวมคำสั่งยาวๆ ในขณะที่เครื่องมือทดสอบ API แบบ GUI สามารถ Export หรือ Sync ผ่าน Cloud ได้ทันที
สรุปทางเลือกที่เหมาะสม
- ใช้ CLI Tools (
curl,HTTPie,xh) เมื่อ: ต้องการตรวจสอบการทำงานของ Endpoint ไวๆ, เขียนสคริปต์อัตโนมัติบน Server หรือรันใน pipeline ของ CI/CD - ใช้เครื่องมือเฉพาะทาง (เช่น Postman, Insomnia, Bruno, Playwright) เมื่อ: ต้องการออกแบบ API Test Suite, มีการจัดการ Auth/Token ที่ต้องส่งต่อกัน, และต้องการทำระบบ Automated Test ร่วมกันในทีม
อ่านเพิ่มเติม