หากคุณมาที่นี่หลังจากรัน npm install -g @apidevtools/swagger-cli และพบคำเตือน นี่คือสรุปสั้นๆ: เครื่องมือนี้ไม่ได้รับการดูแลแล้ว [ที่เก็บ swagger-cli บน GitHub](https://github.com/APIDevTools/swagger-cli) ระบุไว้อย่างชัดเจนว่าเลิกใช้งานแล้ว โดยอ้างถึง "ภาระในการดูแลรักษาที่ต้องพยายามตามความคาดหวังของผู้ใช้งานจำนวนมากแต่มีการสนับสนุนเพียงเล็กน้อยหรือไม่เลย" ไฟล์ README เองก็ชี้ไปที่ Redocly CLI ในฐานะเครื่องมือผู้สืบทอด
ดังนั้นคุณจึงต้องการเครื่องมือมาทดแทน บทความนี้เน้นไปที่เครื่องมือเทอร์มินัล swagger-cli โดยเฉพาะ ซึ่งทำหน้าที่ validate (ตรวจสอบความถูกต้อง) และ bundle (รวมไฟล์) หากคุณหมายถึง Swagger Editor, SwaggerHub หรือชุดเครื่องมือออกแบบที่กว้างกว่านั้น โปรดอ่าน [7 ทางเลือก Swagger ที่สามารถทดสอบ API ของคุณได้ด้วย](https://apidog.com/th/blog/swagger-alternatives-api-design-testing) แทน
มาดูกันว่า swagger-cli ทำอะไรได้บ้าง จากนั้นมาดูรายชื่อเครื่องมือที่แนะนำให้ใช้ตอนนี้อย่างตรงไปตรงมา
swagger-cli ทำอะไรได้บ้าง
การระบุให้ชัดเจนเป็นสิ่งสำคัญ เพราะเครื่องมือทดแทนที่เหมาะสมขึ้นอยู่กับสิ่งที่คุณเคยใช้
swagger-cli มีคำสั่งเพียงสองคำสั่งเท่านั้น:
# ตรวจสอบความถูกต้องของคำจำกัดความ Swagger 2.0 / OpenAPI 3.0 เทียบกับสคีมาและตรวจสอบ $refs
swagger-cli validate openapi.yaml
# ตามตัวชี้ $ref และรวมคำจำกัดความหลายไฟล์เป็นไฟล์เดียว
swagger-cli bundle openapi.yaml -o bundled.json
คำสั่ง bundle มีตัวเลือกไม่กี่อย่าง: -o/--outfile สำหรับเขียนลงไฟล์, -t/--type สำหรับเลือก JSON หรือ YAML, -r/--dereference สำหรับการรวม $ref ทั้งหมดไว้ในบรรทัดเดียวกัน และ -f/--format สำหรับการจัดรูปแบบย่อหน้า
นั่นคือเครื่องมือทั้งหมด มันตรวจสอบโครงสร้างและรวมสเปกหลายไฟล์ มันไม่ได้ตรวจสอบตามกฎสไตล์, สร้างเอกสาร, รันการทดสอบ หรือจำลองอะไรเลย หากคุณอ่านข้ออ้างว่า swagger-cli "ตรวจสอบ" สเปกของคุณ นั่นผิด; มันเพียงแค่ตรวจสอบคำจำกัดความของคุณเทียบกับ OpenAPI schema และแก้ไขการอ้างอิง โปรดจำขอบเขตนี้ไว้ เพราะเครื่องมือทดแทนบางอย่างทำได้มากกว่านั้นมาก และคุณอาจต้องการหรือไม่ต้องการสิ่งนั้นก็ได้
รายชื่อที่แนะนำ
มีเครื่องมือสามชนิดที่ครอบคลุมเกือบทุกเหตุผลที่คุณจะใช้ swagger-cli รวมถึงเครื่องมือเฉพาะทางอีกสองสามอย่างที่ควรกล่าวถึง นี่คือการสรุปอย่างตรงไปตรงมา
Redocly CLI: เครื่องมือผู้สืบทอดอย่างเป็นทางการและทดแทนได้ใกล้เคียง 1:1 มากที่สุด
[Redocly CLI](https://redocly.com/docs/cli) (@redocly/cli, ไบนารี redocly) เป็นโอเพนซอร์ส และเป็นเครื่องมือที่ไฟล์ README ของ swagger-cli เองแนะนำ Redocly ยังเผยแพร่ [คู่มือการย้ายข้อมูลจาก swagger-cli](https://redocly.com/docs/cli/guides/migrate-from-swagger-cli) อีกด้วย หากเป้าหมายของคุณคือตัวตรวจสอบและตัวรวมไฟล์แบบเทอร์มินัลที่ใช้งานง่าย เริ่มที่นี่ได้เลย
ติดตั้งด้วยวิธีเดียวกับที่คุณติดตั้ง swagger-cli:
npm install -g @redocly/cli@latest
# หรือรันโดยไม่ต้องติดตั้ง
npx @redocly/cli@latest lint openapi.yaml
การจับคู่เป็นไปอย่างชัดเจน `validate` ของ swagger-cli กลายเป็น `redocly lint` ซึ่งจะตรวจสอบสเปกของคุณและใช้กฎสไตล์ที่สามารถกำหนดค่าได้ `bundle` ของ swagger-cli กลายเป็น `redocly bundle`:
# swagger-cli bundle -o output.json
redocly bundle openapi.yaml --output output.json
นี่คือการจับคู่แฟล็ก bundle แบบเคียงข้างกัน:
| swagger-cli | Redocly CLI | วัตถุประสงค์ |
|---|---|---|
-o, --outfile |
--output (หรือ -o) |
เขียนลงในไฟล์ |
-t, --type |
--ext (json, yaml, yml) |
รูปแบบเอาต์พุต |
-r, --dereference |
-d, --dereferenced |
รวม $ref ทั้งหมดไว้ในบรรทัดเดียวกัน |
สิ่งหนึ่งที่ควรรู้: redocly lint ทำอะไรได้มากกว่า `validate` ของ swagger-cli ตามค่าเริ่มต้น มันใช้ชุดกฎของคู่มือสไตล์ ไม่ใช่แค่การตรวจสอบสคีมา หากคุณต้องการการตรวจสอบโครงสร้างธรรมดาที่ swagger-cli ให้มา ให้กำหนดค่า redocly.yaml ด้วยกฎ spec เพียงอย่างเดียว จากนั้นรัน redocly lint openapi.yaml พฤติกรรมของชุดกฎนั้นเป็นจุดแข็งที่เป็นเอกลักษณ์ของ Redocly มากกว่าข้อด้อย; นี่คือเหตุผลที่ทีมที่ต้องการการกำกับดูแลแบบเทอร์มินัลชื่นชอบ คุณสามารถปรับแต่งชุดกฎ (`minimal`, `recommended`, `recommended-strict`, `spec`) หรือเขียนกฎเองได้ ดู [การตั้งค่า OpenAPI linter ที่ดีที่สุด](https://apidog.com/th/blog/openapi-linter) สำหรับวิธีการทำงานร่วมกับ linters อื่นๆ
Redocly CLI ยังก้าวข้ามคำสั่งสองคำสั่งของ swagger-cli อีกด้วย มันสามารถ split คำอธิบายเดียวออกเป็นโครงสร้างหลายไฟล์ (ตรงข้ามกับการ bundle), join หลายไฟล์ (ทดลอง) และสร้างเอกสาร Redoc HTML แบบสแตนด์อาลอนได้:
redocly build-docs openapi.yaml -o docs.html
สิ่งที่มันไม่ได้ทำ: รันการทดสอบ API หรือโฮสต์ mock server มันเป็นเครื่องมือ lint/bundle/docs ที่เน้นโค้ดเป็นหลัก, ใช้งานผ่านเทอร์มินัล และเป็นเครื่องมือที่ยอดเยี่ยม หากนั่นคือทั้งหมดที่คุณต้องการ คุณสามารถหยุดอ่านและย้ายไปใช้ได้เลยวันนี้
Apidog: เมื่อคุณต้องการมากกว่าแค่การตรวจสอบ (validate) และการรวมไฟล์ (bundle)
นี่คือการปรับมุมมองอย่างตรงไปตรงมา swagger-cli เป็นสคริปต์คงที่ที่คุณรันเพื่อตรวจสอบและรวมไฟล์ แต่สำหรับทีมส่วนใหญ่ การตรวจสอบและการรวมไฟล์เป็นเพียงวิธีการไปสู่จุดประสงค์ คุณตรวจสอบเพื่อให้สเปกถูกต้อง คุณรวมไฟล์เพื่อให้สามารถพกพาได้ จากนั้นคุณก็จำลอง, ทดสอบ และจัดทำเอกสาร swagger-cli มอบขั้นตอนเหล่านั้นให้เครื่องมืออื่นจัดการ
[Apidog](https://apidog.com) ช่วยเติมเต็มช่องว่างนั้น เป็นแพลตฟอร์ม API แบบครบวงจร: ออกแบบ, จำลอง, ทดสอบ และจัดทำเอกสารในพื้นที่ทำงานเดียว พร้อม CLI ที่จัดการการนำเข้า, ส่งออก และการรันการทดสอบ CI ในขณะที่ swagger-cli ให้ไฟล์แก่คุณ Apidog มอบพื้นที่ทำงานที่มีชีวิตชีวาที่สร้างขึ้นจากไฟล์นั้น
สองคำสั่งที่ตรงกับความเคยชินในการใช้ swagger-cli ของคุณมากที่สุดคือ import และ export ติดตั้ง CLI และยืนยันตัวตนก่อน:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
คุณสามารถรับโทเค็นได้จากแอป Apidog หรือเว็บไซต์: รูปโปรไฟล์ (avatar), จากนั้น Account Settings, แล้ว API Access Token มันถูกเก็บไว้ใน ~/.apidog/config.toml ดังนั้นห้ามพิมพ์หรือคอมมิตมันเด็ดขาด
การนำเข้า (Import) คือขั้นตอนการตรวจสอบของคุณ มันนำคำจำกัดความเข้าสู่โปรเจกต์และแก้ไข `$ref` หลายไฟล์ให้เป็นทรัพยากรเดียว หากไฟล์มีรูปแบบผิดพลาด การนำเข้าจะแสดงข้อผิดพลาดนั้น:
apidog import --project 123456 --format openapi --file ./openapi.json
การนำเข้ายอมรับรูปแบบต่างๆ มากมายนอกเหนือจาก OpenAPI รวมถึง Postman, HAR, Insomnia, WSDL และ JSON Schema ซึ่งมีประโยชน์เมื่อแหล่งที่มาของคุณหลากหลาย
การส่งออก (Export) คือขั้นตอนการรวมไฟล์ของคุณ พร้อมโบนัสพิเศษ มันจะสร้างไฟล์เดียวที่รวมเข้าด้วยกัน และคุณสามารถเลือกรุ่น OpenAPI เมื่อส่งออกได้ ทำให้เป็นการรวมไฟล์พร้อมการอัปเกรดสเปกที่ไม่บังคับในคำสั่งเดียว:
# รวมไฟล์และอัปเกรดเป็น OpenAPI 3.1 ในครั้งเดียว
apidog export --project 123456 --format openapi --output ./openapi.json --oas-version 3.1
# หรือส่งออกเอกสาร HTML แบบสแตนด์อโลน
apidog export --project 123456 --format html --output ./docs.html
สำหรับ CI, Apidog เพิ่มขั้นตอนที่ swagger-cli ไม่เคยมี: การรันการทดสอบ
# รันสถานการณ์การทดสอบใน CI ด้วยรูปแบบรายงานที่หลากหลาย
apidog run --project 123456 -t <testScenarioId> -e <environmentId> -r "cli,html,json,junit"
# หรือรันแบบออฟไลน์ทั้งหมดจากไฟล์คอลเลกชันที่ส่งออก
apidog run ./collection.apidog-cli.json
CLI ยังจัดการทรัพยากรของโปรเจกต์ได้โดยตรง รวมถึง endpoint, schema, mock, environment, branch, test-suite และ test-report สำหรับรายละเอียดการตั้งค่าและแฟล็กทั้งหมด โปรดดูที่ [คู่มือ Apidog CLI ฉบับสมบูรณ์](https://apidog.com/th/blog/apidog-cli-complete-guide) และ [เอกสารอย่างเป็นทางการของ Apidog CLI](https://docs.apidog.com/introduction-to-apidog-cli-605134m0)
ตอนนี้มาดูข้อจำกัดอย่างตรงไปตรงมา เพราะความเหมาะสมสำคัญกว่ากระแส CLI ของ Apidog ตรวจสอบโครงสร้างเมื่อนำเข้า แต่ไม่ได้ให้เครื่องมือ linter สำหรับคู่มือสไตล์ที่กำหนดค่าได้และเน้นโค้ดเป็นหลักพร้อมชุดกฎที่กำหนดเองได้เหมือนกับ `lint` ของ Redocly ไม่มีคำสั่ง apidog lint และคุณไม่สามารถสร้างกฎที่กำหนดเองสไตล์ Spectral ผ่าน CLI ได้ ไม่มี split หรือ join ด้วย Apidog เน้น GUI เป็นหลัก: การออกแบบ, การจำลอง, การสร้างการทดสอบด้วยภาพ และเอกสารส่วนใหญ่จะถูกสร้างขึ้นในแอปเดสก์ท็อปหรือเว็บแอป โดยมี CLI จัดการการนำเข้า, ส่งออก, การรันการทดสอบ CI และการจัดการทรัพยากรของโปรเจกต์ และ Apidog เป็นแบบ freemium ไม่ใช่โอเพนซอร์ส ดังนั้นจึงเป็นโมเดลที่แตกต่างจาก Redocly CLI และ Spectral
Spectral: การตรวจสอบโค้ดที่บริสุทธิ์และปรับแต่งได้ใน CI
หากสิ่งที่คุณต้องการจริงๆ จาก swagger-cli คือการตรวจสอบที่เข้มงวดและมีกฎเกณฑ์ในไปป์ไลน์ของคุณ เครื่องมือ linter โดยเฉพาะคือ [Spectral](https://github.com/stoplightio/spectral) จาก Stoplight เป็นโอเพนซอร์สและถูกสร้างมาเพื่อวัตถุประสงค์เดียว: การนำชุดกฎที่ปรับแต่งได้ไปใช้กับเอกสาร OpenAPI (และ JSON/YAML อื่นๆ)
Spectral โดดเด่นเมื่อคุณต้องการบังคับใช้สไตล์ขององค์กรเป็นโค้ด ด้วยกฎของคุณเอง ในทุก pull request มันไม่ได้รวมไฟล์, ไม่ได้สร้างเอกสาร, และไม่ได้ทดสอบเอนด์พอยต์; มันแค่ตรวจสอบโค้ด จับคู่กับ bundler แล้วคุณจะสร้างเวอร์ชันที่เน้นเฉพาะสิ่งที่ swagger-cli ทำได้ขึ้นมาใหม่ พร้อมการกำกับดูแลที่แท้จริง คู่มือของเราเกี่ยวกับ [การตรวจสอบโค้ด OpenAPI ด้วย Spectral](https://apidog.com/th/blog/spectral-openapi-linting) จะแนะนำการเขียนชุดกฎ และ [การตรวจสอบ OpenAPI ใน CI](https://apidog.com/th/blog/openapi-validation-ci) จะครอบคลุมการเชื่อมต่อเข้ากับไปป์ไลน์
โดยย่อ: openapi-generator และ vacuum
มีเครื่องมืออีกสองอย่างที่ถูกกล่าวถึง ดังนั้นนี่คือเวอร์ชันที่ถูกต้องและกระชับ `openapi-generator` เป็นตัวสร้างโค้ดและไคลเอนต์; หากเหตุผลในการรวมไฟล์ของคุณคือเพื่อป้อนให้ตัวสร้าง คุณอาจไม่จำเป็นต้องมีขั้นตอนการรวมไฟล์แยกต่างหากเลย เนื่องจากมันใช้สเปกได้โดยตรง `vacuum` เป็น OpenAPI linter ที่รวดเร็วและเข้ากันได้กับ Spectral ซึ่งเขียนด้วยภาษา Go เป็นตัวเลือกที่ดีเมื่อความเร็วในการตรวจสอบโค้ดใน monorepos ขนาดใหญ่มีความสำคัญ ทั้งสองไม่ใช่เครื่องมือทดแทนการตรวจสอบและการรวมไฟล์แบบทั่วไปในตัวมันเอง แต่ทั้งสองตรงกับความต้องการเฉพาะ
ตารางเปรียบเทียบ
นี่คือวิธีการเปรียบเทียบตัวเลือกต่างๆ ตามความสามารถที่ผู้ใช้ swagger-cli มักจะใส่ใจ
| เครื่องมือ | ตรวจสอบ | รวมไฟล์ | กฎการตรวจสอบโค้ด | เอกสาร | จำลอง | ทดสอบ | โอเพนซอร์ส | เหมาะสำหรับ |
|---|---|---|---|---|---|---|---|---|
| swagger-cli | ใช่ | ใช่ | ไม่ | ไม่ | ไม่ | ไม่ | ใช่ (เลิกใช้แล้ว) | ไม่มีอะไรใหม่; ไม่ได้รับการดูแลแล้ว |
| Redocly CLI | ใช่ (lint) |
ใช่ | ใช่ (ปรับแต่งได้) | ใช่ (Redoc HTML) | ไม่ | ไม่ | ใช่ | เครื่องมือเทอร์มินัลสำหรับตรวจสอบ/รวมไฟล์ที่ใช้งานง่ายพร้อมการกำกับดูแล |
| Apidog | ใช่ (เมื่อนำเข้า) | ใช่ (เมื่อส่งออก, พร้อมการอัปเกรด OAS) | โครงสร้างเท่านั้น, ไม่มีชุดกฎที่กำหนดเอง | ใช่ (แอป + ส่งออก) | ใช่ | ใช่ (รัน CLI) | ไม่ (freemium) | เครื่องมือเดียวสำหรับวงจรชีวิต API ทั้งหมด |
| Spectral | ใช่ (อิงการตรวจสอบโค้ด) | ไม่ | ใช่ (ชุดกฎที่กำหนดเอง) | ไม่ | ไม่ | ไม่ | ใช่ | การตรวจสอบโค้ดที่เข้มงวดและปรับแต่งได้ใน CI |
| vacuum | ใช่ (อิงการตรวจสอบโค้ด) | ไม่ | ใช่ (เข้ากันได้กับ Spectral) | ไม่ | ไม่ | ไม่ | ใช่ | การตรวจสอบโค้ดที่รวดเร็วสำหรับสเปกขนาดใหญ่ |
คำแนะนำ
นี่ไม่ใช่สถานการณ์ที่ "ทุกอย่างดีหมด เลือกอันที่ชอบ" มีสองเส้นทางที่ชัดเจนซึ่งครอบคลุมเกือบทุกคน
เลือก Redocly CLI หากคุณต้องการเครื่องมือทดแทนที่ใช้งานง่าย เป็นเครื่องมือผู้สืบทอดอย่างเป็นทางการ เป็นโอเพนซอร์ส และการย้ายข้อมูลแทบจะเป็นกลไก: validate เป็น lint, bundle เป็น bundle โดยมีการจับคู่แฟล็กที่กล่าวไว้ข้างต้น หากเวิร์กโฟลว์ของคุณคือการ "ตรวจสอบและรวมไฟล์จากเทอร์มินัล" อย่างแท้จริง และคุณต้องการเพิ่มกฎการกำกับดูแลในภายหลังโดยไม่ต้องเปลี่ยนเครื่องมือ Redocly คือทางเลือกที่ชัดเจน มันทำให้คุณยังคงใช้แนวทางโค้ดเป็นหลักและเป็นแบบเทอร์มินัล ซึ่งเป็นสิ่งที่ swagger-cli เคยทำ
เลือก Apidog หากการตรวจสอบและรวมไฟล์เป็นเพียงจุดเริ่มต้น ทีมส่วนใหญ่ไม่ได้ตรวจสอบสเปกเพื่อตัวมันเอง พวกเขาตรวจสอบแล้ว จากนั้นก็มีคนต้องการ mock เพื่อใช้สร้างงาน มีคนอื่นเขียนการทดสอบ และมีคนเป็นเจ้าของเอกสาร swagger-cli หยุดที่ขั้นตอนแรกและบังคับให้คุณประกอบส่วนที่เหลือจาก Spectral, bundler, Postman และ Newman Apidog นำการนำเข้า (validate), การส่งออก (bundle พร้อมการอัปเกรดเวอร์ชัน OAS), mock, test และ docs มารวมไว้ในพื้นที่ทำงานเดียว พร้อม CLI สำหรับส่วนที่เกี่ยวข้องกับ CI คุณหยุดดูแลสคริปต์แบบคงที่ที่ตอนนี้ไม่ได้รับการดูแลแล้ว และนำสเปกทั้งหมดมาไว้ในที่ที่ยังคงมีประโยชน์หลังจากที่ถูกรวมไฟล์
สิ่งเหล่านี้คือกระบวนทัศน์ที่แตกต่างกัน ไม่ใช่เวอร์ชันที่แข่งขันกันของสิ่งเดียวกัน Redocly CLI เป็นเครื่องมือเฉพาะทางที่น้ำหนักเบา ขับเคลื่อนด้วยการกำหนดค่า ซึ่งคุณรันได้จากเทอร์มินัลเท่านั้น Apidog เป็นแพลตฟอร์มแบบครบวงจรที่มี CLI ที่มีความสามารถ เลือกตามจำนวนวงจรชีวิตที่คุณต้องการในเครื่องมือเดียว และซื่อสัตย์กับตัวเอง: หากคุณต้องการเพียงแค่ตรวจสอบโค้ดและรวมไฟล์ในเทอร์มินัล Redocly ก็เบากว่าและฟรี
หากคุณต้องการลองแนวทางวงจรชีวิต ให้ดาวน์โหลด Apidog และนำเข้าสเปกที่มีอยู่; เริ่มต้นใช้งานฟรี ไม่ต้องใช้บัตรเครดิต และคุณสามารถเห็นเอาต์พุตที่รวมไฟล์และมีเวอร์ชันของคุณได้ในไม่กี่นาที
คำถามที่พบบ่อย
swagger-cli ยังได้รับการดูแลอยู่หรือไม่?
ไม่ [ที่เก็บ swagger-cli บน GitHub](https://github.com/APIDevTools/swagger-cli) ถูกทำเครื่องหมายว่าเลิกใช้งานแล้วและไม่ได้รับการดูแลอีกต่อไป โดยอ้างถึงการสนับสนุนที่น้อยเมื่อเทียบกับฐานผู้ใช้ขนาดใหญ่ มันยังคงติดตั้งและทำงานได้ แต่จะไม่ได้รับการแก้ไขข้อผิดพลาดหรือการอัปเดต ดังนั้นควรวางแผนการย้ายข้อมูล
อะไรที่มาแทนที่ swagger-cli?
ไฟล์ README ของโปรเจกต์เองชี้ไปที่ Redocly CLI ในฐานะเครื่องมือผู้สืบทอด redocly lint มาแทนที่ swagger-cli validate และ redocly bundle มาแทนที่ swagger-cli bundle Redocly ยังเผยแพร่ [คู่มือการย้ายข้อมูลโดยเฉพาะ](https://redocly.com/docs/cli/guides/migrate-from-swagger-cli) อีกด้วย หากคุณต้องการมากกว่าแค่การตรวจสอบและการรวมไฟล์ Apidog ก็ครอบคลุมการนำเข้า, ส่งออก, จำลอง, ทดสอบ และเอกสารในที่เดียว
Apidog ฟรีหรือไม่?
Apidog เป็นแบบ freemium มีแผนบริการฟรีที่คุณสามารถเริ่มต้นได้โดยไม่ต้องใช้บัตรเครดิต พร้อมแผนชำระเงินสำหรับทีมขนาดใหญ่และความต้องการขั้นสูง ไม่ใช่โอเพนซอร์ส ซึ่งเป็นความแตกต่างหลักจาก Redocly CLI และ Spectral หากการอนุญาตแบบเปิดเป็นข้อกำหนดสำหรับคุณ
ฉันสามารถรักษากระบวนการทำงานของ swagger-cli ไว้เหมือนเดิมได้หรือไม่?
ที่ใกล้เคียงที่สุดคือ Redocly CLI หากต้องการเลียนแบบ `validate` เชิงโครงสร้างแบบธรรมดาของ swagger-cli ให้ตั้งค่า redocly.yaml ด้วยกฎ spec เพียงอย่างเดียวแล้วรัน redocly lint สำหรับการรวมไฟล์ คำสั่งและแฟล็กจะจับคู่กันเกือบจะหนึ่งต่อหนึ่ง สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับขอบเขตของเครื่องมือดั้งเดิม โปรดดู [วิธีการใช้ swagger-cli จากเทอร์มินัล](https://apidog.com/th/blog/swagger-cli)