Apidog โหมด Spec-First คืออะไร

Apidog Spec-First Mode เป็นพื้นที่ทำงานรุ่นเบต้าที่สร้างขึ้นสำหรับทีมที่ถือว่าสเปก OpenAPI ของตนเป็นซอร์สโค้ด คุณเขียนสเปกโดยตรงในรูปแบบ YAML หรือ JSON ในโปรแกรมแก้ไขสไตล์ IDE จากนั้นซิงค์สองทางกับพื้นที่เก็บข้อมูล Git ที่เชื่อมต่ออยู่ ไม่มีโปรแกรมแก้ไขแบบฟอร์มคั่นกลางระหว่างคุณกับไฟล์ สเปก คือ โปรเจกต์ หากคุณเคยต้องการแก้ไข openapi.yaml ในโปรแกรมแก้ไขโค้ดจริงและพุชไปยัง GitHub โดยไม่ต้องออกจากเครื่องมือ API ของคุณ นี่คือโหมดสำหรับคุณ

คู่มือนี้เป็นข้อมูลอ้างอิงฉบับสมบูรณ์สำหรับคุณสมบัตินี้ ครอบคลุมทุกความสามารถ, ขั้นตอนการตั้งค่าทั้งหมด, ผู้ใช้งานที่เหมาะสม, ข้อจำกัดที่คาดหวังจากเวอร์ชันเบต้า และคำถามที่พบบ่อยที่ใช้งานได้จริง สำหรับแนวคิดที่กว้างขึ้นเบื้องหลังแนวทางนี้ โปรดดูที่ เวิร์กโฟลว์ API ที่ทำงานร่วมกับ Git ได้อย่างเป็นธรรมชาติ ของเรา

Apidog Spec-First Mode คืออะไร?

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

มันถูกสร้างขึ้นมาสำหรับทีมประเภทหนึ่งโดยเฉพาะ: ผู้ที่ใช้เวิร์กโฟลว์ Git แบบเนทีฟอยู่แล้ว วิศวกรแบ็กเอนด์, ทีมแพลตฟอร์ม และบริษัทที่เน้น API ซึ่งจัดการเวอร์ชันสัญญาผ่าน pull requests จะรู้สึกคุ้นเคย ไฟล์สเปกจะกลายเป็นแหล่งข้อมูลเดียวที่เชื่อถือได้ และ Git จะจัดการประวัติ, การรีวิว และการทำ branch ในลักษณะเดียวกับที่ใช้กับ codebase ส่วนที่เหลือของคุณ

นี่แตกต่างจากวิธีการทำงานของเครื่องมือ API ส่วนใหญ่ เครื่องมือส่วนใหญ่จะซ่อนสเปกไว้หลังรูปแบบกราฟิก โหมด Spec-First จะแสดงไฟล์ให้คุณเห็น

โหมด Spec-First เทียบกับ โหมด Design-First: ภาพรวม

Apidog มีสองโหมด โหมด Design-First เป็นโปรแกรมแก้ไขแบบภาพที่ใช้ฟอร์ม ซึ่งทีมส่วนใหญ่เริ่มต้นด้วย โหมด Spec-First เป็นแนวทางที่ใช้โปรแกรมแก้ไขโค้ด ซึ่งคู่มือนี้จะกล่าวถึง นี่คือฉบับย่อ สำหรับการวิเคราะห์ข้อดีข้อเสียทั้งหมด โปรดอ่าน การเปรียบเทียบระหว่าง spec-first กับ design-first ของเรา

ไม่มีโหมดใด “ดีกว่า” ทั้งสองโหมดให้บริการทีมที่แตกต่างกัน คุณสามารถสลับไปมาระหว่างโหมดได้ ซึ่งเราจะกล่าวถึงด้านล่าง

คุณสมบัติสำคัญ

โหมด Spec-First เป็นมากกว่ากล่องข้อความ มันรวบรวมโปรแกรมแก้ไข, ตัวนำทาง, การรวม Git และการควบคุมทีม นี่คือความสามารถทุกอย่างโดยละเอียด

