เครื่องมือ CLI โอเพนซอร์สฟรี สำหรับนักพัฒนา

เวิร์กโฟลว์ของนักพัฒนาจำนวนมากยังคงเริ่มและจบที่เทอร์มินัล เครื่องมือ CLI ที่เหมาะกับงานระยะยาวควรตรวจสอบได้ โฮสต์เองได้ และไม่บังคับให้ล็อกอินหรือคุยกับฝ่ายขาย เมื่อเครื่องมือมีใบอนุญาตแบบ permissive หรือ copyleft พร้อมซอร์สโค้ดบน GitHub คุณสามารถตรวจสอบการบำรุงรักษา อ่านโค้ด และ fork โปรเจกต์ได้หากโครงการหยุดพัฒนา

ลองใช้ Apidog วันนี้

บทความนี้รวบรวม CLI โอเพนซอร์สฟรี 7 ตัวที่ใช้ได้จริงกับงาน พัฒนา API และแบ็กเอนด์ประจำวัน โดยเน้นเครื่องมือที่มีใบอนุญาตชัดเจน ใช้งานได้โดยไม่มีค่าใช้จ่าย และไม่บังคับให้พึ่งบริการที่เช่าใช้งาน

คุณจะได้ชุดเครื่องมือสำหรับงานหลักดังนี้:

• ส่งและดีบักคำขอ HTTP
• กรองและแปลง JSON
• ทดสอบ HTTP flow ใน CI
• ทำงานกับ GitHub API
• เปิด local server ให้เข้าถึงจากอินเทอร์เน็ต
• เก็บ API spec และชุดทดสอบไว้ใน version control

เกณฑ์เลือกเครื่องมือ CLI แบบโอเพนซอร์ส

คำว่า “ดาวน์โหลดฟรี” ไม่ได้แปลว่าโอเพนซอร์สเสมอไป บางเครื่องมือปิดซอร์สโค้ด หรือเปิดเฉพาะส่วนหลักแต่ล็อกความสามารถสำคัญไว้ในแพ็กเกจแบบเสียเงิน

รายการนี้ใช้เกณฑ์ 3 ข้อ:

1. มีใบอนุญาตที่ OSI รับรอง
   
   เช่น MIT, Apache 2.0, BSD หรือ GPL เพื่อให้ใช้งานเชิงพาณิชย์ โฮสต์เอง และ fork ได้ตามเงื่อนไขใบอนุญาต

2. มีซอร์สโค้ดบน GitHub หรือแพลตฟอร์มเทียบเท่า
   
   คุณควรอ่านโค้ด ตรวจสอบ issue ดูประวัติ commit และประเมินความต่อเนื่องของการดูแลโปรเจกต์ได้

3. ไม่บังคับให้ล็อกอินเพื่อใช้งานหลัก
   
   เครื่องมือควรรันได้โดยไม่ต้องมีบัญชี ไม่มี telemetry ที่ปิดไม่ได้ และไม่บังคับให้เช่าบริการส่วนกลาง

ก่อนนำเครื่องมือไปใช้เป็นมาตรฐานทีม ให้ตรวจสอบไฟล์ LICENSE ใน repo เสมอ โดยเฉพาะหากงานมีข้อกำหนดด้านการใช้งานเชิงพาณิชย์หรือการแจกจ่ายซอฟต์แวร์

1. curl: ไคลเอนต์ HTTP มาตรฐานสำหรับสคริปต์

curl คือฐานของงาน HTTP บนเทอร์มินัล รองรับหลายโปรโตคอล ติดตั้งมากับระบบปฏิบัติการส่วนใหญ่ และได้รับการบำรุงรักษาอย่างต่อเนื่องตั้งแต่ปี 1996 ซอร์สโค้ดอยู่ที่ github.com/curl/curl

ใช้ curl เมื่อคุณต้องการคำสั่งที่พกพาได้และเหมาะกับ shell script หรือ CI job

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue","body":"Filed from curl"}'

แนวทางใช้งานจริง:

• ใส่ -s เพื่อลด progress output ในสคริปต์
• ส่ง token ผ่าน environment variable เช่น $TOKEN แทนการ hardcode
• ใช้ -H "Content-Type: application/json" เมื่อส่ง JSON body
• เพิ่ม --fail-with-body ใน CI หากต้องการให้คำขอล้มเหลวเมื่อได้ HTTP 4xx/5xx

เหมาะสำหรับ: สคริปต์ที่ต้องรันได้แทบทุก environment

ข้อจำกัด: เอาต์พุตดิบ อ่าน JSON ยาก และต้องพึ่งเครื่องมืออื่นเมื่อต้องกรองข้อมูล

2. HTTPie: ส่ง HTTP request แบบอ่านง่าย

