หากคุณทำงานในเทอร์มินัลเป็นหลัก แต่รู้สึกว่าไวยากรณ์ของ curl ยาวเกินไปและเอาต์พุตอ่านยาก curlie เป็นเครื่องมือที่ควรรู้จัก มันเป็น HTTP client แบบคอมมานด์ไลน์ที่ทำงานครอบ curl และใช้ไวยากรณ์ที่เป็นมิตรพร้อมเอาต์พุตสีสันแบบ HTTPie คุณจึงทดสอบ endpoint ได้เร็ว อ่าน response ได้ง่าย และยังใช้พลังของ curl ได้เหมือนเดิม
curlie คืออะไร
curlie เป็น frontend สำหรับ curl ไม่ได้สร้าง HTTP engine ใหม่ แต่จะแปลงคำสั่งสั้น ๆ สไตล์ HTTPie ให้เป็นคำสั่ง curl ที่เทียบเท่า แล้วส่งคำขอผ่าน binary ของ curl บนเครื่องคุณ
ผลลัพธ์คือคุณได้:
- ไวยากรณ์ที่สั้นกว่า curl
- เอาต์พุตที่มีสี
- JSON ที่จัดรูปแบบให้อ่านง่าย
- ความสามารถของ curl เดิม รวมถึง TLS, proxy, protocol support และ flags ต่าง ๆ
แนวคิดสำคัญคือ curlie ไม่ได้มาแทน curl แต่ทำให้ curl ใช้งานแบบ interactive ได้ง่ายขึ้น คุณยังสามารถส่งผ่าน flag ของ curl ได้โดยตรงเมื่อจำเป็น
โปรเจกต์นี้เป็น Go binary ไฟล์เดียว ดูแลบน GitHub ไม่ต้องติดตั้ง Python runtime หรือ plugin เพิ่มเติม เพียงวาง binary ไว้ใน PATH ก็ใช้งานได้
เหมาะสำหรับงานแบบ ad-hoc เช่น ทดสอบ endpoint, ตรวจ response, debug header หรือ authentication จากเทอร์มินัล แต่ไม่ใช่เครื่องมือสำหรับ test automation แบบเต็มรูปแบบ
ทำไมควรใช้ curlie
curl มีอยู่แทบทุกเครื่อง แต่เอาต์พุตดิบมักอ่านยาก โดยเฉพาะ JSON ที่อยู่บรรทัดเดียว หรือ header/body ที่ต้องใช้ flag เพิ่มเพื่อแยกดู
HTTPie แก้ปัญหานี้ด้วยไวยากรณ์ที่อ่านง่ายและเอาต์พุตสวยงาม ส่วน curlie อยู่ตรงกลางระหว่างสองเครื่องมือนี้: ได้ความอ่านง่ายแบบ HTTPie แต่ยังใช้ curl เป็น engine
เหตุผลที่ curlie มีประโยชน์กับ developer:
อ่าน response ง่ายขึ้นทันที
JSON ถูก pretty-print และมี syntax highlightingเขียน request สั้นกว่า curl
ใช้รูปแบบkey=value,Header:value,param==valueแทนการซ้อน-Hและ-dยังใช้ curl flags ได้
เช่น-v,--max-time,--proxy,--insecureติดตั้งง่าย
เป็น binary เดี่ยว ไม่ต้องจัดการ dependency จำนวนมากใช้เรียนรู้ curl ได้ดี
เปิด verbose mode เพื่อดู request/response headers และพฤติกรรมจริงที่ curl ใช้
การติดตั้ง curlie
curlie มีทั้ง binary ที่ build ไว้แล้วและติดตั้งผ่าน package manager ได้ วิธีที่ใช้จริงขึ้นอยู่กับระบบของคุณ ควรตรวจสอบ release ล่าสุดจาก GitHub เสมอ
บน macOS ด้วย Homebrew:
brew install curlie
ถ้ามี Go ติดตั้งอยู่แล้ว:
go install github.com/rs/curlie@latest
หรือดาวน์โหลด binary สำหรับ platform ของคุณจากหน้า releases แล้ววางไว้ใน PATH:
# ตัวอย่าง: ย้าย binary ที่ดาวน์โหลดมาไว้ใน PATH
mv curlie /usr/local/bin/
# ตรวจสอบว่าใช้งานได้
curlie --version
curlie ต้องมี curl อยู่ในระบบ เพราะมันเรียกใช้งาน curl จริง ๆ เบื้องหลัง บน macOS และ Linux ส่วนใหญ่มักมี curl ติดตั้งมาให้อยู่แล้ว
การใช้งานพื้นฐาน
1. ส่ง GET request
คำสั่ง GET แบบง่ายที่สุดคือใส่ URL:
curlie httpbin.org/get
ถ้าไม่ระบุ method curlie จะถือว่าเป็น GET และถ้าละ http:// หรือ https:// ไว้ curlie จะเติม scheme ให้โดยอัตโนมัติ
2. ส่ง JSON body
ใช้รูปแบบ key=value เพื่อสร้าง JSON body:
curlie POST httpbin.org/post name=apidog role=platform
คำสั่งนี้จะส่ง body ประมาณนี้:
{
"name": "apidog",
"role": "platform"
}
curlie จะตั้งค่า Content-Type: application/json ให้โดยอัตโนมัติ
3. เพิ่ม header
ใช้รูปแบบ Header:value:
curlie GET httpbin.org/get Authorization:"Bearer token123"
ตัวอย่างที่อ่านง่ายขึ้นเมื่อมีหลายบรรทัด:
curlie GET httpbin.org/get \
Authorization:"Bearer token123" \
Accept:"application/json"
4. เพิ่ม query parameters
ใช้ param==value:
curlie GET httpbin.org/get search==apidog page==1
เทียบเท่ากับการเรียก URL ประมาณนี้:
http://httpbin.org/get?search=apidog&page=1
5. ใช้ curl flags ร่วมด้วย
เพราะ curlie ทำงานครอบ curl คุณจึงยังใช้ flag ของ curl ได้:
curlie -v --max-time 5 httpbin.org/get
แนะนำให้ใช้ -v เมื่อต้อง debug เพราะจะเห็น header และรายละเอียด request/response ชัดเจนขึ้น
ถ้าต้องการทบทวน curl แบบละเอียด ดูเพิ่มเติมได้ที่ คู่มือ curl REST API
ตัวอย่าง workflow ที่ใช้ได้จริง
ตรวจ endpoint ว่าทำงานอยู่หรือไม่
curlie https://api.example.com/health
ดูว่า response status และ JSON ตรงกับที่คาดไว้หรือไม่
Debug authentication
curlie -v GET https://api.example.com/me \
Authorization:"Bearer $TOKEN"
ใช้ -v เพื่อเช็กว่า header ถูกส่งจริงหรือไม่
ส่ง POST พร้อม JSON
curlie POST https://api.example.com/users \
Authorization:"Bearer $TOKEN" \
name="Alice" \
role="admin"
เหมาะสำหรับลอง endpoint ระหว่างพัฒนา API หรือทดสอบ request payload อย่างรวดเร็ว
ใช้ timeout เพื่อตรวจ latency หรือปัญหา network
curlie --max-time 3 https://api.example.com/reports
ถ้า request ใช้เวลานานเกิน 3 วินาที คำสั่งจะหยุดตาม behavior ของ curl
curlie เทียบกับ curl เทียบกับ HTTPie
ทั้งสามเครื่องมือใช้ส่ง HTTP request จากเทอร์มินัลได้เหมือนกัน ความแตกต่างหลักอยู่ที่ syntax, output และ engine เบื้องหลัง
| คุณสมบัติ | curl | HTTPie | curlie |
|---|---|---|---|
| เอนจิน | libcurl | Python / requests-style | curl |
| ไวยากรณ์ | เน้น flag เช่น -X, -H, -d
|
กระชับ เช่น key=value
|
กระชับ สไตล์ HTTPie |
| เอาต์พุต | ดิบ ไม่จัดรูปแบบ | มีสี JSON อ่านง่าย | มีสี JSON อ่านง่าย |
| การติดตั้ง | มักติดตั้งมาให้แล้ว | แพ็กเกจ Python | Go binary ไฟล์เดียว |
| ใช้ curl flags เดิม | ได้ | ไม่ได้โดยตรง | ได้ |
| Dependency | น้อยมาก | Python runtime | ต้องมี curl |
| เหมาะกับ | script และ ad-hoc calls | interactive API calls | interactive API calls ที่ยังต้องการ curl |
สรุปสั้น ๆ:
- ใช้ curl เมื่อต้องการ compatibility สูงสุดหรือเขียน script ที่ portable มาก
- ใช้ HTTPie ถ้าต้องการ client แบบ standalone ที่มี syntax เป็นมิตร
- ใช้ curlie ถ้าต้องการความอ่านง่ายแบบ HTTPie แต่ยังต้องใช้ curl flags และ behavior เดิม
อ่านเพิ่มเกี่ยวกับ HTTPie ได้ที่ บทช่วยสอน HTTPie และถ้าต้องการเทียบ syntax ระหว่าง curl กับ HTTPie ดู การเปรียบเทียบ curl กับ HTTPie
สำหรับตัวเลือกอื่นนอกเหนือจากเครื่องมือกลุ่มนี้ ดู ทางเลือกของ curl สำหรับการทดสอบ REST API
เมื่อใดควรใช้ curlie
curlie เหมาะกับงานที่ต้องการความเร็วและการโต้ตอบทันที:
- เช็กว่า endpoint ยังทำงานอยู่หรือไม่
- ตรวจ response JSON ด้วยสายตา
- debug header, token, cookie หรือ authentication flow
- ทดลอง payload ก่อนนำไปเขียนในแอปจริง
- สาธิต HTTP request เพราะอ่านคำสั่งง่ายกว่า curl
ตัวอย่าง:
curlie GET https://api.example.com/orders \
Authorization:"Bearer $TOKEN" \
status==paid
เหมาะกับการสำรวจ API อย่างรวดเร็วโดยไม่ต้องเปิด GUI tool
เมื่อใดไม่ควรใช้ curlie
curlie ไม่เหมาะกับงานที่ต้องทำซ้ำ แบ่งปัน หรือ validate อัตโนมัติ เช่น:
- ต้องเก็บ request เป็น collection
- ต้องสลับ environment ระหว่าง local, staging, production
- ต้องมี assertions เช่น status ต้องเป็น
200 - ต้องตรวจ schema หรือ field ใน response
- ต้องรันใน CI/CD และให้ pipeline fail เมื่อ API ผิดปกติ
- ต้องสร้างรายงาน test result
ถ้าคุณเริ่ม copy คำสั่ง curlie เดิม ๆ ไปไว้ในเอกสาร หรือเขียน shell script พร้อม grep เพื่อเช็ก response นั่นคือสัญญาณว่าควรย้ายไปใช้ workflow ที่บันทึกและทำซ้ำได้
เส้นทางอัปเกรด: จากคำสั่งครั้งเดียวไปสู่ workflow ที่ทำซ้ำได้
ใช้ curlie สำหรับการสำรวจ endpoint จากนั้นเมื่อ request เริ่มมีความสำคัญ ให้ย้ายไปยังระบบที่บันทึก แชร์ และทดสอบซ้ำได้
Apidog ทำหน้าที่เป็นชั้นถัดไปหลังจากการทดลองในเทอร์มินัล ไม่ได้แทนที่ curlie สำหรับงานเร็ว ๆ แต่ช่วยจัดการ request ที่ต้องอยู่ถาวรและใช้ร่วมกันในทีม
ด้วย Apidog คุณสามารถ:
- บันทึก request เป็น collection แทนการค้นหาจาก shell history
- จัดการ environment เช่น local, staging, production ด้วยตัวแปร
- เพิ่ม assertions เพื่อตรวจ status code, response field หรือ schema
-
รัน test ใน CI ด้วย
apidog runสำหรับ scenario ที่บันทึกไว้ - แชร์กับทีม ผ่าน workspace เพื่อให้ทุกคนใช้ request เดียวกันได้
workflow ที่แนะนำ:
- ใช้ curlie เพื่อสำรวจ endpoint
- ปรับ method, header, query และ body จน request ถูกต้อง
- สร้าง request เดียวกันใน Apidog
- เพิ่ม assertions ที่ตรวจผลลัพธ์
- รวมเข้า collection หรือ test scenario
- รันซ้ำในทีม หรือรันใน CI
ถ้าทีมของคุณกำลังจัดระบบการทดสอบ API อ่านต่อได้ที่ คู่มือการทดสอบ API
คำถามที่พบบ่อย
curlie ใช้แทน curl ได้หรือไม่?
ไม่เชิง curlie ทำงานบน curl จึงเป็นเหมือน interface ที่เป็นมิตรกว่า ไม่ใช่การแทนที่ curl ทั้งหมด มันแปลง syntax ที่กระชับให้เป็นการเรียก curl และจัดรูปแบบ output ให้ดีขึ้น แต่ curl ยังคงเป็น engine หลัก
curlie ใช้ใน CI/CD pipelines ได้หรือไม่?
ใช้ได้ในเชิงเทคนิค เพราะเรียกจาก script ได้ แต่ไม่ใช่เครื่องมือที่ออกแบบมาสำหรับ test automation โดยตรง curlie ไม่มี saved scenarios, assertions หรือ structured reports
สำหรับ pipeline คุณควรใช้เครื่องมือที่ validate response และทำให้ build fail เมื่อผลลัพธ์ไม่ถูกต้อง เช่น apidog run ของ Apidog หรือเครื่องมือทดสอบ API อื่น ๆ ดูเพิ่มเติมได้ใน รายการไคลเอนต์ทดสอบ API ยอดนิยม
curlie แตกต่างจาก HTTPie อย่างไร?
ทั้งสองมี syntax และ output ที่คล้ายกัน เพราะ curlie ยืมแนวทางของ HTTPie มาใช้ ความต่างคือ engine:
- HTTPie เป็นเครื่องมือ Python แบบ standalone
- curlie เป็น Go wrapper ที่เรียก curl จริง
เลือก curlie ถ้าคุณต้องการใช้ curl behavior และ curl flags ต่อไป เลือก HTTPie ถ้าต้องการเครื่องมือ standalone ที่มี feature set ของตัวเอง
ดูคำสั่งหรือรายละเอียด request จริงได้หรือไม่?
ได้ ใช้ -v:
curlie -v GET httpbin.org/get
โหมด verbose ช่วยให้เห็น header และรายละเอียดการส่ง request เหมาะสำหรับ debug และเรียนรู้ว่า request จริงหน้าตาเป็นอย่างไร
บทสรุป
curlie เป็นเครื่องมือเล็ก ๆ ที่ช่วยให้การเรียก HTTP จากเทอร์มินัลอ่านง่ายขึ้นมาก คุณได้ syntax ที่กระชับและ output ที่สวยแบบ HTTPie โดยยังใช้ curl เป็น engine อยู่เบื้องหลัง
ใช้ curlie เมื่อคุณต้องการทดสอบ endpoint อย่างรวดเร็ว อ่าน JSON response หรือ debug authentication จากเทอร์มินัล แต่เมื่อ request ต้องถูกบันทึก แชร์ ตรวจสอบด้วย assertions หรือรันใน CI ให้ย้ายไปใช้ workflow ที่เหมาะกับงานนั้น
ดาวน์โหลด Apidog เพื่อเปลี่ยน endpoint ที่คุณสำรวจด้วย curlie ให้เป็น request ที่บันทึกไว้ environment ที่จัดการได้ และ automated tests ที่ทีมใช้งานร่วมกันได้ ใช้ curlie สำหรับงานเร็ว ๆ และให้ Apidog จัดการงานที่ต้องทำซ้ำ


Top comments (0)