คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล
ทุกองค์กรมีวงจรการพัฒนาซอฟต์แวร์ (SDLC) ที่แตกต่างกัน เรามักจำเป็นต้องซิงค์ข้อมูลและปรับการติดตั้งใช้งานพร็อกซี API ให้สอดคล้องกับกระบวนการเดียวกันกับที่ใช้อยู่ในปัจจุบันเพื่อการพัฒนา ทดสอบ และการทำให้แอปพลิเคชันอื่นๆ ใช้งานได้
บริการ API มีเครื่องมือและ RESTful API ที่ช่วยให้คุณผสานรวมการจัดการและการติดตั้งใช้งานพร็อกซี API เข้ากับ SDLC ขององค์กรได้ การใช้งานทั่วไปของ RESTful API คือการเขียนสคริปต์หรือโค้ดที่ทำให้พร็อกซี API ใช้งานได้แบบเป็นโปรแกรม หรือย้ายข้อมูลพร็อกซี API จากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่ง ซึ่งเป็นส่วนหนึ่งของกระบวนการอัตโนมัติขนาดใหญ่ที่ต้องทำให้แอปพลิเคชันอื่นใช้งานได้หรือย้ายแอปพลิเคชันอื่นด้วย บริการ API จะไม่ตั้งข้อสันนิษฐานเกี่ยวกับ SDLC ของคุณ (หรือของใครก็ตาม) ในเรื่องนั้น แต่จะแสดงฟังก์ชันอะตอมที่ทีมพัฒนาของคุณได้ประสานงานกันเพื่อทำให้วงจรการพัฒนา API เป็นแบบอัตโนมัติและเพิ่มประสิทธิภาพ
API ของบริการ API มีการบันทึกไว้ในเอกสารการอ้างอิง API โปรดดูการเริ่มต้นใช้งานข้อมูลอ้างอิง API
ดูวิดีโอนี้สำหรับข้อมูลเบื้องต้นเกี่ยวกับสภาพแวดล้อม API และวงจรการพัฒนา API
สภาพแวดล้อม
ทุกองค์กรใน Apigee Edge มีสภาพแวดล้อมการติดตั้งใช้งานอย่างน้อย 2 แบบที่พร้อมสำหรับพร็อกซี API ได้แก่ "test" และ "prod" สภาพแวดล้อมทั้ง 2 แบบแตกต่างกันอย่างไร แต่ละสภาพแวดล้อมจะระบุได้ง่ายๆ ด้วยชุดที่อยู่เครือข่าย (URL) ที่ต่างกัน เป้าหมายคือการมอบโดเมนที่จะใช้สร้างและยืนยันพร็อกซีของ API ก่อนที่นักพัฒนาซอฟต์แวร์ภายนอกจะเปิดเผย API ดังกล่าว
คุณใช้สภาพแวดล้อมเหล่านี้เพื่อซิงค์ข้อมูลการพัฒนาพร็อกซี API ที่ประมวลผลด้วย SDLC ได้ สภาพแวดล้อมแต่ละแบบจะกำหนดโดยที่อยู่เครือข่าย ซึ่งช่วยให้คุณแยกการรับส่งข้อมูลระหว่างพร็อกซี API ที่ทำงานอยู่และที่แอปที่แอปเข้าถึงขณะรันไทม์ได้ ระบบจะกำหนดที่อยู่เครือข่ายที่ใช้ได้สำหรับแต่ละสภาพแวดล้อมไว้ในชุดของ VirtualHosts ที่ใช้ได้ในสภาพแวดล้อมนั้น
ขาเข้า TLS/SSL ของเซิร์ฟเวอร์จะเปิดใช้โดยอัตโนมัติสำหรับแต่ละสภาพแวดล้อม VirtualHost จำนวน 2 รายการมีคำจำกัดความล่วงหน้าในแต่ละสภาพแวดล้อม: default
และ secure
ค่าเริ่มต้นจะกำหนดที่อยู่ HTTP ส่วนการรักษาความปลอดภัยจะกำหนดที่อยู่ HTTP/S ด้วย TLS/SSL ฝั่งเซิร์ฟเวอร์ที่กำหนดค่าไว้ล่วงหน้า ในการกำหนดค่าพร็อกซี API คุณระบุ VirtualHost ที่ ProxyEndpoint ควรรับสัญญาณ
เมื่อโปรโมตไปยัง Prod โดยทั่วไปคุณจะปิดใช้ HTTP ด้วยการนำ default
VirtualHost ออกจากการกำหนดค่าพร็อกซี API
ตัวอย่างเช่น ProxyEndpoint ต่อไปนี้จะคอยฟังคำสั่ง HTTP และ HTTPS
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>default</VirtualHost> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
การลบ default
VirtualHost ออกจากการกำหนดค่า ProxyEndpoint จะเป็นการสร้างพร็อกซี API ที่ฟังเฉพาะใน HTTPS เท่านั้น ไม่ใช่บน HTTP
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
คุณดูได้ว่า VirtualHost ใดมีอยู่ในสภาพแวดล้อมโดยเลือกสภาพแวดล้อมในเมนูหลัก UI การจัดการ
นอกจากนี้ สภาพแวดล้อมยังช่วยแยกข้อมูลและทรัพยากรอีกด้วย ตัวอย่างเช่น คุณอาจตั้งค่าแคชที่แตกต่างกันในการทดสอบและ Pro ซึ่งเข้าถึงได้ผ่านพร็อกซี API ที่ดำเนินการในสภาพแวดล้อมดังกล่าวเท่านั้น นอกจากนี้ คีย์ API ที่ออกในสภาพแวดล้อมการทดสอบจะใช้ไม่ได้ในสภาพแวดล้อมของผลิตภัณฑ์ และในทางกลับกันด้วย
การทำให้พร็อกซี API ใช้งานได้ในสภาพแวดล้อม
เมื่อสร้างพร็อกซี API คุณต้องเลือกสภาพแวดล้อมที่จะใช้งาน คุณเลือกสร้างพร็อกซี API ใหม่ในเวอร์ชันที่ใช้งานจริงได้ แต่เราไม่แนะนำให้ทำเนื่องจากคุณอาจแสดง API แก่นักพัฒนาซอฟต์แวร์ก่อนที่ API ดังกล่าวจะพร้อมให้ใช้งาน โดยทั่วไป ให้เริ่มต้นด้วยการสร้างพร็อกซี API ใน
test
ซึ่งหลังจากการทดสอบ คุณจะโปรโมตเป็น
prod
ดูข้อมูลเพิ่มเติมได้ที่การทำความเข้าใจการทำให้ใช้งานได้
การพัฒนาซ้ำๆ ในการทดสอบ
ขณะที่คุณใช้งานพร็อกซี API บริการ API จะบันทึกการกำหนดค่าซ้ำเป็นการแก้ไข เมื่อทำให้พร็อกซี API ใช้งานได้ คุณจะเลือกการแก้ไขที่ต้องการทำให้ใช้งานได้ โดยปกติแล้ว คุณจะทำให้การแก้ไขล่าสุดใช้งานได้ และหากจำเป็น ให้เปลี่ยนกลับไปใช้หมายเลขการแก้ไขก่อนหน้า คุณเลือกได้ว่าจะให้การแก้ไขเหล่านั้นใช้งานได้ที่ใด ตัวอย่างเช่น คุณโปรโมตการแก้ไขเป็นเวอร์ชันที่ใช้งานจริงได้เพื่อให้นักพัฒนาซอฟต์แวร์เริ่มทำงานกับ API ของคุณได้ ในขณะเดียวกัน คุณอาจปรับปรุงการแก้ไขหลายรายการในการทดสอบโดยที่คุณกําลังเพิ่มฟีเจอร์หรือนโยบายที่ปรับแต่ง จากนั้นเมื่อพร้อม คุณก็ทำให้การแก้ไขใหม่ใช้งานได้ในเวอร์ชันที่ใช้งานจริง ซึ่งจะเขียนทับการแก้ไขที่มีอยู่ในสภาพแวดล้อมนั้น เมื่อใช้วิธีนี้ คุณจะมีเวอร์ชันสำหรับ API ที่พร้อมให้นักพัฒนาซอฟต์แวร์ใช้งานเสมอขณะพัฒนาได้
โปรโมตเป็นเวอร์ชันที่ใช้งานจริง
เมื่อมีการใช้และทดสอบพร็อกซี API อย่างสมบูรณ์แล้ว พร็อกซีก็จะพร้อมได้รับการเลื่อนระดับเป็น "prod" ระบบจะใช้การแก้ไขพร็อกซี API ในการทดสอบเพื่อเขียนทับการแก้ไขพร็อกซี API ที่ทำให้ใช้งานได้ใน prod
บริการ API มอบความสามารถในการใช้งานพร็อกซี API ที่ราบรื่น ช่วยลดผลกระทบต่อแอปและผู้ใช้ปลายทางระหว่างกระบวนการทำให้ใช้งานได้
การติดตั้งใช้งานสคริปต์
UI การจัดการ Apigee Edge ช่วยให้คุณทำให้พร็อกซี API ใช้งานได้เพื่อสร้างผลิตภัณฑ์ได้โดยตรงจากเครื่องมือสร้างพร็อกซี API อย่างไรก็ตาม ในหลายๆ สถานการณ์จะต้องมีข้อกำหนดด้านความปลอดภัย ความน่าเชื่อถือ และความสอดคล้องที่ทีมพัฒนาสคริปต์กำหนดให้ใช้กระบวนการติดตั้งใช้งานสคริปต์ ดังนั้นให้เขียนโค้ดและสคริปต์ที่เรียกใช้ RESTful API ที่บริการ API แสดง
ทรัพยากรด้านสภาพแวดล้อม
สำหรับการควบคุมเพิ่มเติมในระหว่างการโปรโมต ขอแนะนำให้คุณทำซ้ำเฉพาะบนพร็อกซี API ในการทดสอบเท่านั้น และทำการเปลี่ยนแปลงให้น้อยที่สุดเท่าที่จำเป็นกับพร็อกซี API ที่ทำให้ใช้งานได้ในเวอร์ชันผลิตภัณฑ์
ในการทำเช่นนั้น คุณต้องตรวจสอบว่าทรัพยากรบางรายการที่เชื่อมโยงกับสภาพแวดล้อมแต่ละรายการได้รับการกำหนดค่าในลักษณะที่ยังคงเหมือนเดิมในการกำหนดค่าพร็อกซี API
- URL เป้าหมาย: เป็นเรื่องปกติที่พร็อกซี API จะเรียก URL แบ็กเอนด์ที่แตกต่างกันระหว่างการทดสอบและเวอร์ชันที่ใช้งานจริง คุณใช้การกำหนดค่า TargetServer เพื่อสร้างการกำหนดค่า TargetEndpoint ที่ไม่ขึ้นอยู่กับสภาพแวดล้อมได้ โปรดดูหัวข้อการจัดสรรภาระงานในเซิร์ฟเวอร์แบ็กเอนด์
- แคชและแมปคีย์/ค่า: ทรัพยากรความต่อเนื่องทั้งสองจะกำหนดขอบเขตตามสภาพแวดล้อม คุณควรตรวจสอบว่ามีการใช้แบบแผนการตั้งชื่อเพื่อเปิดใช้พร็อกซี API เพื่อจัดเก็บข้อมูลโดยไม่ต้องเปลี่ยนแปลงการกำหนดค่าระหว่างโปรโมชัน ดูการสร้างและแก้ไขแคชของสภาพแวดล้อม
- เป้าหมาย Serviceคำขอราคาเสนอ: ไฮไลต์ของบริการอาจใช้เป้าหมายที่แตกต่างกันโดยขึ้นอยู่กับสภาพแวดล้อม เช่น ในกรณีที่ Serviceที่แตกต่างกัน ในสภาพแวดล้อมการทดสอบต้องใช้บริการเดโม ดูนโยบายคำขอราคาเสนอบริการ
หากต้องการทำให้การกำหนดค่าพร็อกซี API ไม่ขึ้นอยู่กับสภาพแวดล้อม คุณจะใช้คำสั่งแบบมีเงื่อนไขได้ด้วย คำสั่งแบบมีเงื่อนไขที่สร้างด้วยตัวแปร environment.name
จะใช้เพื่อประเมินสภาพแวดล้อมปัจจุบันก่อนบังคับใช้นโยบายหรือก่อนกำหนดเส้นทางไปยัง URL บนแบ็กเอนด์ได้
โปรดดูข้อมูลเพิ่มเติมที่หัวข้อทำความเข้าใจการทำให้ใช้งานได้