HTTPie เป็น HTTP client แบบ CLI ที่ออกแบบให้คำสั่งอ่านง่ายกว่า curl รองรับ JSON โดยค่าเริ่มต้น และจัดรูปแบบ response ให้พร้อมอ่าน ซอร์สโค้ดอยู่ที่ github.com/httpie/cli

ติดตั้งด้วย pip:

pip install httpie

ส่ง JSON request โดยไม่ต้องเขียน header และ body เอง:

http POST httpbin.org/post name=apidog role=platform

name=apidog และ role=platform จะถูกแปลงเป็น JSON field โดยอัตโนมัติ เหมาะกับการทดลอง endpoint หรือดีบัก request ระหว่างพัฒนา

ตัวอย่างส่ง Authorization header:

http GET https://api.github.com/user \
  Authorization:"Bearer $TOKEN"

เหมาะสำหรับ: สำรวจ API และดีบักแบบ interactive

ข้อจำกัด: เป็นแพ็กเกจ Python ซึ่งอาจไม่เหมาะกับ container หรือ CI image ที่ต้องการ footprint ต่ำที่สุด

3. jq: กรองและแปลง JSON ใน pipeline

API ส่วนใหญ่ตอบกลับเป็น JSON และ jq คือเครื่องมือสำหรับดึง แปลง และจัดรูปร่างข้อมูล JSON จากบรรทัดคำสั่ง ซอร์สโค้ดอยู่ที่ github.com/jqlang/jq

ใช้ร่วมกับ curl ได้โดยตรง:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'

คำสั่งนี้แปลง response ขนาดใหญ่ให้เหลือเฉพาะข้อมูลที่สคริปต์ต้องใช้:

{
  "name": "jq",
  "stars": 0,
  "license": "MIT"
}

ตัวอย่างที่ใช้บ่อย:

# ดึงค่า field เดียว
jq -r '.token'

# เลือกเฉพาะรายการที่ตรงเงื่อนไข
jq '.items[] | select(.status == "active")'

# แปลง array เป็น CSV
jq -r '.users[] | [.id, .email] | @csv'

เหมาะสำหรับ: เชื่อม API response เข้ากับ shell pipeline และ CI

ข้อจำกัด: ไวยากรณ์กระชับมาก การแปลงที่ซับซ้อนอาจต้องใช้เวลาเรียนรู้

4. gh: GitHub CLI สำหรับ repo, PR และ API

gh นำงาน GitHub มาไว้ในเทอร์มินัล ทั้ง pull request, issue, release, Actions และ GitHub API ซอร์สโค้ดอยู่ที่ github.com/cli/cli

คำสั่ง gh api มีประโยชน์มากเมื่อคุณต้องเรียก GitHub REST หรือ GraphQL API เพราะจัดการ authentication ให้แล้ว:

gh api repos/cli/cli/releases --jq '.[0].tag_name'

ผลลัพธ์คือ tag ของ release ล่าสุด โดยใช้ตัวกรอง jq ที่มีอยู่ใน gh

ตัวอย่าง workflow ที่ใช้งานได้ทันที:

# สร้าง issue
gh issue create \
  --title "API regression" \
  --body "Endpoint /health returned 500"

# ดูสถานะ workflow ล่าสุด
gh run list --limit 5

# เรียก GitHub API พร้อม query parameter
gh api repos/OWNER/REPO/issues -f state=open

เหมาะสำหรับ: automation ที่ทำงานกับ GitHub repository และ GitHub Actions

ข้อจำกัด: รองรับ GitHub โดยเฉพาะ หากใช้ GitLab หรือ Gitea ให้ใช้ CLI ของแพลตฟอร์มนั้นหรือเรียก API ด้วย curl

5. Hurl: เขียน HTTP test เป็นไฟล์ที่ commit ได้

Hurl ช่วยให้คุณกำหนด HTTP request และ assertion ในไฟล์ข้อความธรรมดา แล้วรันในเครื่องหรือ CI ได้ ซอร์สโค้ดอยู่ที่ github.com/Orange-OpenSource/hurl

สร้างไฟล์ repo.hurl:

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000

รันทดสอบ:

hurl --test repo.hurl

Hurl จะคืน exit code 0 เมื่อ assertion ผ่านทั้งหมด และคืนค่าที่ไม่ใช่ศูนย์เมื่อมีการทดสอบล้มเหลว จึงใส่ใน CI ได้โดยตรง

ตัวอย่าง GitHub Actions step:

