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

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

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

คุณจะได้รับเครื่องมือเจ็ดชิ้นสำหรับกระบวนการหลัก: การสร้างคำขอ, การแยกวิเคราะห์ JSON, การทดสอบ HTTP flow, การทำงานกับ GitHub และการเปิดเผยเซิร์ฟเวอร์ภายในเครื่องออกสู่อินเทอร์เน็ต เครื่องมือแต่ละรายการจะระบุใบอนุญาต, ลิงก์ไปยัง repo และแสดงคำสั่งจริงหนึ่งคำสั่งเพื่อให้คุณเห็นการทำงาน นอกจากนี้ยังมีข้อสังเกตตรงไปตรงมาว่าเครื่องมือเชิงพาณิชย์แบบฟรีเทียร์เหมาะสมกับจุดใด โดยมีการระบุไว้อย่างชัดเจน เพื่อที่คุณจะได้ไม่เข้าใจผิดว่าเป็นเครื่องมือโอเพนซอร์ส

อะไรที่ทำให้เครื่องมือ CLI เป็น “โอเพนซอร์ส” สำหรับการพัฒนา

เครื่องมือหลายอย่างสามารถดาวน์โหลดได้ฟรีแต่มีซอร์สโค้ดปิด หรือโอเพนซอร์สในส่วนหลักแต่ส่วนที่มีประโยชน์ถูกจำกัดไว้หลังกำแพงการจ่ายเงิน สำหรับรายการนี้ เครื่องมือจะเข้าเกณฑ์ตามสามข้อตรวจสอบ:

• ใบอนุญาต มาพร้อมใบอนุญาตที่ได้รับการรับรองจาก OSI: MIT, Apache 2.0, BSD หรือ GPL ซึ่งทำให้คุณสามารถใช้งานในเชิงพาณิชย์ โฮสต์ด้วยตนเอง และ fork ได้โดยไม่ต้องขออนุญาต
• ซอร์สโค้ดบน GitHub (หรือเทียบเท่า) คุณสามารถอ่านโค้ดได้ทุกบรรทัด รายงานปัญหา และตัดสินการบำรุงรักษาจากประวัติการคอมมิตและรอบการออกเวอร์ชัน
• ไม่มีการล็อกอิน ไม่ต้องมีบัญชีบังคับ, ไม่มี telemetry ที่ไม่สามารถปิดได้, ไม่มีส่วนประกอบเซิร์ฟเวอร์ที่คุณถูกบังคับให้เช่า หากมันรันบริการ คุณสามารถรันบริการนั้นได้ด้วยตัวเอง

จำนวนดาวและการคอมมิตล่าสุดก็มีความสำคัญเช่นกัน แต่เป็นรอง เครื่องมือ MIT ที่เสถียรและเงียบสงบดีกว่าเครื่องมือยอดนิยมที่มีใบอนุญาต source-available ที่จำกัดการใช้งานเชิงพาณิชย์ ตรวจสอบไฟล์ LICENSE ก่อนที่คุณจะนำสิ่งใดมาเป็นมาตรฐาน

curl: ไคลเอนต์ HTTP สากล

curl คือเครื่องมือที่เกือบทุกเครื่องมือ HTTP อื่นๆ ใช้เป็นมาตรฐาน มันรองรับโปรโตคอลมากมาย ถูกติดตั้งมาพร้อมกับ OS เกือบทุกตัว และได้รับการบำรุงรักษาอย่างต่อเนื่องมาตั้งแต่ปี 1996 มันได้รับใบอนุญาตภายใต้ ใบอนุญาต curl (ซึ่งเป็นอนุพันธ์ของ MIT/X) และซอร์สโค้ดอยู่ที่ github.com/curl/curl

สำหรับงาน API, curl คือเครื่องมือส่งคำขอพื้นฐานที่สุดของคุณ มันถูกติดตั้งไว้แล้ว ดังนั้นสคริปต์หรือ 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"}'

ดีที่สุดสำหรับ: การพกพาและการเขียนสคริปต์ หากมีเชลล์ ก็รัน curl ได้ ข้อจำกัดที่แท้จริงคือความสะดวกในการใช้งาน เอาต์พุตของ curl แบบดิบๆ นั้นหนาแน่น การจัดการเฮดเดอร์ก็ซับซ้อน และการอ่านเนื้อหา JSON หมายถึงการต้องส่งต่อไปยังที่อื่น นั่นคือเหตุผลที่เครื่องมือสองตัวถัดไปมีอยู่

HTTPie: curl ที่มีเอาต์พุตที่เป็นมิตรกับผู้ใช้