โปรแกรมแก้ไข OpenAPI สไตล์ IDE

ส่วนกลางของพื้นที่ทำงานคือโปรแกรมแก้ไขโค้ดเต็มรูปแบบสำหรับเอกสาร OpenAPI ของคุณ คุณแก้ไข YAML หรือ JSON ดิบได้โดยตรง มันทำงานเหมือนโปรแกรมแก้ไขที่คุณใช้งานอยู่ทุกวัน

คุณจะได้รับการไฮไลต์โค้ดที่ช่วยให้คีย์, ค่า และโครงสร้างมีสีสัน ทำให้ไฟล์อ่านง่ายขึ้นแม้ในขนาดใหญ่ คุณจะได้รับการตรวจสอบ Schema ที่แจ้งข้อผิดพลาดตามข้อกำหนด OpenAPI ทันทีที่คุณพิมพ์ ดังนั้นออบเจกต์การตอบกลับที่ผิดรูปแบบหรือฟิลด์ที่จำเป็นที่หายไปจะแสดงขึ้นมาทันที คุณจะได้รับการเติมข้อความอัตโนมัติที่ปรับแต่งมาสำหรับ OpenAPI และ Swagger ซึ่งจะแนะนำคีย์เวิร์ด, ชื่อฟิลด์ และโครงสร้างที่ถูกต้องในขณะที่คุณเขียน

การเติมข้อความอัตโนมัตินี้สำคัญที่สุดเมื่อคุณกำลังเจาะลึกอยู่ใน Schema และจำไม่ได้ว่าควรใช้ additionalProperties หรือ additionalItems โปรแกรมแก้ไขรู้สเปก จึงช่วยให้คุณเขียนได้อย่างถูกต้อง

ส่วนย่อยที่คุณจะแก้ไข:

paths:
 /users/{userId}:
 get:
 summary: Get a user by ID
 operationId: getUserById
 parameters:
 - name: userId
 in: path
 required: true
 schema:
 type: string
 responses:
 '200':
 description: A single user
 content:
 application/json:
 schema:
 $ref: '#/components/schemas/User'

โครงร่างที่สามารถนำทางได้โดยอัตโนมัติ

ไฟล์สเปกแบบดิบอาจยาวขึ้นอย่างรวดเร็ว API จริงอาจมีหลายพันบรรทัด โหมด Spec-First แก้ปัญหานี้ด้วยแถบด้านข้างซ้ายที่จะแยกวิเคราะห์ไฟล์เป็นโครงร่างแบบภาพโดยอัตโนมัติ

ขณะที่คุณพิมพ์ Apidog จะอ่านเอกสารและสร้างโครงสร้างที่นำทางได้: paths, operations, schemas และ components คลิกโหนดใด ๆ ในโครงร่าง โปรแกรมแก้ไขจะกระโดดไปยังตำแหน่งนั้นในไฟล์ คุณนำทางตามความหมาย ไม่ใช่การเลื่อน โครงร่างจะอัปเดตแบบเรียลไทม์เมื่อสเปกเปลี่ยนแปลง ดังนั้นจึงแสดงสิ่งที่อยู่ในไฟล์จริงเสมอ

สิ่งนี้ช่วยให้ไฟล์ openapi.yaml ขนาดใหญ่สามารถจัดการได้ คุณคิดในแง่ของ “การดำเนินการ POST /orders” ไม่ใช่ “บรรทัดที่ 1,847”

การซิงค์ Git สองทาง

นี่คือแกนหลักของโหมดนี้ โหมด Spec-First เชื่อมต่อกับพื้นที่เก็บข้อมูล Git ของคุณและซิงค์สเปกทั้งสองทิศทาง