- name: Run API tests
  run: hurl --test tests/*.hurl

เหมาะสำหรับ: integration test ของ HTTP API ที่อ่านง่าย ตรวจสอบใน code review ได้ และเก็บใน Git ได้

ข้อจำกัด: เป็นเครื่องมือสำหรับ request/response testing ไม่ใช่เครื่องมือ contract testing หรือ load testing แบบเต็มรูปแบบ

หากทีมใช้ OpenAPI เป็นแหล่งข้อมูลหลัก ไฟล์ Hurl สามารถทำหน้าที่เป็นชั้นทดสอบที่เสริม workflow ของ การพัฒนา API แบบ spec-first ได้

6. cloudflared: เปิด local server ด้วย public URL

เมื่อต้องทดสอบ webhook, mobile app หรือเดโม API คุณมักต้องเปิด server บนเครื่องให้เข้าถึงผ่าน URL สาธารณะ cloudflared มี quick tunnel ที่สร้าง URL ชั่วคราว *.trycloudflare.com ได้โดยไม่ต้องมีบัญชี ซอร์สโค้ดอยู่ที่ github.com/cloudflare/cloudflared

รัน local server ของคุณก่อน เช่นที่พอร์ต 3000 จากนั้นเปิด tunnel:

cloudflared tunnel --url http://localhost:3000

คำสั่งจะพิมพ์ HTTPS URL สาธารณะที่ forward ไปยัง localhost:3000 ตราบใดที่ process ยังทำงานอยู่

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

1. รัน API ในเครื่องที่ http://localhost:3000
2. รัน cloudflared tunnel --url http://localhost:3000
3. คัดลอก URL ที่ได้ไปตั้งค่า webhook callback
4. ดู request ที่เข้ามาจาก log ของ local server

หากต้องการตัวเลือกใน ecosystem ของ npm ใช้ localtunnel ซึ่งใช้ใบอนุญาต MIT ได้เช่นกัน:

npx localtunnel --port 3000

เหมาะสำหรับ: แชร์ local endpoint ชั่วคราวเพื่อทดสอบหรือเดโม

ข้อจำกัด: quick tunnel ใช้ URL แบบสุ่มและชั่วคราว หากต้องการชื่อ tunnel ที่คงที่ ต้องตั้งค่า Cloudflare account และ configuration เพิ่มเติม

7. git: เก็บ API spec และ API test ไว้ใน version control

git คือพื้นฐานของ workflow ทั้งหมด ไม่ว่าจะเป็น OpenAPI specification, collection, Hurl test หรือ shell script ควรอยู่ใน repository เดียวกันเพื่อให้ review, rollback และ trace การเปลี่ยนแปลงได้ ซอร์สโค้ดอยู่ที่ github.com/git/git

ตัวอย่าง: สร้าง pre-commit hook ที่รัน Hurl test ก่อน commit

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

เมื่อมีคนรัน git commit hook นี้จะรันชุดทดสอบก่อน หาก Hurl คืนค่าไม่ใช่ศูนย์ commit จะไม่ถูกสร้าง

สำหรับโปรเจกต์จริง ควรเก็บ hook เป็นสคริปต์ใน repository แทนการเขียนลง .git/hooks โดยตรง เช่น:

#!/usr/bin/env bash
set -euo pipefail

hurl --test tests/*.hurl

จากนั้นให้เครื่องมือจัดการ hook ของทีมเรียกสคริปต์นี้

เหมาะสำหรับ: เก็บ spec, test และ automation ไว้ในประวัติการเปลี่ยนแปลงเดียวกัน

ข้อจำกัด: Git เป็น version control system ไม่ใช่แพลตฟอร์มโฮสต์โครงการ การเลือก GitHub, GitLab หรือ Gitea เป็นการตัดสินใจอีกชั้นหนึ่ง

ข้อสังเกตอย่างตรงไปตรงมา: Apidog อยู่ตรงไหน

Apidog ไม่ใช่โอเพนซอร์ส จึงไม่ควรถูกจัดเป็นเครื่องมือ OSS ในรายการนี้ เป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีเวอร์ชันฟรี

ชุดเครื่องมือข้างต้นมีความยืดหยุ่นสูง แต่คุณต้องประกอบ workflow เอง:

• curl หรือ HTTPie สำหรับส่ง request
• jq สำหรับแปลง JSON
• Hurl สำหรับทดสอบ
• เครื่องมือแยกสำหรับ mock server และเอกสาร
• environment variables และ shell profile สำหรับจัดการค่า config

Apidog รวมการออกแบบ การทดสอบ การจำลอง และเอกสารไว้ใน workspace เดียว ขณะที่ apidog-cli นำความสามารถเหล่านั้นมาสู่เทอร์มินัล

ติดตั้ง CLI:

npm install -g apidog-cli

ตามเอกสารที่อ้างอิงไว้ CLI สามารถรันสถานการณ์ทดสอบ จัดการ endpoint และ schema สร้าง mock expectation รวมถึงนำเข้าและส่งออก OpenAPI โดยมี JSON output ที่สคริปต์และ AI agent อ่านต่อได้

เช่นเดียวกับ Hurl คำสั่ง apidog run จะคืนค่า 0 เมื่อสำเร็จ และคืนค่าที่ไม่ใช่ศูนย์เมื่อล้มเหลว จึงใช้ใน CI ได้

หากคุณต้องการไม่ล็อกอินและต้องเข้าถึงซอร์สโค้ดเต็มรูปแบบ ชุดเครื่องมือโอเพนซอร์สในบทความนี้คือทางเลือกที่เหมาะสมกว่า แต่หากไม่ต้องการดูแลการเชื่อมต่อระหว่างหลายเครื่องมือ Apidog เวอร์ชันฟรีและ CLI เป็นทางเลือกแบบรวมศูนย์

สำหรับการเริ่มต้นใช้งาน CLI ดูคู่มือการติดตั้ง

วิธีเลือกและจัดชุดเครื่องมือ

นักพัฒนาส่วนใหญ่ไม่จำเป็นต้องเลือกเพียงตัวเดียว แต่ควรใช้ร่วมกันตามหน้าที่:

curl หรือ HTTPie  -> ส่ง request
jq                -> กรอง response JSON
Hurl              -> ทดสอบ API flow
git               -> เก็บ spec และ test
cloudflared       -> รับ webhook เข้า local server
gh                -> ทำ automation บน GitHub

เครื่องมือ	ดีที่สุดสำหรับ	ติดตั้ง	โอเพนซอร์ส?	หมายเหตุ
curl	ส่ง request แบบพกพา, shell script	มักติดตั้งมาแล้ว	ใช่ (curl/MIT-style)	ใช้ได้เกือบทุก environment
HTTPie	ดีบัก API แบบอ่านง่าย	pip install httpie	ใช่ (BSD-3-Clause)	JSON และสีใน terminal
jq	กรองและแปลง JSON	package manager / binary	ใช่ (MIT)	เชื่อม API response เข้ากับ script
gh	GitHub automation	package manager / binary	ใช่ (MIT)	ใช้กับ GitHub โดยเฉพาะ
Hurl	HTTP test ที่ commit ได้	binary เดียว	ใช่ (Apache 2.0)	เหมาะกับ CI
cloudflared	เปิด local server แบบสาธารณะ	binary เดียว	ใช่ (Apache 2.0)	Quick tunnel ไม่ต้องมีบัญชี
git	Version control	มักติดตั้งมาแล้ว	ใช่ (GPLv2)	เก็บ spec และ test
apidog-cli	Workflow API แบบรวมศูนย์	npm i -g apidog-cli	ไม่ใช่ (มีเวอร์ชันฟรี)	ออกแบบ + ทดสอบ + จำลอง + เอกสาร

กฎง่าย ๆ คือ:

• เลือกเครื่องมือโอเพนซอร์สแบบแยกหน้าที่ หากต้องการควบคุมทุกส่วนของระบบ
• เลือกแพลตฟอร์มรวมศูนย์ หากต้องการลดภาระการเชื่อมและดูแลหลายเครื่องมือ

หากกำลังเปรียบเทียบแนวทางแบบรวมศูนย์ ดูบทความ Apidog ในฐานะแพลตฟอร์มการพัฒนา API ที่ครอบคลุม

สรุป

เครื่องมือ CLI แบบโอเพนซอร์สมีคุณค่าเพราะตรวจสอบได้ โฮสต์เองได้ และไม่ผูกคุณกับผู้ให้บริการรายเดียว

เริ่มจากชุดเล็ก ๆ ที่ตอบโจทย์งานปัจจุบัน:

# ส่ง request และอ่านเฉพาะ field ที่ต้องการ
curl -s https://api.example.com/health | jq '.status'

# ทดสอบ API flow
hurl --test tests/health.hurl

# เก็บการเปลี่ยนแปลง
git add .
git commit -m "test: add health endpoint check"

เมื่อ workflow เติบโตขึ้น ค่อยเพิ่ม gh สำหรับ GitHub automation และ cloudflared สำหรับ webhook หรือการทดสอบจากภายนอก

หากคุณกำลังสร้าง workflow ที่ขับเคลื่อนด้วย agent เอาต์พุต JSON แบบมีโครงสร้างจะเป็นจุดเชื่อมสำคัญ อ่านเพิ่มเติมได้ในบทความ ผู้ช่วยเขียนโค้ด AI สำหรับการพัฒนา API

และหากการดูแลเครื่องมือแยกกันหลายตัวเริ่มเป็นภาระ สามารถดาวน์โหลด Apidog และลองใช้ Apidog CLI เพื่อประเมินแนวทางแบบรวมศูนย์ได้