คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่
เอกสารประกอบของ Apigee X info
ส่วนต่อไปนี้จะแนะนำให้คุณรู้จักกับ ผลิตภัณฑ์ API และ แนวคิดหลักที่เกี่ยวข้อง
ผลิตภัณฑ์ API คืออะไร
ในฐานะผู้ให้บริการ API คุณสร้างผลิตภัณฑ์ API เพื่อรวม API ของคุณไว้ด้วยกันและทำให้พร้อมใช้งาน สำหรับนักพัฒนาแอป คุณสามารถคิดว่าผลิตภัณฑ์ API เป็นสายผลิตภัณฑ์ของคุณ
โดยเฉพาะอย่างยิ่ง ผลิตภัณฑ์ API จะรวมสิ่งต่อไปนี้ไว้ด้วยกัน
- คอลเล็กชันทรัพยากร API (URI)
- แพ็กเกจบริการ
- ข้อมูลเมตาที่เฉพาะเจาะจงกับธุรกิจของคุณสำหรับการตรวจสอบหรือการวิเคราะห์ (ไม่บังคับ)
ทรัพยากร API ที่รวมอยู่ในผลิตภัณฑ์ API อาจมาจาก API อย่างน้อย 1 รายการ ดังนั้นคุณจึงสามารถผสมและจับคู่ ทรัพยากรเพื่อสร้างชุดฟีเจอร์เฉพาะได้ ดังที่แสดงในรูปภาพต่อไปนี้
คุณสามารถสร้างผลิตภัณฑ์ API หลายรายการเพื่อตอบสนองกรณีการใช้งานที่แก้ปัญหาความต้องการเฉพาะ เช่น คุณสามารถสร้างผลิตภัณฑ์ API ที่รวมทรัพยากรการแมปจำนวนหนึ่งเพื่อให้ผู้พัฒนาสามารถผสานรวม Maps เข้ากับแอปพลิเคชันของตนได้อย่างง่ายดาย นอกจากนี้ คุณยังตั้งค่าพร็อพเพอร์ตี้ที่แตกต่างกันในผลิตภัณฑ์ API แต่ละรายการได้ เช่น ระดับราคาที่แตกต่างกัน ตัวอย่างเช่น คุณอาจเสนอชุดผลิตภัณฑ์ API ต่อไปนี้
- ผลิตภัณฑ์ API ที่มีขีดจำกัดการเข้าถึงต่ำ เช่น คำขอ 1,000 รายการต่อวัน ในราคาที่ถูก ผลิตภัณฑ์ API ที่ 2 ซึ่งให้สิทธิ์เข้าถึงทรัพยากรเดียวกัน แต่มีขีดจำกัดการเข้าถึงสูงกว่าและราคาสูงกว่า
- ผลิตภัณฑ์ API ฟรีที่ให้สิทธิ์เข้าถึงทรัพยากรแบบอ่านอย่างเดียว ผลิตภัณฑ์ API ที่ 2 ซึ่งให้สิทธิ์เข้าถึงทรัพยากรเดียวกันแบบอ่าน/เขียนโดยมีค่าใช้จ่ายเล็กน้อย
นอกจากนี้ คุณยังควบคุมการเข้าถึงทรัพยากร API ในผลิตภัณฑ์ API ได้ด้วย เช่น คุณสามารถรวม ทรัพยากรที่นักพัฒนาภายในเท่านั้นหรือลูกค้าที่ชำระเงินเท่านั้นเข้าถึงได้
ผลิตภัณฑ์ API เป็นกลไกส่วนกลางสำหรับการให้สิทธิ์และการควบคุมการเข้าถึง API ใน Apigee ระบบจะจัดเตรียมคีย์ API ไม่ใช่สำหรับ API เอง แต่สำหรับผลิตภัณฑ์ API กล่าวอีกนัยหนึ่งคือ ระบบจะจัดเตรียมคีย์ API สำหรับชุดทรัพยากรที่มีแพ็กเกจบริการแนบอยู่
นักพัฒนาแอปเข้าถึงผลิตภัณฑ์ API ของคุณได้โดยการลงทะเบียนแอปของตนเองตามที่อธิบายไว้ในหัวข้อการลงทะเบียนแอป เมื่อแอปพยายามเข้าถึงผลิตภัณฑ์ API ระบบจะบังคับใช้การให้สิทธิ์โดย Apigee ในรันไทม์เพื่อให้แน่ใจว่า
- แอปที่ส่งคำขอได้รับอนุญาตให้เข้าถึงทรัพยากร API ที่เฉพาะเจาะจง
- แอปที่ส่งคำขอไม่ได้ใช้โควต้าเกินที่อนุญาต
- หากมีการกำหนดไว้ ขอบเขต OAuth ที่กำหนดไว้ในผลิตภัณฑ์ API จะต้องตรงกับขอบเขตที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึง ที่แอปแสดง
ทำความเข้าใจแนวคิดหลัก
โปรดอ่านแนวคิดหลักต่อไปนี้ก่อนสร้างผลิตภัณฑ์ API
คีย์ API
เมื่อคุณลงทะเบียนแอปของนักพัฒนาแอปในองค์กร แอปดังกล่าวต้องเชื่อมโยงกับผลิตภัณฑ์ API อย่างน้อย 1 รายการ เมื่อจับคู่แอปกับผลิตภัณฑ์ API อย่างน้อย 1 รายการ Edge จะกำหนดคีย์ผู้ใช้ที่ไม่ซ้ำกันให้กับแอป
พอร์ทัลแบบผสานรวมไม่รองรับคีย์ผู้ใช้หรือโทเค็นเพื่อการเข้าถึงจะทำหน้าที่เป็นข้อมูลเข้าสู่ระบบของคำขอ นักพัฒนาแอปจะฝังคีย์ผู้ใช้ลงในแอป เพื่อให้เมื่อแอปส่งคำขอ ไปยัง API ที่โฮสต์โดย Edge แอปจะส่งคีย์ผู้ใช้ในคำขอด้วยวิธีใดวิธีหนึ่งต่อไปนี้
- เมื่อ API ใช้การยืนยันคีย์ API แอปต้องส่งคีย์ผู้ใช้โดยตรง
- เมื่อ API ใช้การยืนยันโทเค็น OAuth แอปต้องส่งโทเค็นที่ได้มาจากคีย์ผู้ใช้
การบังคับใช้คีย์ API จะไม่เกิดขึ้นโดยอัตโนมัติ ไม่ว่าจะใช้คีย์ผู้ใช้หรือโทเค็น OAuth เป็นข้อมูลเข้าสู่ระบบของคำขอ พร็อกซี API จะตรวจสอบข้อมูลเข้าสู่ระบบของคำขอใน พร็อกซี API โดยรวมนโยบาย VerifyAPIKey หรือนโยบาย OAuth/VerifyAccessToken ไว้ในโฟลว์ที่เหมาะสม หากคุณไม่รวมนโยบายการบังคับใช้ข้อมูลเข้าสู่ระบบไว้ใน พร็อกซี API ผู้เรียกทุกคนจะเรียกใช้ API ของคุณได้ ดูข้อมูลเพิ่มเติมได้ที่ ดู นโยบาย Verify API Key
Edge จะทำตามขั้นตอนต่อไปนี้เพื่อยืนยันข้อมูลเข้าสู่ระบบที่ส่งในคำขอ
- รับข้อมูลเข้าสู่ระบบที่ส่งมาพร้อมกับคำขอ ในกรณีของการยืนยันโทเค็น OAuth Edge จะยืนยันว่าโทเค็นยังไม่หมดอายุ จากนั้นค้นหาคีย์ผู้บริโภค ที่ใช้สร้างโทเค็น
- ดึงข้อมูลรายการผลิตภัณฑ์ API ที่เชื่อมโยงกับคีย์ผู้ใช้
- ยืนยันว่าพร็อกซี API ปัจจุบันรวมอยู่ในผลิตภัณฑ์ API และหากมีการเปิดใช้ เส้นทางทรัพยากรปัจจุบัน (เส้นทาง URL) ในผลิตภัณฑ์ API
- ยืนยันว่าคีย์ผู้ใช้ยังไม่หมดอายุหรือถูกเพิกถอน ตรวจสอบว่าแอปยังไม่ถูกเพิกถอน, และตรวจสอบว่านักพัฒนาแอปยังใช้งานอยู่
หากการตรวจสอบทั้งหมดข้างต้นผ่าน การยืนยันข้อมูลเข้าสู่ระบบจะสำเร็จ
สรุปคือ Edge จะสร้างคีย์ผู้บริโภคโดยอัตโนมัติ แต่ผู้เผยแพร่ API ต้อง บังคับใช้การตรวจสอบคีย์ในพร็อกซี API โดยใช้นโยบายที่เหมาะสม
การอนุมัติอัตโนมัติเทียบกับการอนุมัติด้วยตนเอง
โดยค่าเริ่มต้น ระบบจะอนุมัติคำขอทั้งหมดเพื่อรับคีย์ในการเข้าถึงผลิตภัณฑ์ API จากแอปโดยอัตโนมัติ หรือคุณจะกำหนดค่าผลิตภัณฑ์ API ให้อนุมัติคีย์ด้วยตนเองก็ได้ ในกรณีนี้ คุณจะต้องอนุมัติคำขอคีย์จากแอปที่เพิ่ม ผลิตภัณฑ์ API ดูข้อมูลเพิ่มเติมได้ที่ ลงทะเบียนแอปและจัดการคีย์ API คีย์
โควต้า
โควต้าสามารถปกป้องเซิร์ฟเวอร์แบ็กเอนด์จากปริมาณการเข้าชมสูง และแยกความแตกต่างของสายผลิตภัณฑ์ ตัวอย่างเช่น คุณอาจต้องการรวมทรัพยากรที่มีโควต้าสูงไว้เป็นผลิตภัณฑ์ระดับพรีเมียม และใช้ ชุดทรัพยากรเดียวกันที่มีโควต้าต่ำกว่าเป็นผลิตภัณฑ์พื้นฐาน โควต้าสามารถช่วยปกป้องเซิร์ฟเวอร์ไม่ให้ทำงานหนักเกินไปหากผลิตภัณฑ์ได้รับความนิยมและได้รับคำขอจำนวนมาก
ดูข้อมูลเกี่ยวกับการกำหนดค่าโควต้าได้ที่นโยบายโควต้า ดูข้อมูลเกี่ยวกับการใช้การตั้งค่าโควต้าผลิตภัณฑ์ในนโยบายโควต้าได้ที่บทความในชุมชนต่อไปนี้ How do the quota settings on an API product interact with quota policies in an API proxy?
ขอบเขต OAuth
คุณสามารถกำหนดขอบเขต OAuth ใดก็ได้เป็นรายการที่คั่นด้วยคอมมา ซึ่งต้องอยู่ในโทเค็นเพื่อการเข้าถึงที่ส่งผ่านผลิตภัณฑ์ เพื่อเพิ่มความปลอดภัยอีกระดับ เมื่อสร้างผลิตภัณฑ์ คุณต้องทราบขอบเขตทั้งหมดที่องค์กรใช้ ขอบเขตที่คุณเพิ่มลงในผลิตภัณฑ์ ต้องตรงกับขอบเขตที่มีอยู่ มิเช่นนั้นผลิตภัณฑ์จะไม่ปลอดภัย
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ขอบเขตกับนโยบาย OAuth ของ Edge ได้ที่หัวข้อ การทำงานกับขอบเขต OAuth2
ระดับการเข้าถึง
เมื่อกำหนดผลิตภัณฑ์ API คุณสามารถตั้งค่าระดับการเข้าถึงต่อไปนี้ได้
| ระดับการเข้าถึง | คำอธิบาย |
|---|---|
| สาธารณะ | ผลิตภัณฑ์ API ที่พร้อมให้บริการแก่นักพัฒนาแอปทุกคน คุณสามารถเพิ่มผลิตภัณฑ์ API เหล่านี้ลงในพอร์ทัลนักพัฒนาแอปแบบผสานรวมหรือแบบ Drupal ได้ |
| ส่วนตัวหรือภายในเท่านั้น | ผลิตภัณฑ์ API ที่ออกแบบมาเพื่อการใช้งานส่วนตัวหรือภายใน หมายเหตุ: ระดับการเข้าถึงส่วนตัวและภายในเท่านั้นไม่มีความแตกต่างด้านฟังก์ชันการทำงาน โปรดเลือกป้ายกำกับที่อธิบายกลุ่มเป้าหมายที่ต้องการของผลิตภัณฑ์ API ได้ดีที่สุด สำหรับพอร์ทัลแบบผสานรวม คุณสามารถเพิ่มผลิตภัณฑ์ API ส่วนตัวหรือภายในเท่านั้น และทำให้พร้อมใช้งานสำหรับนักพัฒนาแอปได้ตามต้องการ สำหรับพอร์ทัลนักพัฒนาซอฟต์แวร์แบบ Drupal คุณสามารถจัดการการเข้าถึงผลิตภัณฑ์ API ส่วนตัวหรือภายในเท่านั้นในพอร์ทัลนักพัฒนาซอฟต์แวร์ได้ตามที่อธิบายไว้ในส่วนต่อไปนี้
|