GitHub และ GitLab ได้รับการสนับสนุนโดยตรง Azure DevOps ทำงานผ่าน Generic Git Connection ซึ่งช่วยให้คุณชี้ Apidog ไปยังรีโพสิตอรีโดยใช้ข้อมูลประจำตัว Git มาตรฐาน เมื่อเชื่อมต่อแล้ว การดึงข้อมูลจะนำการเปลี่ยนแปลงจากรีโพสิตอรีเข้ามาในโปรแกรมแก้ไขของคุณ และการพุชจะส่งการแก้ไขของคุณกลับไปยังรีโพสิตอรี สเปกจะคงความสอดคล้องกันในหมู่ทุกคนในทีม เพราะ Git เป็นแกนหลักที่ใช้ร่วมกัน

หากคุณต้องการคำแนะนำที่เน้นและเป็นขั้นตอนสำหรับผู้ให้บริการรายเดียว คู่มือการซิงค์ OpenAPI spec ไปยัง GitHub ของเราจะอธิบายขั้นตอนดังกล่าวอย่างละเอียด

คอมมิต, พุช และตัวบ่งชี้สถานะการซิงค์

คุณไม่ได้แค่บันทึกแล้วหวัง โหมด Spec-First ทำตามโมเดล Git ที่คุณรู้จักอยู่แล้ว เมื่อคุณแก้ไขเสร็จ คุณจะเขียนข้อความคอมมิตและคอมมิตการเปลี่ยนแปลง จากนั้นคุณก็พุชไปยังรีโพสิตอรีที่เชื่อมต่ออยู่

ตัวบ่งชี้สถานะการซิงค์จะแจ้งให้คุณทราบตลอดเวลา มันจะแสดงสถานะเช่น “Synced just now” เมื่อสเปกในเครื่องของคุณตรงกับรีโพสิตอรี และจะเปลี่ยนไปเมื่อคุณมีการเปลี่ยนแปลงที่ยังไม่ได้พุช คุณจะรู้เสมอว่าเวอร์ชันที่คุณเห็นอยู่ตรงหน้าเป็นเวอร์ชันที่เพื่อนร่วมทีมของคุณเห็นหรือไม่ ไม่ต้องคาดเดา ไม่ต้องมีสเปกที่ล้าสมัย

การติดตามการเปลี่ยนแปลงไฟล์

ก่อนที่คุณจะคอมมิต โหมด Spec-First จะแสดงให้คุณเห็นว่ามีการเปลี่ยนแปลงอะไรบ้างอย่างแม่นยำ มันติดตามการแก้ไขในระดับไฟล์และทำเครื่องหมายแต่ละรายการว่าถูกแก้ไข, เพิ่ม หรือลบ คุณตรวจสอบชุดการเปลี่ยนแปลงในลักษณะเดียวกับที่คุณตรวจสอบผลลัพธ์สถานะ Git

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

โปรเจกต์ที่มีการกำหนดขอบเขตตาม Branch และ Repo พร้อมสิทธิ์ของทีม

โปรเจกต์ Spec-First ไม่ได้ลอยอยู่เป็นนามธรรม คุณสร้างมันจากพื้นที่เก็บข้อมูล (repository) และ branch ที่เฉพาะเจาะจง ซึ่งโดยทั่วไปคือ main การกำหนดขอบเขตนั้นหมายความว่าโปรเจกต์จะชี้ไปยังตำแหน่งจริงใน Git เสมอ สเปก ประวัติ และ branch ของคุณจะตรงกัน

สิทธิ์ของทีมจะถูกกำหนดค่าระหว่างการตั้งค่า คุณตัดสินใจว่าใครสามารถเข้าถึงโปรเจกต์ได้และสามารถทำอะไรได้บ้าง เพื่อให้คนที่ทำงานเกี่ยวกับสัญญาคือคนที่คุณต้องการ เนื่องจากโปรเจกต์ผูกกับรีโพสิตอรีและ branch โมเดลการเข้าถึงของคุณจึงสามารถสะท้อนโมเดลการเข้าถึงที่คุณบังคับใช้ใน Git อยู่แล้ว

วิธีตั้งค่าโหมด Spec-First

