4
คุณจัดการโค้ดเบสสำหรับ API เวอร์ชันได้อย่างไร
ฉันได้อ่านข้อมูลเกี่ยวกับกลยุทธ์การกำหนดเวอร์ชันสำหรับ ReST APIs และสิ่งที่ดูเหมือนว่าไม่มีที่อยู่คือวิธีที่คุณจัดการ codebase ที่สำคัญ สมมติว่าเรากำลังทำการเปลี่ยนแปลงหลายอย่างกับ API ตัวอย่างเช่นการเปลี่ยนทรัพยากรของลูกค้าเพื่อให้ส่งกลับแยกforenameและsurnameฟิลด์แทนที่จะเป็นnameฟิลด์เดียว (สำหรับตัวอย่างนี้ฉันจะใช้โซลูชันการกำหนดเวอร์ชัน URL เนื่องจากง่ายต่อการทำความเข้าใจแนวคิดที่เกี่ยวข้อง แต่คำถามนี้ใช้ได้กับการต่อรองเนื้อหาหรือส่วนหัว HTTP ที่กำหนดเอง) ขณะนี้เรามีปลายทางที่และอีกปลายทางที่เข้ากันไม่ได้http://api.mycompany.com/v1/customers/{id} http://api.mycompany.com/v2/customers/{id}เรายังคงปล่อยการแก้ไขข้อบกพร่องและการอัปเดตความปลอดภัยให้กับ v1 API แต่การพัฒนาฟีเจอร์ใหม่ทั้งหมดมุ่งเน้นไปที่ v2 เราจะเขียนทดสอบและปรับใช้การเปลี่ยนแปลงในเซิร์ฟเวอร์ API ของเราได้อย่างไร ฉันเห็นวิธีแก้ปัญหาอย่างน้อยสองวิธี: ใช้สาขา / แท็กควบคุมแหล่งที่มาสำหรับ v1 codebase v1 และ v2 ได้รับการพัฒนาและปรับใช้อย่างอิสระโดยมีการผสานการควบคุมการแก้ไขที่ใช้ตามความจำเป็นเพื่อใช้การแก้ไขข้อบกพร่องเดียวกันกับทั้งสองเวอร์ชันซึ่งคล้ายกับวิธีที่คุณจัดการโค้ดเบสสำหรับแอปเนทีฟเมื่อพัฒนาเวอร์ชันใหม่ที่สำคัญในขณะที่ยังคงรองรับเวอร์ชันก่อนหน้า ทำให้ codebase ทราบถึงเวอร์ชันของ API ดังนั้นคุณจึงลงเอยด้วย codebase เดียวที่มีทั้งตัวแทนลูกค้า v1 และตัวแทนลูกค้า v2 ถือว่าการกำหนดเวอร์ชันเป็นส่วนหนึ่งของสถาปัตยกรรมโซลูชันของคุณแทนที่จะเป็นปัญหาในการปรับใช้ - อาจใช้เนมสเปซและการกำหนดเส้นทางร่วมกันเพื่อให้แน่ใจว่าคำขอได้รับการจัดการโดยเวอร์ชันที่ถูกต้อง ข้อได้เปรียบที่ชัดเจนของโมเดลสาขาคือการลบเวอร์ชัน API เก่านั้นเป็นเรื่องเล็กน้อยเพียงแค่หยุดการปรับใช้สาขา …