HTTPie เป็นไคลเอนต์ HTTP สมัยใหม่ที่สร้างขึ้นสำหรับผู้คน ไม่ใช่แค่สคริปต์ คำขออ่านได้เหมือนภาษาอังกฤษทั่วไป JSON เป็นประเภทเนื้อหาเริ่มต้น และการตอบกลับจะมาพร้อมสีและจัดรูปแบบ มันได้รับอนุญาตภายใต้ BSD-3-Clause และเป็นโอเพนซอร์สที่ github.com/httpie/cli

ติดตั้งด้วย pip แล้วใช้คำสั่ง http:

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

นั่นคือคำขอทั้งหมด name=apidog กลายเป็นฟิลด์ JSON โดยอัตโนมัติ เฮดเดอร์และสถานะจะแสดงพร้อมสี และเนื้อหาจะถูกจัดรูปแบบอย่างสวยงามโดยไม่ต้องใช้เครื่องมืออื่น ดีที่สุดสำหรับ: การสำรวจแบบโต้ตอบและการดีบักด้วยตนเอง ข้อจำกัดที่แท้จริงคือมันเป็นแพ็คเกจ Python ซึ่งทำให้การติดตั้งหนักกว่าไบนารีเดี่ยว และในอิมเมจ CI ที่จำกัด คุณอาจยังคงต้องใช้ curl

jq: ตัวประมวลผล JSON ที่ทุกไปป์ไลน์ต้องการ

API คืนค่า JSON และ jq คือวิธีที่คุณจะตัดแบ่งมันจากบรรทัดคำสั่ง มันกรอง ปรับรูปร่าง และแยกฟิลด์ด้วยภาษาคิวรีขนาดเล็ก และมันทำงานร่วมกับ curl หรือ HTTPie ในไปป์ได้อย่างสะอาดตา jq ได้รับ ใบอนุญาต MIT และดูแลโดยชุมชนที่ github.com/jqlang/jq

ส่งเอาต์พุต API ตรงไปยังมัน:

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

สิ่งนี้ดึงสามฟิลด์ออกจากผลตอบกลับขนาดใหญ่และสร้างออบเจกต์ที่สะอาดตา ดีที่สุดสำหรับ: การแปลง JSON ที่มีข้อมูลมากเกินไปให้เป็นรูปร่างที่คุณต้องการสำหรับขั้นตอนถัดไปในสคริปต์ ข้อจำกัดที่แท้จริงคือความชันในการเรียนรู้ ไวยากรณ์ของ jq นั้นทรงพลังแต่กระชับ และการแปลงที่ซับซ้อนอาจดูเป็นปริศนาได้อย่างรวดเร็ว อย่างไรก็ตาม สำหรับการแยกฟิลด์ในชีวิตประจำวัน คุณจะเรียนรู้ 90% ของสิ่งที่คุณต้องการในหนึ่งบ่าย

gh: GitHub CLI

gh นำ GitHub มาสู่เทอร์มินัลของคุณ: pull requests, issues, releases, Actions runs และการเรียก API ทั้งหมดโดยไม่ต้องเปิดเบราว์เซอร์ มันถูกเขียนด้วย Go, ได้รับใบอนุญาต MIT และอยู่ที่ github.com/cli/cli เนื่องจากงาน API และแบ็กเอนด์จำนวนมากอยู่บน GitHub repos จึงเป็นส่วนสำคัญของชุดเครื่องมือหลัก

เคล็ดลับที่มีประโยชน์อย่างหนึ่ง: gh api ให้คุณมี wrapper ที่ได้รับการรับรองความถูกต้องและมีการแบ่งหน้าเหนือ GitHub REST และ GraphQL APIs ดังนั้นคุณจึงไม่ต้องสร้างโทเค็นเองใน curl

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

นั่นจะพิมพ์แท็กเวอร์ชันล่าสุดโดยใช้ตัวกรอง jq ในตัวของ gh ดีที่สุดสำหรับ: การเขียนสคริปต์ GitHub ด้วยตัวเอง ตั้งแต่เวิร์กโฟลว์ CI ไปจนถึงการทำงานอัตโนมัติในการเผยแพร่ ข้อจำกัดที่แท้จริงคือขอบเขต มันออกแบบมาสำหรับ GitHub เท่านั้น สำหรับ GitLab หรือ Gitea คุณจะต้องใช้ CLI ของพวกมัน หรือ curl ธรรมดากับ API ของพวกมัน

Hurl: การทดสอบ HTTP แบบข้อความธรรมดาที่คุณสามารถคอมมิตได้