การตั้งค่าเป็นขั้นตอนสั้นๆ ที่เป็นเส้นตรง ทำตามขั้นตอนเหล่านี้ คู่มือฉบับสมบูรณ์อยู่ที่ docs.apidog.com/spec-first-mode-beta-2058268m0 หากคุณต้องการดูภาพประกอบ

1. สลับโหมด เปิดโมดูล APIs ใน Apidog ค้นหาสวิตช์โหมดที่มุมล่างซ้ายของโมดูล และสลับจากโหมด Design-First เป็น Spec-First Mode
2. เชื่อมต่อผู้ให้บริการ Git ของคุณ ให้สิทธิ์ GitHub หรือ GitLab โดยตรง สำหรับ Azure DevOps ให้ตั้งค่า Generic Git Connection ด้วยข้อมูลประจำตัว Git ของคุณ
3. สร้างโปรเจกต์จากรีโพสิตอรีของคุณ เลือกพื้นที่เก็บข้อมูลที่มีสเปกของคุณและเลือก branch ซึ่งโดยทั่วไปคือ main Apidog จะกำหนดขอบเขตโปรเจกต์ใหม่ไปยังรีโพสิตอรีและ branch นั้น
4. กำหนดสิทธิ์ของทีม ระหว่างการตั้งค่า ให้กำหนดว่าใครสามารถเข้าถึงโปรเจกต์ได้และสามารถเปลี่ยนแปลงอะไรได้บ้าง
5. แก้ไขสเปก เปิดไฟล์ openapi.yaml หรือ openapi.json ของคุณในโปรแกรมแก้ไขสไตล์ IDE ใช้โครงร่างทางด้านซ้ายเพื่อนำทาง ใช้ประโยชน์จากการตรวจสอบความถูกต้องและการเติมข้อความอัตโนมัติขณะที่คุณเขียน
6. คอมมิตการเปลี่ยนแปลงของคุณ เขียนข้อความคอมมิตที่ชัดเจน ตรวจสอบการเปลี่ยนแปลงที่ติดตามก่อน ทิ้งสิ่งที่คุณไม่ต้องการเก็บไว้
7. พุชไปยังรีโพสิตอรี พุชคอมมิตของคุณไปยัง branch ที่เชื่อมต่อ
8. ตรวจสอบการซิงค์ ตรวจสอบตัวบ่งชี้สถานะการซิงค์ เมื่อแสดงว่า “Synced just now” แสดงว่าสเปกและรีโพสิตอรีของคุณตรงกัน

นั่นคือวงจรทั้งหมด: สลับ, เชื่อมต่อ, สร้าง, แก้ไข, คอมมิต, พุช, ตรวจสอบ

เวิร์กโฟลว์ประจำวันทั่วไป

นี่คือความรู้สึกในการใช้งานจริงของโหมดนี้เมื่อตั้งค่าเสร็จแล้ว

คุณเริ่มต้นวันด้วยการดึงข้อมูลล่าสุดจาก branch ที่เชื่อมต่อ เพื่อให้โปรแกรมแก้ไขของคุณสะท้อนสิ่งที่เพื่อนร่วมทีมรวมเข้าด้วยกันเมื่อคืน คุณเปิดโครงร่าง คลิกไปยังการดำเนินการที่คุณกำลังทำ และเริ่มแก้ไข YAML เอ็นด์พอยต์ใหม่ต้องการ request body คุณจึงกำหนด schema การเติมข้อความอัตโนมัติช่วยให้คุณระบุชื่อฟิลด์ได้อย่างถูกต้อง และการตรวจสอบความถูกต้องจะจับข้อผิดพลาดในการพิมพ์ใน $ref ก่อนที่จะกลายเป็นปัญหา

เมื่อเอ็นด์พอยต์ดูดีแล้ว คุณตรวจสอบการติดตามการเปลี่ยนแปลงไฟล์ มันแสดงการแก้ไขของคุณ คุณเขียนข้อความคอมมิต เช่น Add POST /invoices endpoint, คอมมิต และพุช ตัวบ่งชี้สถานะจะเปลี่ยนเป็น “Synced just now” เพื่อนร่วมทีมจะตรวจสอบการเปลี่ยนแปลงใน pull request ตามปกติ เพราะสเปกอยู่ใน Git เช่นเดียวกับสิ่งอื่น ๆ

