วันทำงานส่วนใหญ่ของนักพัฒนาแบ็กเอนด์คือการวนลูปสั้น ๆ: ส่ง request ไปยัง endpoint, อ่าน JSON, ปรับโค้ด แล้วทำซ้ำ หากใช้ GUI ขนาดใหญ่กับงานเหล่านี้ เวลาส่วนหนึ่งจะหมดไปกับการเปิดแอปและสลับหน้าจอแทนที่จะเป็นการตรวจสอบ API จริง ๆ
CLI แบบ lightweight ช่วยลด friction ในลูปนี้ได้ เพราะมักเป็นไบนารีเดียวหรือแพ็กเกจที่เรียกผ่าน npx ได้ เริ่มเร็ว ใช้ใน shell script และ CI ได้ และต่อผลลัพธ์เข้ากับเครื่องมืออื่นผ่าน stdin/stdout ได้โดยตรง สำหรับงาน API และแบ็กเอนด์ เครื่องมือชุดเล็ก ๆ สามารถครอบคลุมการส่ง request, แยก JSON, เปิดพอร์ต local และรัน test suite ได้ครบ
บทความนี้รวบรวม CLI 10 ตัวที่ควรมีใน PATH ของนักพัฒนาแบ็กเอนด์ พร้อมคำสั่งเริ่มต้นที่นำไปลองได้ทันที หากต้องการภาพรวมของเวิร์กโฟลว์ที่กว้างขึ้น ดูคู่มือเรื่อง การพัฒนา API
อะไรทำให้ CLI เป็นเครื่องมือแบบ lightweight
คำว่า lightweight ไม่ได้หมายถึงมีฟีเจอร์น้อย แต่หมายถึงติดตั้งง่าย เริ่มเร็ว และให้ผลลัพธ์ได้โดยแทบไม่ต้องตั้งค่า ประเมินเครื่องมือจาก 4 ข้อนี้:
-
ขนาดและรูปแบบการติดตั้ง — ไบนารีแบบ static ไฟล์เดียว หรือแพ็กเกจ
npxขนาดเล็ก เหมาะกับงานเฉพาะหน้ามากกว่าเครื่องมือที่ต้องติดตั้ง runtime และ lockfile เพิ่ม - ความเร็วในการเริ่มทำงาน — คำสั่งควรเริ่มทำงานแทบจะทันที โดยเฉพาะเมื่อต้องเรียกซ้ำใน edit-run loop
- เวลาจากการติดตั้งสู่ผลลัพธ์แรก — ควรมี default ที่ใช้งานได้ทันทีโดยไม่ต้องสร้างโปรเจกต์ สมัครบัญชี หรือเปิด dashboard
- ความสามารถในการประกอบร่วมกัน — อ่านจาก stdin, เขียน stdout, และคืน exit code ที่ถูกต้อง เพื่อเชื่อมต่อกับ pipeline หรือเครื่องมืออื่นได้
เครื่องมือด้านล่างเรียงจากเครื่องมือเฉพาะทางขนาดเล็กไปยังเครื่องมือที่ครอบคลุมงานมากขึ้น โดย curl มักติดตั้งอยู่ในเครื่องอยู่แล้ว ส่วนที่เหลือติดตั้งได้ไม่ซับซ้อน
curl
curl คือ baseline สำหรับ HTTP client บน command line ใช้ตรวจ endpoint, ส่ง request ใน script และทำ health check ใน CI ได้ดี เพราะมีอยู่บนระบบส่วนใหญ่และควบคุมรายละเอียด request ได้ครบ
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"}'
สำหรับใช้ใน automation ให้เพิ่ม flag ตามงาน:
curl --fail --silent --show-error \
-w '\nHTTP %{http_code}\n' \
https://api.example.com/health
-
-sหรือ--silentซ่อน progress meter -
--show-errorแสดงข้อความผิดพลาดแม้ใช้--silent -
-iแสดง response headers -
-w '%{http_code}'พิมพ์ status code -
--failทำให้คำสั่งคืน exit code ที่ไม่ใช่ศูนย์เมื่อเจอ HTTP 4xx หรือ 5xx
เหมาะสำหรับ: shell script, health check ใน CI และ request ที่ต้องแชร์ให้ทุกคนรันได้เหมือนกัน
ข้อจำกัด: flag ค่อนข้างหนาแน่น และการเขียน JSON body ต้องจัดการเอง
HTTPie
HTTPie หรือคำสั่ง http ทำให้การส่ง HTTP request แบบโต้ตอบอ่านง่ายกว่า curl โดย JSON เป็นค่าเริ่มต้น และใช้ syntax แบบ key=value สำหรับสร้าง request body
http POST httpbin.org/post name=apidog role=api-tool active:=true
คำสั่งนี้ส่ง JSON ดังนี้:
{
"name": "apidog",
"role": "api-tool",
"active": true
}
ใช้ syntax หลักเหล่านี้:
# string
http POST api.example.com/users name=alice
# raw JSON value เช่น boolean, number, array
http POST api.example.com/users active:=true age:=24
# header
http GET api.example.com/users Authorization:"Bearer $TOKEN"
เหมาะสำหรับ: สำรวจ API แบบ manual ที่ต้องการ request และ response อ่านง่าย
ข้อจำกัด: เป็นแพ็กเกจ Python จึงต้องมี Python และโดยทั่วไปเริ่มช้ากว่าไบนารี native เล็กน้อย
xh
xh ใช้ syntax ใกล้เคียง HTTPie แต่เป็นไบนารี Rust เดี่ยว จึงเหมาะเมื่อคุณต้องการรูปแบบ request ที่อ่านง่ายและความเร็วในการเริ่มทำงานแบบ native นอกจากนี้ยังรองรับ HTTP/2 และ HTTP/3
xh POST httpbin.org/post name=apidog age:=24
ใช้ร่วมกับ script ได้โดยไม่ต้องพึ่ง Python:
TOKEN="$TOKEN" \
xh GET https://api.example.com/profile \
Authorization:"Bearer $TOKEN"
เนื่องจากเป็นไบนารีเดียว จึงเหมาะกับ container image หรือ CI environment ที่ต้องการลด dependency ดูไบนารีสำหรับ Linux, macOS และ Windows ได้จาก โปรเจกต์ xh บน GitHub
เหมาะสำหรับ: คนที่ชอบ syntax ของ HTTPie แต่ต้องการติดตั้งง่ายและเริ่มทำงานเร็ว
ข้อจำกัด: ไม่ได้ครอบคลุม plugin ecosystem ของ HTTPie ทั้งหมด แต่รองรับงาน request ทั่วไปได้ดี
jq
jq คือเครื่องมือหลักสำหรับกรองและแปลง JSON บน command line ใช้คู่กับ curl, xh หรือ gh เพื่อดึงเฉพาะข้อมูลที่ script ต้องใช้
curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'
ตัวอย่างที่ใช้บ่อย:
# ดึงชื่อจาก array
jq '.items[] | .name'
# กรองเฉพาะรายการที่ active
jq '.items[] | select(.active)'
# ส่งค่า string แบบไม่ใส่เครื่องหมายคำพูดไปยัง shell variable
API_URL=$(curl -s https://api.example.com/config | jq -r '.url')
เหมาะสำหรับ: ดึงฟิลด์, กรอง response และแปลง JSON ใน script หรือ CI
ข้อจำกัด: query ที่ซ้อนหลายระดับมีช่วงการเรียนรู้ แต่การอ่านฟิลด์พื้นฐานทำได้ตรงไปตรงมา
gh (GitHub CLI)
gh นำ GitHub API มาไว้ใน terminal โดยจัดการ authentication ผ่าน gh auth login เพียงครั้งเดียว จากนั้นใช้สร้าง PR, ดู CI, สร้าง release หรือเรียก GitHub API ได้โดยไม่ต้องเขียน curl และจัดการ token เอง
gh pr create --title "Add rate limiting" --body "Closes #42" --base main
คำสั่งที่ควรใช้ในงานประจำ:
# ดูสถานะ CI ของ PR ปัจจุบัน
gh pr checks
# ติดตาม GitHub Actions workflow แบบ real-time
gh run watch
# เรียก GitHub API โดยใช้ authentication ที่ gh จัดการให้
gh api repos/OWNER/REPO/issues
เหมาะสำหรับ: automation บน GitHub เช่น สร้าง PR จาก CI, สร้าง release และตรวจ workflow
ข้อจำกัด: ใช้ได้เฉพาะ GitHub ไม่ครอบคลุม GitLab หรือ Bitbucket
ngrok
ngrok เปิดพอร์ต local ให้เข้าถึงผ่าน public URL ที่ปลอดภัย เหมาะสำหรับทดสอบ webhook, OAuth callback หรือให้เพื่อนร่วมทีมเปิด dev server ที่รันอยู่บนเครื่องคุณ
ngrok http 8080
หลังรันคำสั่ง คุณจะได้ public https:// URL ที่ forward traffic ไปยัง localhost:8080 และสามารถตรวจ request ที่เข้ามาได้ที่:
http://127.0.0.1:4040
ใช้ traffic inspector เพื่อดู headers, body และ replay request ได้ โดยเฉพาะเมื่อกำลัง debug webhook จาก payment provider หรือ Git provider
เหมาะสำหรับ: webhook development, third-party callback และการแชร์ local server
ข้อจำกัด: เป็นบริการเชิงพาณิชย์ที่มี free plan ซึ่ง URL อาจเปลี่ยนในแต่ละ session และมีข้อจำกัดการใช้งาน
mkcert
mkcert สร้าง certificate HTTPS ที่เบราว์เซอร์เชื่อถือได้สำหรับ local development โดยไม่ต้องเขียนคำสั่ง OpenSSL ที่ซับซ้อน เหมาะเมื่อต้องทดสอบ secure cookies, OAuth redirect หรือฟีเจอร์ที่ทำงานต่างกันระหว่าง HTTP และ HTTPS
mkcert -install
mkcert localhost 127.0.0.1 myapp.local
ขั้นตอนใช้งาน:
- รัน
mkcert -installหนึ่งครั้งเพื่อสร้างและติดตั้ง local CA ลงใน trust store - ออก certificate สำหรับ hostname ที่ต้องการ
- นำไฟล์ certificate และ key ที่สร้างได้ไปตั้งค่าใน dev server หรือ reverse proxy
ตัวอย่างชื่อไฟล์ที่ได้จะมีลักษณะคล้าย:
localhost+2.pem
localhost+2-key.pem
เหมาะสำหรับ: รัน local HTTPS ที่ trusted และใกล้เคียง production
ข้อจำกัด: ใช้สำหรับ development เท่านั้น ห้ามนำ certificate หรือ Root CA ของ mkcert ไปใช้ใน production และควรปกป้อง Root CA key ให้ดี
watchexec
watchexec เฝ้าดูการเปลี่ยนแปลงไฟล์ แล้วรันคำสั่งซ้ำอัตโนมัติ ช่วยให้ edit-run loop สั้นลงโดยไม่ต้องใช้ watch mode เฉพาะของแต่ละ framework
watchexec -e py -r 'pytest tests/'
ตัวอย่างตาม stack:
# restart Go server เมื่อไฟล์เปลี่ยน
watchexec -r 'go run .'
# รัน JavaScript test suite ใหม่เมื่อมีไฟล์เปลี่ยน
watchexec 'npm test'
-
-e pyกรองให้เฝ้าดูเฉพาะไฟล์ Python -
-rrestart process เดิม แทนการปล่อย process เก่าค้างไว้ - โดย default จะเคารพ
.gitignoreจึงไม่ต้อง trigger จาก build artifacts โดยไม่จำเป็น
เหมาะสำหรับ: รัน server หรือ test suite ซ้ำทุกครั้งที่บันทึกไฟล์
ข้อจำกัด: ไม่มี hot-module reload และไม่รักษา state ภายใน process
Docker CLI
Docker CLI เป็นเครื่องมือที่หนักที่สุดในรายการ แต่มีประโยชน์มากเมื่อ local development ต้องใช้ Postgres, Redis หรือ backing service อื่น ๆ โดยไม่ต้องติดตั้ง service เหล่านั้นลงบนระบบโดยตรง
docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16
แอปของคุณเชื่อมต่อได้ที่:
localhost:5432
ความหมายของ flag หลัก:
-
--rmลบ container เมื่อหยุดทำงาน -
-eกำหนด environment variable -
-p 5432:5432map พอร์ตจาก container มายังเครื่อง host
สลับ image เพื่อเปิด service อื่นได้ทันที:
docker run --rm -p 6379:6379 redis:7
เหมาะสำหรับ: local backing services และ integration test ที่ต้องการ environment ทำซ้ำได้
ข้อจำกัด: ต้องมี Docker daemon, พื้นที่ดิสก์ และหน่วยความจำ จึงไม่ lightweight ในระดับ runtime แต่ CLI ใช้ใน script ได้ดี
apidog-cli
งาน API บน command line มักไม่ได้มีแค่การส่ง request แต่รวมถึง endpoint, schema, environment และ test scenario ของโปรเจกต์ด้วย Apidog มี apidog-cli สำหรับเชื่อม terminal เข้ากับทรัพยากรเหล่านี้ ติดตั้งผ่าน npm และใช้รัน test scenario หรือจัดการทรัพยากร API โดยไม่ต้องเปิดแอปเดสก์ท็อป
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli
apidog run จะรัน scenario ที่บันทึกไว้กับ environment ที่ระบุ และแสดงผลของแต่ละขั้นตอนใน terminal เหมาะกับการใช้เป็น CI gate เพราะคืน exit code 0 เมื่อ assertion ผ่านทั้งหมด และคืน non-zero เมื่อมีความล้มเหลว
นอกจากการทดสอบ CLI ยังมีชุดคำสั่งสำหรับจัดการโปรเจกต์ เช่น:
# จัดการ API endpoint และ schema
apidog endpoint
apidog schema
# import/export API specification
apidog import
apidog export
# จัดการ mock, environment และ variables
apidog mock
apidog environment
apidog variables
เอาต์พุตเป็น JSON แบบมีโครงสร้าง และมี agentHints.nextSteps ซึ่งช่วยให้เหมาะกับ AI coding assistants ที่ทำงานด้านการพัฒนา API ดูรายละเอียดคำสั่งได้จากคู่มือ Apidog CLI ฉบับสมบูรณ์ และเริ่มต้นติดตั้งตาม คู่มือการติดตั้ง Apidog CLI
เหมาะสำหรับ: รัน API test scenarios ใน CI และจัดการทรัพยากร API จาก script โดยเฉพาะเวิร์กโฟลว์ การพัฒนา API แบบ spec-first
ข้อควรทราบ: Apidog ไม่ใช่โอเพนซอร์สและเป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีแผนฟรี ส่วนที่ lightweight คือ apidog-cli ขณะที่แพลตฟอร์ม Apidog เต็มรูปแบบ เป็น GUI ที่ทำงานกับโปรเจกต์เดียวกัน
วิธีเลือก
เครื่องมือเหล่านี้ส่วนใหญ่ใช้ร่วมกันได้ ไม่ได้เป็นคู่แข่งกันโดยตรง ตัวอย่าง workflow ทั่วไปคือใช้ HTTP client ส่ง request, ใช้ jq อ่าน response, ใช้ tunnel รับ webhook, ใช้ watcher รัน test ซ้ำ และใช้ Docker เปิด dependency ในเครื่อง
| เครื่องมือ | เหมาะสำหรับ | การติดตั้ง | โอเพนซอร์ส? |
|---|---|---|---|
| curl | คำขอใน script, การตรวจสถานะ CI | ติดตั้งมาแล้ว | ใช่ (ใบอนุญาต curl) |
| HTTPie | คำขอแบบโต้ตอบที่อ่านง่าย | pip install httpie |
ใช่ (BSD) |
| xh | syntax แบบ HTTPie, ความเร็ว native |
cargo install xh / binary |
ใช่ (MIT) |
| jq | กรอง JSON response |
brew install jq / binary |
ใช่ (MIT) |
| gh | เขียน script สำหรับ GitHub PR และ CI |
brew install gh / binary |
ใช่ (MIT) |
| ngrok | เปิดเผย localhost, ทดสอบ webhook | ดาวน์โหลดไบนารี | ไม่ (freemium) |
| mkcert | certificate HTTPS ที่เชื่อถือได้ในเครื่อง |
brew install mkcert / binary |
ใช่ (BSD) |
| watchexec | รันซ้ำเมื่อไฟล์เปลี่ยน | cargo install watchexec-cli |
ใช่ (Apache-2.0) |
| Docker CLI | backing services แบบใช้แล้วทิ้ง | ติดตั้ง Docker | ใช่ (Apache-2.0) |
| apidog-cli | รัน test scenario, จัดการโปรเจกต์ API | npm install -g apidog-cli |
ไม่ (freemium) |
เลือกตามงาน:
- ส่ง request แบบโต้ตอบ:
xhหรือ HTTPie - ส่ง request ใน script หรือ CI:
curl - อ่านและแปลง JSON:
jq - เปิด local port ให้เข้าถึงจากภายนอก:
ngrok - ใช้ HTTPS ที่ trusted ในเครื่อง:
mkcert - รันคำสั่งซ้ำเมื่อบันทึกไฟล์:
watchexec - เปิด Postgres, Redis หรือ service อื่นแบบชั่วคราว: Docker
- รัน API tests และจัดการ API project:
apidog-cli
สรุป
ชุดเครื่องมือ lightweight ที่ดีคือเครื่องมือขนาดเล็กหลายตัว ซึ่งแต่ละตัวทำหน้าที่ชัดเจนและต่อกันเป็น workflow ได้:
curl -s https://api.example.com/users \
| jq -r '.items[] | .email'
curl และ xh ส่ง request, jq อ่าน JSON, ngrok และ mkcert จัดการ local access, watchexec ลดเวลาระหว่างการแก้และรัน, ส่วน Docker ให้ infrastructure แบบใช้แล้วทิ้ง
apidog-cli เชื่อม workflow บน terminal กลับไปยังโปรเจกต์ API จริงของทีม เพื่อให้ endpoint และ test scenario ที่รันใน CI สอดคล้องกับสิ่งที่ออกแบบและจัดส่ง ดูรายละเอียดเพิ่มเติมหรือเริ่มต้นโปรเจกต์ได้ที่ ดาวน์โหลด Apidog แล้วใช้ CLI ขับเคลื่อนการทดสอบใน CI pipeline ของคุณ
Top comments (0)