โดยทั่วไปแล้วเราควรพัฒนาห้องสมุดลูกค้าสำหรับบริการ REST เพื่อช่วยป้องกันการแตกของ API หรือไม่

เรามีโครงการที่รหัส UI จะได้รับการพัฒนาโดยทีมเดียวกัน แต่ในภาษาอื่น (Python / Django) จากชั้นบริการ (REST / Java) รหัสสำหรับแต่ละชั้นออกจากที่เก็บรหัสที่แตกต่างกันและสามารถติดตามรอบการเปิดตัวที่แตกต่างกัน ฉันพยายามหากระบวนการที่จะป้องกัน / ลดการเปลี่ยนแปลงในเลเยอร์บริการจากมุมมองของเลเยอร์ UI

ฉันคิดว่าจะเขียนการทดสอบการรวมที่ระดับเลเยอร์ UI ที่เราจะเรียกใช้เมื่อใดก็ตามที่เราสร้าง UI หรือเลเยอร์บริการ (เรากำลังใช้ Jenkins เป็นเครื่องมือ CI ของเราในการสร้างรหัสซึ่งอยู่ใน repos Git สอง) และถ้า มีความล้มเหลวดังนั้นบางสิ่งในเลเยอร์บริการแตกและการยอมรับไม่ยอมรับ

มันจะเป็นความคิดที่ดี (มันเป็นวิธีปฏิบัติที่ดีที่สุดหรือไม่) เพื่อให้ผู้พัฒนาเลเยอร์บริการสร้างและบำรุงรักษาไลบรารีไคลเอ็นต์สำหรับบริการ REST ที่มีอยู่ในเลเยอร์ UI ที่พวกเขาจะอัปเดตเมื่อใดก็ตามที่มีการเปลี่ยนแปลง Service API ของพวกเขา น่าจะเป็นไปได้ว่าเราจะได้ประโยชน์จาก API ที่พิมพ์แบบคงที่ซึ่งรหัส UI นั้นสร้างขึ้นมา หาก API ของไลบรารีไคลเอ็นต์เปลี่ยนแปลงรหัส UI จะไม่รวบรวม (ดังนั้นเราจะทราบได้เร็วว่ามีการเปลี่ยนแปลงที่ไม่คาดคิด) ฉันยังคงทำการทดสอบการรวมระบบเมื่อสร้าง UI หรือเลเยอร์บริการเพื่อตรวจสอบเพิ่มเติมว่าการรวมระหว่าง UI และบริการยังคงทำงานอยู่

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

การเข้าสู่ระบบภายใน service API เป็นสิ่งหนึ่ง แต่การแจ้งเตือนลูกค้าที่ใช้งานก็เป็นอีกเรื่องหนึ่ง สำหรับ REST ฉันไม่คิดว่าจะมีการฝึกฝนที่แข็งแกร่งและเป็นมาตรฐาน ไคลเอนต์ FourSquare API สามารถค้นพบวิธีที่ไม่สนับสนุนแม้ว่าวิธีการที่เรียกใช้นั้นสำเร็จแล้ว (รหัส HTTP 200 อย่างไรก็ตาม errorType จะถูกตั้งค่าเป็น 'ไม่สนับสนุน') อาจเป็นกลยุทธ์ที่สมเหตุสมผลในการให้โอกาสลูกค้าในการบริโภคความรู้เกี่ยวกับวิธีการที่เลิกใช้ภายใน API โดยไม่ทำให้เกิดการละเมิด

https://developer.foursquare.com/overview/responses

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

การกำหนดเวอร์ชัน API ของคุณเป็นไปได้อีกอย่างหนึ่ง เมื่อมีการปรับใช้เวอร์ชันใหม่ปล่อยให้เวอร์ชันเก่าแอ็คทีฟด้วยและอนุญาตการเจรจาผ่านการร้องขอ หากคุณรักษาเวอร์ชัน 2 หรือ 3 ล่าสุดไว้ดังนั้นโค้ด UI สามารถอัปเกรดได้ตามความต้องการ

มีคำถามอย่างน้อยสามข้อในคราวนี้มาทำทีละข้อ

• "เป็นความคิดที่ดีหรือไม่ที่มีห้องสมุดลูกค้าสำหรับบริการ REST?"

อาจเป็นไปได้ว่าตราบใดที่คุณไม่ต้องการให้มีการโทรผ่าน REST แบบสุ่มโดยตรงผ่านรหัส UI ทั้งหมด

• "เป็นความคิดที่ดีหรือไม่ที่จะให้ผู้พัฒนาเลเยอร์บริการสร้างและบำรุงรักษา lib"

ขึ้นอยู่กับบุคคลในทีมของคุณ ผู้ดูแลระบบของ API ควรรู้ทั้งสิ่งที่มีอยู่ในชั้นบริการรวมถึงข้อกำหนดของชั้น UI ดังนั้นอาจเป็นได้ทั้งบุคคลจากเลเยอร์บริการหรือหนึ่งคนจากเลเยอร์ UI หรือ (ขึ้นอยู่กับขนาดและงานอื่น ๆ ) บุคคลที่เป็นอิสระจากทั้งสองทีม

• [เราจะได้รับประโยชน์จากข้อเท็จจริงที่ว่า] "หรือไม่หากไคลเอ็นต์ไลบรารี API เปลี่ยนแปลงรหัส UI จะไม่รวบรวม"

คุณไม่ได้พูดว่า UI จะถูกเขียนใน Python หรือไม่? นั่นไม่ใช่ภาษาที่พิมพ์แบบคงที่ดังนั้นฉันจะไม่คาดหวังว่าตัวแบ่งการสร้างทันทีจากการเปลี่ยนแปลง API ฉันคิดว่าคุณเข้าใจผิด ณ จุดนี้และคุณมี API ที่พิมพ์แบบคงที่ที่นี่ - จากนั้นคุณอาจได้รับประโยชน์บางอย่างที่นี่ตราบใดที่บิลด์ไม่แตกเมื่อเพิ่งเพิ่มฟีเจอร์ใหม่ (เช่นพารามิเตอร์ทางเลือกใหม่)ไปยัง API ไม่เช่นนั้นคุณจะผลิตงานที่ไม่จำเป็นจำนวนมากให้กับทีมของคุณ