นี่คือการเพิ่มเติมที่คุณจะทำในเวิร์กโฟลว์นั้น:

components:
 schemas:
 Invoice:
 type: object
 required: [id, amount, currency]
 properties:
 id:
 type: string
 format: uuid
 amount:
 type: integer
 description: Amount in the smallest currency unit
 currency:
 type: string
 example: USD
 status:
 type: string
 enum: [draft, sent, paid]

วงจรทั้งหมดอยู่ภายในเครื่องมือที่คุณเชื่อถือ สเปกคือโค้ด และคุณปฏิบัติต่อมันเหมือนโค้ด

ใครควรใช้โหมด Spec-First

โหมด Spec-First เหมาะกับบางทีมมากกว่าทีมอื่น จงซื่อสัตย์กับตัวเองว่าคุณเป็นทีมประเภทไหน

ใช้โหมด Spec-First หากทีมของคุณใช้ Git เป็นหลักอยู่แล้ว หากคุณตรวจสอบสัญญา API ใน pull requests, หากคุณต้องการให้สเปกมีเวอร์ชันควบคู่ไปกับโค้ดบริการของคุณ หรือหากวิศวกรของคุณชอบแก้ไข YAML โดยตรง โหมดนี้จะช่วยลดความขัดแย้ง มันเหมาะอย่างยิ่งสำหรับทีมแบ็กเอนด์และแพลตฟอร์มที่ถือว่าเอกสาร OpenAPI เป็นสิ่งสำคัญอันดับแรก

ให้เลือกโหมด Design-First แทน หากคุณต้องการประสบการณ์ที่แนะนำและเป็นภาพ ทีมที่มีบุคคลที่ไม่ใช่วิศวกรมีส่วนร่วมในการออกแบบ หรือใครก็ตามที่ชอบคลิกผ่านฟอร์มมากกว่าเขียน YAML จะทำงานได้เร็วกว่าในโหมดนั้น ทีมผสมที่ฝ่ายผลิตภัณฑ์และการออกแบบมีส่วนร่วมในการพิจารณาเอ็นด์พอยต์มักจะชอบโปรแกรมแก้ไขแบบภาพ ไม่มีคำตอบที่ผิด เลือกโหมดที่เหมาะสมกับวิธีการทำงานของทีมคุณจริง ๆ โพสต์เปรียบเทียบ ของเราจะเจาะลึกถึงการตัดสินใจนี้

ข้อจำกัดและหมายเหตุเกี่ยวกับเวอร์ชันเบต้า

โหมด Spec-First เป็นเวอร์ชันเบต้า คำว่า "เบต้า" นี้มีความหมายจริงจัง ดังนั้นโปรดตั้งความคาดหวังให้เหมาะสม

ในฐานะเวอร์ชันเบต้า คุณสมบัตินี้ยังอยู่ในระหว่างการพัฒนา ความสามารถและพฤติกรรมอาจเปลี่ยนแปลงได้เมื่อ Apidog ปรับปรุงโหมดตามความคิดเห็น การรวมผู้ให้บริการโดยตรงครอบคลุม GitHub และ GitLab ในปัจจุบัน ในขณะที่ Azure DevOps อาศัย Generic Git Connection แทนที่จะเป็นการรวมเฉพาะ หากทีมของคุณขึ้นอยู่กับผู้ให้บริการ Git หรือเวิร์กโฟลว์เฉพาะ โปรดยืนยันว่ามันตรงกับความต้องการของคุณก่อนที่จะนำโปรเจกต์สำคัญมาใช้ในโหมดนี้

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

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

คำถามที่พบบ่อย

โหมด Spec-First ใช้งานฟรีหรือไม่?