Hurl รันและทดสอบคำขอ HTTP ที่กำหนดไว้ในไฟล์ข้อความธรรมดาที่เรียบง่าย คุณเขียนคำขอ, ยืนยันสถานะโค้ด, เฮดเดอร์ และเนื้อหา JSON และเชื่อมโยงการเรียกโดยการจับค่าจากการตอบกลับหนึ่งไปยังอีกอันหนึ่ง มันเปลี่ยน "ทดสอบ API" ให้กลายเป็นไฟล์ที่คุณตรวจสอบเข้าสู่ git Hurl ถูกเขียนด้วย Rust, ได้รับใบอนุญาต Apache 2.0 และดูแลโดย Orange ที่ github.com/Orange-OpenSource/hurl

เขียนไฟล์ .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 จะออกค่า 0 เมื่อทุกการยืนยันผ่าน และค่าที่ไม่ใช่ 0 เมื่อมีบางอย่างล้มเหลว ซึ่งทำให้มันสามารถนำไปใช้ใน CI ได้ทันที ดีที่สุดสำหรับ: การทดสอบการผสานรวมที่อ่านง่ายและมีการควบคุมเวอร์ชัน ซึ่งทั้งทีมสามารถแก้ไขได้โดยไม่ต้องเรียนรู้เฟรมเวิร์ก ข้อจำกัดที่แท้จริงคือมันมุ่งเน้นไปที่การทดสอบคำขอ/การตอบกลับ HTTP; ไม่ใช่เครื่องมือทดสอบสัญญาหรือทดสอบโหลดที่สมบูรณ์ สำหรับภาพรวมที่กว้างขึ้นว่าการทดสอบ CLI เข้ากับเวิร์กโฟลว์ การพัฒนา API แบบ spec-first ได้อย่างไร ไฟล์ยืนยันทำงานได้ดีกับ OpenAPI ซึ่งเป็นแหล่งข้อมูลความจริง

cloudflared: เปิดเผยเซิร์ฟเวอร์ภายในเครื่องโดยไม่ต้องใช้ tunnel แบบมีค่าใช้จ่าย

บางครั้งคุณก็ต้องการ URL สาธารณะสำหรับ API ที่รันอยู่บนแล็ปท็อปของคุณ: การเรียกกลับของ webhook, การสาธิต, การทดสอบมือถือกับโฮสต์จริง cloudflared คือไคลเอนต์ tunnel ของ Cloudflare และโหมด quick-tunnel ของมันให้ URL สาธารณะชั่วคราว *.trycloudflare.com ด้วยคำสั่งเดียวและไม่ต้องมีบัญชี มันถูกเขียนด้วย Go, ได้รับใบอนุญาต Apache 2.0 และเป็นโอเพนซอร์สที่ github.com/cloudflare/cloudflared

ชี้ไปที่พอร์ตท้องถิ่นของคุณ:

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

มันจะพิมพ์ URL HTTPS สาธารณะที่ส่งต่อไปยัง localhost:3000 จนกว่าคุณจะหยุดมัน ดีที่สุดสำหรับ: tunnels แบบเร่งด่วน ฟรี และเฉพาะกิจ เมื่อคุณไม่ต้องการสมัครอะไร หากคุณต้องการอยู่ในระบบนิเวศ npm อย่างเต็มที่ localtunnel (MIT) ก็ทำงานเดียวกันด้วย npx localtunnel --port 3000 ข้อจำกัดที่แท้จริงของ quick tunnels: URL จะเป็นแบบสุ่มและชั่วคราว และสำหรับ tunnels ที่มีชื่อที่เสถียร คุณจะต้องสร้างบัญชี Cloudflare และการกำหนดค่า แม้ว่าไคลเอนต์จะยังคงเป็นโอเพนซอร์สอยู่ดี

git: การควบคุมเวอร์ชันในรูปแบบ CLI ไม่ใช่ GUI

เป็นเรื่องง่ายที่จะลืมว่า git เป็นเครื่องมือบรรทัดคำสั่งก่อนเสมอ ข้อมูลจำเพาะ API, ไฟล์ทดสอบ และสถานการณ์ Hurl ทุกอย่างที่กล่าวมาข้างต้นควรอยู่ใน git repo และ CLI คือที่ที่พลังที่แท้จริงอยู่: การจัดเตรียมอย่างแม่นยำ, bisect, rebase และ hooks ที่รันการทดสอบ API ของคุณก่อนที่ commit จะถูกนำไปใช้ git ได้รับใบอนุญาต GPLv2 และได้รับการพัฒนาแบบเปิดที่ github.com/git/git

