คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล
ส่วนต่อไปนี้จะแนะนำคุณเกี่ยวกับผลิตภัณฑ์ API และแนวคิดหลักที่เกี่ยวข้อง
ผลิตภัณฑ์ API คืออะไร
ในฐานะผู้ให้บริการ API คุณจะสร้างผลิตภัณฑ์ API เพื่อรวม API และทำให้นักพัฒนาแอปใช้งานผลิตภัณฑ์ดังกล่าวได้ คุณอาจคิดว่าผลิตภัณฑ์ API เป็นสายผลิตภัณฑ์ของคุณก็ได้
กล่าวโดยเจาะจงก็คือผลิตภัณฑ์ API จะรวมกลุ่มสิ่งต่อไปนี้เข้าด้วยกัน
- คอลเล็กชันของทรัพยากร API (URI)
- แผนบริการ
- ข้อมูลเมตาเฉพาะสำหรับธุรกิจของคุณเพื่อการตรวจสอบหรือการวิเคราะห์ (ไม่บังคับ)
ทรัพยากร API ที่รวมกลุ่มอยู่ในผลิตภัณฑ์ API อาจมาจาก API อย่างน้อย 1 รายการ คุณจึงผสมผสานทรัพยากรเพื่อสร้างชุดฟีเจอร์เฉพาะได้ ดังที่แสดงในรูปภาพต่อไปนี้
คุณสร้างผลิตภัณฑ์ API หลายรายการเพื่อจัดการกับกรณีการใช้งานที่ตอบสนองความต้องการเฉพาะได้ ตัวอย่างเช่น คุณอาจสร้างผลิตภัณฑ์ API ที่รวมทรัพยากรการแมปหลายรายการเข้าด้วยกัน เพื่อให้นักพัฒนาซอฟต์แวร์ผสานรวมแผนที่เข้ากับแอปพลิเคชันของตนได้อย่างง่ายดาย นอกจากนี้ คุณยังตั้งค่าพร็อพเพอร์ตี้ที่แตกต่างกันในผลิตภัณฑ์ API แต่ละรายการได้ เช่น ระดับราคาที่แตกต่างกัน ตัวอย่างเช่น คุณอาจนำเสนอชุดผลิตภัณฑ์ API ต่อไปนี้
- ผลิตภัณฑ์ API ที่มีขีดจำกัดการเข้าถึงต่ำ เช่น คำขอ 1,000 รายการต่อวันในราคาที่ต่อรองได้ ผลิตภัณฑ์ API ที่สองที่ให้สิทธิ์เข้าถึงทรัพยากรเดียวกัน แต่มีขีดจำกัดการเข้าถึงสูงกว่าและมีราคาสูงกว่า
- ผลิตภัณฑ์ API ฟรีที่เสนอสิทธิ์การเข้าถึงทรัพยากรในแบบอ่านอย่างเดียว ผลิตภัณฑ์ API ที่สองที่ให้สิทธิ์อ่าน/เขียนทรัพยากรเดียวกันโดยมีค่าใช้จ่ายเพียงเล็กน้อย
นอกจากนี้ คุณยังควบคุมการเข้าถึงทรัพยากร API ในผลิตภัณฑ์ API ได้ด้วย เช่น คุณอาจรวมทรัพยากรที่นักพัฒนาซอฟต์แวร์ภายในเท่านั้นเข้าถึงได้ หรือโดยลูกค้าที่ชำระเงินเท่านั้น
ผลิตภัณฑ์ API เป็นกลไกหลักสำหรับการให้สิทธิ์และการควบคุมการเข้าถึง API ใน Apigee คีย์ API จะได้รับการจัดสรร ไม่ใช่สำหรับ API เอง แต่จัดสรรสำหรับผลิตภัณฑ์ API กล่าวคือ ระบบจะจัดสรรคีย์ API สำหรับแพ็กเกจทรัพยากรที่มีแผนบริการที่แนบมา
นักพัฒนาแอปเข้าถึงผลิตภัณฑ์ API ของคุณโดยการลงทะเบียนแอปตามที่อธิบายไว้ในการลงทะเบียนแอป เมื่อแอปพยายามเข้าถึงผลิตภัณฑ์ API Apigee จะบังคับใช้การให้สิทธิ์ระหว่างรันไทม์เพื่อให้แน่ใจว่า
- แอปที่ส่งคำขอได้รับอนุญาตให้เข้าถึงทรัพยากร API บางอย่าง
- แอปที่ส่งคำขอไม่เกินโควต้าที่ได้รับอนุญาต
- หากกำหนดไว้ ขอบเขต OAuth ที่กำหนดในผลิตภัณฑ์ API จะตรงกับขอบเขตที่เชื่อมโยงกับโทเค็นเพื่อการเข้าถึงที่แอปแสดง
ทำความเข้าใจแนวคิดหลัก
โปรดอ่านแนวคิดหลักต่อไปนี้ก่อนที่จะสร้างผลิตภัณฑ์ API
- คีย์ API
- การอนุมัติคีย์แบบอัตโนมัติกับการอนุมัติคีย์ด้วยตนเอง
- โควต้า
- ขอบเขตของ OAuth
- ระดับการเข้าถึง
คีย์ API
เมื่อคุณลงทะเบียนแอปของนักพัฒนาแอปในองค์กร แอปต้องเชื่อมโยงกับผลิตภัณฑ์ API อย่างน้อย 1 รายการ เนื่องจากการจับคู่แอปกับผลิตภัณฑ์ API อย่างน้อย 1 รายการ Edge จะกำหนดรหัสผู้ใช้ที่ไม่ซ้ำกันให้กับแอป
คีย์ผู้ใช้หรือโทเค็นเพื่อการเข้าถึงจะทำหน้าที่เป็นข้อมูลเข้าสู่ระบบของคำขอ นักพัฒนาแอปจะฝังคีย์ผู้บริโภคลงในแอป เพื่อที่ว่าเมื่อแอปส่งคำขอไปยัง API ที่โฮสต์โดย Edge แอปจะส่งคีย์ผู้บริโภคในคำขอด้วยวิธีใดวิธีหนึ่งต่อไปนี้
- เมื่อ API ใช้การยืนยันคีย์ API แอปจะต้องส่งรหัสผู้ใช้โดยตรง
- เมื่อ API ใช้การยืนยันโทเค็น OAuth แอปจะต้องส่งโทเค็นที่ได้มาจากรหัสผู้ใช้
การบังคับใช้คีย์ API จะไม่เกิดขึ้นโดยอัตโนมัติ พร็อกซี API จะตรวจสอบข้อมูลเข้าสู่ระบบของคำขอในพร็อกซี API โดยรวมนโยบายVerifyAPIKey หรือนโยบาย OAuth/VerifyAccessToken ไว้ในขั้นตอนที่เหมาะสมไม่ว่าจะใช้คีย์ผู้ใช้หรือโทเค็น OAuth เป็นข้อมูลเข้าสู่ระบบของคำขอ หากคุณไม่ได้ระบุนโยบายการบังคับใช้ข้อมูลเข้าสู่ระบบในพร็อกซี API ผู้โทรจะเรียกใช้ API ของคุณได้ ดูข้อมูลเพิ่มเติมได้ที่ยืนยันนโยบายคีย์ API
Edge จะทำตามขั้นตอนต่อไปนี้เพื่อยืนยันข้อมูลเข้าสู่ระบบที่ส่งไปในคำขอ
- รับข้อมูลเข้าสู่ระบบที่ส่งต่อไปกับคำขอ ในกรณีการยืนยันโทเค็น OAuth นั้น Edge จะตรวจสอบว่าโทเค็นยังไม่หมดอายุ จากนั้นจะค้นหาคีย์ผู้บริโภคที่ใช้สร้างโทเค็น
- ดึงรายการผลิตภัณฑ์ API ที่เชื่อมโยงกับคีย์ผู้ใช้
- ยืนยันว่าพร็อกซี API ปัจจุบันรวมอยู่ในผลิตภัณฑ์ API แล้ว และเปิดใช้เส้นทางทรัพยากรปัจจุบัน (เส้นทาง URL) ในผลิตภัณฑ์ API หรือไม่
- ตรวจสอบว่าคีย์ผู้บริโภคยังไม่หมดอายุหรือถูกเพิกถอน ตรวจสอบว่าไม่ได้เพิกถอนแอป และตรวจสอบว่านักพัฒนาแอปทำงานอยู่
หากการตรวจสอบข้างต้นทั้งหมดผ่านการตรวจสอบแล้ว แสดงว่าการยืนยันข้อมูลเข้าสู่ระบบสำเร็จ
สิ่งสำคัญที่สุดคือ Edge จะสร้างคีย์ผู้บริโภคโดยอัตโนมัติ แต่ผู้เผยแพร่โฆษณา API จะต้องบังคับใช้การตรวจสอบคีย์ในพร็อกซี API โดยใช้นโยบายที่เหมาะสม
การอนุมัติโดยอัตโนมัติกับการอนุมัติด้วยตนเอง
โดยค่าเริ่มต้น คำขอทั้งหมดเพื่อขอรับคีย์เพื่อเข้าถึงผลิตภัณฑ์ API จากแอปจะได้รับอนุมัติโดยอัตโนมัติ หรือจะกำหนดค่าผลิตภัณฑ์ API เพื่ออนุมัติคีย์ด้วยตนเองก็ได้ ในกรณีนี้ คุณจะต้องอนุมัติคำขอสำคัญจากแอปที่เพิ่มผลิตภัณฑ์ API ดูข้อมูลเพิ่มเติมได้ที่ลงทะเบียนแอปและจัดการคีย์ API
โควต้า
โควต้าสามารถปกป้องเซิร์ฟเวอร์แบ็กเอนด์สำหรับการรับส่งข้อมูลปริมาณมากและสร้างความแตกต่างให้กับสายผลิตภัณฑ์ของคุณได้ เช่น คุณอาจต้องการรวมทรัพยากรที่มีโควต้าสูงเป็นผลิตภัณฑ์พรีเมียมและใช้แพ็กเกจเดียวกันที่มีโควต้าต่ำกว่าเป็นผลิตภัณฑ์พื้นฐาน โควต้าจะช่วยป้องกันไม่ให้เซิร์ฟเวอร์ของคุณทำงานหนักเกินไปหากผลิตภัณฑ์หนึ่งๆ เป็นที่นิยมและได้รับคำขอจำนวนมาก
ดูข้อมูลเกี่ยวกับการกำหนดค่าโควต้าได้ที่นโยบายโควต้า สำหรับข้อมูลเกี่ยวกับการใช้การตั้งค่าโควต้าผลิตภัณฑ์ในนโยบายโควต้า โปรดดูบทความชุมชนต่อไปนี้ การตั้งค่าโควต้าในผลิตภัณฑ์ API โต้ตอบกับนโยบายโควต้าในพร็อกซี API อย่างไร
ขอบเขต OAuth
หากต้องการเพิ่มระดับการรักษาความปลอดภัย คุณจะกำหนดขอบเขต OAuth ใดก็ได้เป็นรายการที่คั่นด้วยคอมมา ซึ่งต้องแสดงในโทเค็นเพื่อการเข้าถึงที่ส่งผ่านผลิตภัณฑ์ เมื่อสร้างผลิตภัณฑ์ คุณต้องทราบขอบเขตทั้งหมดที่องค์กรใช้ ขอบเขตที่คุณเพิ่มลงในผลิตภัณฑ์ต้องตรงกับขอบเขตที่มีอยู่ หรือผลิตภัณฑ์ไม่ปลอดภัย
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ขอบเขตกับนโยบาย OAuth ของ Edge ที่หัวข้อการทำงานกับขอบเขต OAuth2
ระดับการเข้าถึง
เมื่อกำหนดผลิตภัณฑ์ API คุณจะตั้งค่าระดับการเข้าถึงต่อไปนี้ได้
ระดับการเข้าถึง | คำอธิบาย |
---|---|
สาธารณะ | ผลิตภัณฑ์ API ที่พร้อมให้นักพัฒนาซอฟต์แวร์ทุกคนใช้งาน คุณเพิ่มกลุ่มเป้าหมายลงในพอร์ทัลนักพัฒนาซอฟต์แวร์ที่ผสานรวมหรืออิงจาก Drupal ได้ |
ส่วนตัวหรือภายในเท่านั้น | ผลิตภัณฑ์ API ที่ออกแบบมาเพื่อการใช้งานส่วนตัวหรือภายใน หมายเหตุ: ระดับการเข้าถึงแบบส่วนตัวและภายในเท่านั้นไม่มีความแตกต่างด้านฟังก์ชันการทำงาน เลือกป้ายกำกับที่อธิบายกลุ่มเป้าหมายของผลิตภัณฑ์ API ได้ดีที่สุด สำหรับพอร์ทัลที่ผสานรวม คุณสามารถเพิ่มผลิตภัณฑ์ API แบบส่วนตัวหรือภายในเท่านั้น และทำให้นักพัฒนาแอปใช้งานผลิตภัณฑ์ดังกล่าวได้ตามที่จำเป็น สำหรับพอร์ทัลนักพัฒนาซอฟต์แวร์ที่ใช้ Drupal คุณสามารถจัดการการเข้าถึงผลิตภัณฑ์ API แบบส่วนตัวหรือภายในเท่านั้นในพอร์ทัลนักพัฒนาซอฟต์แวร์ตามที่อธิบายไว้ในส่วนต่อไปนี้
|