คุณกำลังดูเอกสารประกอบ 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 รายการที่ 2 ที่ให้สิทธิ์เข้าถึงทรัพยากรเดียวกัน แต่มีขีดจํากัดการเข้าถึงที่สูงกว่าและราคาสูงกว่า
- ผลิตภัณฑ์ API ฟรีที่มอบสิทธิ์การเข้าถึงทรัพยากรในระดับอ่านอย่างเดียว ผลิตภัณฑ์ API รายการที่ 2 ที่ให้สิทธิ์การอ่าน/เขียนทรัพยากรเดียวกันโดยมีค่าใช้จ่ายเพียงเล็กน้อย
นอกจากนี้ คุณยังควบคุมการเข้าถึงทรัพยากร 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 จะไม่เกิดขึ้นโดยอัตโนมัติ ไม่ว่าจะใช้คีย์ผู้ใช้หรือโทเค็น OAuth เป็นข้อมูลรับรองคำขอ พร็อกซี API จะตรวจสอบข้อมูลเข้าสู่ระบบของคำขอใน พร็อกซี API โดยรวมนโยบาย VerifyAPIKey หรือนโยบาย OAuth/VerifyAccessToken ไว้ด้วย ตามลำดับที่เหมาะสม หากคุณไม่ได้รวมนโยบายการบังคับใช้ข้อมูลเข้าสู่ระบบไว้ใน พร็อกซี API ผู้โทรทุกคนสามารถเรียกใช้ API ของคุณได้ สำหรับข้อมูลเพิ่มเติม ดูหัวข้อยืนยันนโยบายคีย์ API
Edge จะทำตามขั้นตอนต่อไปนี้เพื่อยืนยันข้อมูลเข้าสู่ระบบที่ส่งในคำขอ
- รับข้อมูลเข้าสู่ระบบที่ส่งไปกับคำขอ ในกรณีของ OAuth การยืนยันโทเค็น Edge จะยืนยันว่าโทเค็นยังไม่หมดอายุ จากนั้นค้นหาผู้บริโภค ที่ใช้ในการสร้างโทเค็น
- เรียกรายการผลิตภัณฑ์ API ที่เชื่อมโยงกับคีย์ผู้ใช้
- ยืนยันว่ามีพร็อกซี API ปัจจุบันอยู่ในผลิตภัณฑ์ API และ เส้นทางแหล่งข้อมูล (เส้นทาง URL) เปิดใช้อยู่ในผลิตภัณฑ์ API
- ตรวจสอบว่าคีย์ผู้ใช้ยังไม่หมดอายุหรือถูกเพิกถอน ตรวจสอบว่าไม่มีการเพิกถอนแอป และตรวจสอบว่านักพัฒนาแอปทำงานอยู่
หากผ่านการตรวจสอบทั้งหมดข้างต้นแล้ว แสดงว่าการยืนยันข้อมูลเข้าสู่ระบบสําเร็จ
ส่วนที่สำคัญที่สุด Edge จะสร้างคีย์ผู้บริโภคโดยอัตโนมัติ แต่ผู้เผยแพร่ API จะต้องสร้าง บังคับใช้การตรวจสอบคีย์ในพร็อกซี API โดยใช้นโยบายที่เหมาะสม
อัตโนมัติเทียบกับด้วยตนเอง การอนุมัติ
โดยค่าเริ่มต้น คำขอทั้งหมดในการรับคีย์เพื่อเข้าถึงผลิตภัณฑ์ API จากแอปจะได้รับอนุมัติโดยอัตโนมัติ อีกวิธีหนึ่งคือ กำหนดค่าผลิตภัณฑ์ API เพื่ออนุมัติคีย์ด้วยตนเอง ในกรณีนี้ คุณจะต้องอนุมัติคำขอสำคัญจากแอปใดก็ตามที่เพิ่ม ผลิตภัณฑ์ API ดูข้อมูลเพิ่มเติมได้ที่ลงทะเบียนแอปและจัดการ API
โควต้า
โควต้าสามารถปกป้องเซิร์ฟเวอร์แบ็กเอนด์เมื่อมีการรับส่งข้อมูลสูง และทำให้สายผลิตภัณฑ์ของคุณโดดเด่น ตัวอย่างเช่น คุณอาจต้องการรวมทรัพยากรที่มีโควต้าสูงเป็นผลิตภัณฑ์พรีเมียมและใช้ แพ็กเกจเดียวกันแต่มีโควต้าต่ำกว่า เมื่อใช้ผลิตภัณฑ์พื้นฐาน โควต้าจะช่วยปกป้องเซิร์ฟเวอร์ของคุณจาก รู้สึกตื่นเต้นหากผลิตภัณฑ์เป็นที่นิยมและได้รับคำขอจำนวนมาก
โปรดดูข้อมูลเกี่ยวกับการกำหนดค่าโควต้าที่นโยบายโควต้า สำหรับข้อมูลเกี่ยวกับ ที่ใช้การตั้งค่าโควต้าผลิตภัณฑ์ในนโยบายโควต้า โปรดดูบทความของชุมชนต่อไปนี้ การตั้งค่าโควต้าในผลิตภัณฑ์ API โต้ตอบกับนโยบายโควต้าในพร็อกซี API อย่างไร
ขอบเขตของ OAuth
เพื่อเพิ่มระดับการรักษาความปลอดภัย คุณสามารถกำหนดขอบเขต OAuth ใดก็ได้เป็นรายการที่คั่นด้วยจุลภาค ที่ต้องแสดงในโทเค็นเพื่อการเข้าถึงที่ส่งผ่านผลิตภัณฑ์ เมื่อคุณสร้างผลิตภัณฑ์ คุณต้องทราบขอบเขตทั้งหมดที่องค์กรของคุณใช้ ขอบเขตที่คุณเพิ่มลงในผลิตภัณฑ์ ต้องตรงกับขอบเขตที่มีอยู่หรือผลิตภัณฑ์ไม่ปลอดภัย
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ขอบเขตกับนโยบาย Edge OAuth ที่หัวข้อการใช้งานขอบเขต OAuth2
ระดับการเข้าถึง
เมื่อกำหนดผลิตภัณฑ์ API คุณตั้งค่าระดับการเข้าถึงต่อไปนี้ได้
| ระดับการเข้าถึง | คำอธิบาย |
|---|---|
| สาธารณะ | ผลิตภัณฑ์ API ที่พร้อมให้บริการแก่นักพัฒนาซอฟต์แวร์ทุกคน คุณจะเพิ่มไปยังพอร์ทัลของนักพัฒนาซอฟต์แวร์แบบผสานรวมหรือที่ใช้ Drupal ได้ |
| ส่วนตัวหรือภายในเท่านั้น | ผลิตภัณฑ์ API ที่ออกแบบมาสำหรับการใช้งานส่วนตัวหรือภายใน หมายเหตุ: ไม่มีความแตกต่างด้านฟังก์ชันระหว่างระดับการเข้าถึงแบบส่วนตัวและภายในเท่านั้น เลือกป้ายกำกับที่อธิบายกลุ่มเป้าหมายที่ต้องการของผลิตภัณฑ์ API ได้ดีที่สุด สำหรับพอร์ทัลแบบผสานรวม คุณสามารถเพิ่มผลิตภัณฑ์ API ส่วนตัวหรือภายในเท่านั้น และเผยแพร่แก่นักพัฒนาแอปตามที่จำเป็น สําหรับพอร์ทัลนักพัฒนาแอปที่ใช้ Drupal คุณสามารถจัดการการเข้าถึงผลิตภัณฑ์ API ส่วนตัวหรือภายในเท่านั้นได้ในพอร์ทัลนักพัฒนาแอปของคุณตามที่อธิบายไว้ในส่วนต่อไปนี้
|