โหมด Spec-First เป็นคุณสมบัติเวอร์ชันเบต้าภายใน Apidog การเข้าถึงจะขึ้นอยู่กับแผน Apidog ของคุณ ดังนั้นโปรดตรวจสอบว่าโหมดนี้พร้อมใช้งานหรือไม่ตามแผนปัจจุบันของคุณและสถานะเบต้า เนื่องจากเป็นเวอร์ชันเบต้า วิธีที่ง่ายที่สุดคือเปิดใช้งานในโมดูล APIs และดูว่ามีให้ใช้งานสำหรับบัญชีของคุณหรือไม่

รองรับผู้ให้บริการ Git รายใดบ้าง?

GitHub และ GitLab รองรับการรวมโดยตรง Azure DevOps ทำงานผ่าน Generic Git Connection ซึ่งใช้ข้อมูลประจำตัว Git มาตรฐานเพื่อชี้ Apidog ไปยังพื้นที่เก็บข้อมูลของคุณ โฮสต์ Git อื่นๆ ก็อาจใช้งานได้ผ่านการเชื่อมต่อทั่วไปนั้น เนื่องจากอาศัย Git มาตรฐานแทน API เฉพาะของผู้ให้บริการ

ฉันสามารถสลับกลับไปใช้โหมด Design-First ได้หรือไม่?

ได้ สวิตช์โหมดอยู่ที่มุมล่างซ้ายของโมดูล APIs และคุณสามารถสลับระหว่าง Spec-First และ Design-First ได้ที่นั่น คุณไม่ได้ถูกจำกัด เลือกโหมดที่เหมาะสมกับโปรเจกต์ที่คุณกำลังทำอยู่

ฉันสามารถแก้ไขไฟล์ฟอร์แมตใดได้บ้าง?

คุณแก้ไขเอกสาร OpenAPI ของคุณในรูปแบบ YAML หรือ JSON ดิบในโปรแกรมแก้ไขสไตล์ IDE โปรแกรมแก้ไขมีคุณสมบัติการไฮไลต์โค้ด, การตรวจสอบ Schema และการเติมข้อความอัตโนมัติสำหรับทั้ง OpenAPI และ Swagger เพื่อให้คุณเขียนได้อย่างถูกต้องไม่ว่าจะใช้รูปแบบใด

จะเกิดอะไรขึ้นกับการแก้ไขที่ยังไม่ได้พุชของฉัน?

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

บทสรุป

Apidog Spec-First Mode รวบรวมโปรแกรมแก้ไข OpenAPI และ Git เข้าไว้ด้วยกันในที่เดียว คุณแก้ไขสเปกในรูปแบบ YAML หรือ JSON, นำทางผ่านโครงร่างที่แยกวิเคราะห์โดยอัตโนมัติ, ตรวจสอบความถูกต้องขณะที่คุณพิมพ์ และซิงค์สองทางกับ GitHub, GitLab หรือ Azure DevOps ข้อความคอมมิต, การพุช, การติดตามการเปลี่ยนแปลง และตัวบ่งชี้การซิงค์ที่ชัดเจนจะมอบเวิร์กโฟลว์ Git ที่คุณรู้จักอยู่แล้ว มาประยุกต์ใช้กับสัญญา API ของคุณ

เป็นเวอร์ชันเบต้า และมีเป้าหมายสำหรับทีมที่ใช้ Git เป็นหลักซึ่งต้องการให้สเปกเป็นซอร์สโค้ด หากคุณเป็นหนึ่งในนั้น โหมดนี้ก็น่าสนใจอย่างยิ่ง เปิดใช้งานในโมดูล APIs, เชื่อมต่อรีโพสิตอรี และลองวงจรการแก้ไข-คอมมิต-พุชเล็กๆ เพื่อทำความเข้าใจเวิร์กโฟลว์ เมื่อคุณพร้อม ลองใช้โหมด Spec-First ในเอกสารประกอบ และเชื่อมต่อกับรีโพสิตอรีที่คุณเชื่อถือ