ตัวอย่างเล็กๆ ที่เชื่อมโยงชุดเครื่องมือเข้าด้วยกัน: pre-commit hook ที่รันการทดสอบ Hurl ของคุณก่อนที่โค้ดจะถูกนำไปใช้

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

ดีที่สุดสำหรับ: เป็นรากฐานที่ทุกสิ่งอื่นตั้งอยู่ โฮสต์ด้วยตนเองตั้งแต่วันแรก ไม่ต้องใช้เซิร์ฟเวอร์ และสามารถ fork ได้ในทุกแง่มุม ข้อจำกัดที่แท้จริงคือ git เป็นระบบควบคุมเวอร์ชัน ไม่ใช่การโฮสต์โปรเจกต์; เลเยอร์การโฮสต์ (GitHub, GitLab, Gitea) เป็นทางเลือกที่แยกต่างหาก และมีเพียงบางส่วนเท่านั้นที่เป็นโอเพนซอร์ส

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

Apidog ไม่ใช่โอเพนซอร์ส ดังนั้นจึงไม่ควรอยู่ในรายการนี้ในฐานะรายการ OSS เป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีเวอร์ชันฟรี และควรค่าแก่การกล่าวถึงที่นี่ด้วยเหตุผลหนึ่ง: เครื่องมือข้างต้นนั้นยอดเยี่ยมในแต่ละส่วน แต่คุณต้องนำมาเชื่อมโยงเข้าด้วยกันด้วยตนเอง curl สำหรับคำขอ, jq สำหรับการแยกวิเคราะห์, Hurl สำหรับการทดสอบ, mock server แยกต่างหาก, ตัวสร้างเอกสาร, ตัวแปรสภาพแวดล้อมที่จัดการใน shell profiles

Apidog รวบรวมการออกแบบ การทดสอบ การจำลอง และเอกสารประกอบไว้ในพื้นที่ทำงานเดียว และ apidog-cli นำสิ่งนั้นมาสู่เทอร์มินัล มันเป็นแพ็คเกจ npm (npm install -g apidog-cli) และรันสถานการณ์การทดสอบ จัดการ endpoint และ schema สร้าง mock expectation และนำเข้าหรือส่งออก OpenAPI ทั้งหมดนี้ด้วยเอาต์พุต JSON ที่มีโครงสร้างซึ่งสคริปต์และ AI agent สามารถอ่านได้ apidog run จะออกค่า 0 เมื่อผ่านทั้งหมดและค่าที่ไม่ใช่ 0 เมื่อล้มเหลว ดังนั้นจึงสามารถนำไปใช้ใน CI ได้เช่นเดียวกับ Hurl

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

วิธีเลือก

เลือกเครื่องมือให้เหมาะสมกับงาน นักพัฒนาส่วนใหญ่ใช้เครื่องมือเหล่านี้หลายตัวพร้อมกัน เช่น curl หรือ HTTPie เพื่อดึงข้อมูล, jq เพื่อแยกวิเคราะห์, Hurl เพื่อทดสอบ, git เพื่อควบคุมเวอร์ชันทุกอย่าง

กฎง่ายๆ: เลือกใช้เครื่องมือโอเพนซอร์สแบบวัตถุประสงค์เดียวเมื่อคุณต้องการจัดการระบบเองทั้งหมด และเลือกใช้แพลตฟอร์มแบบรวมศูนย์เมื่อคุณไม่อยากทำเช่นนั้น หากคุณกำลังพิจารณาข้อดีข้อเสียนั้นทั่วทั้งชุดเครื่องมือ บทความเกี่ยวกับ Apidog ในฐานะแพลตฟอร์มการพัฒนา API ที่ครอบคลุม จะอธิบายถึงสิ่งที่เส้นทางแบบรวมศูนย์เข้ามาแทนที่

สรุป

โอเพนซอร์สพิสูจน์คุณค่าของมันในเทอร์มินัลด้วยการที่สามารถตรวจสอบได้ โฮสต์ด้วยตัวเองได้ และไม่มีการผูกขาด curl, HTTPie, jq, gh, Hurl, cloudflared และ git ครอบคลุมแกนหลักของการพัฒนา API และแบ็กเอนด์ และทุกตัวล้วนมีใบอนุญาตที่คุณสามารถอ่านและ repo ที่คุณสามารถ fork ได้ เริ่มต้นด้วยสองหรือสามตัวที่เหมาะกับเวิร์กโฟลว์ปัจจุบันของคุณ และเพิ่มส่วนที่เหลือเมื่อคุณต้องการ

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