درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
بخش‌های زیر شما را با محصولات API و مفاهیم کلیدی مرتبط آشنا می‌کند.
محصول API چیست؟
به‌عنوان ارائه‌دهنده API، محصولات API را ایجاد می‌کنید تا APIهای خود را دسته‌بندی کنید و آن‌ها را برای مصرف توسعه‌دهندگان برنامه دردسترس قرار دهید. می‌توانید محصولات API را به‌عنوان خط تولید خود درنظر بگیرید.
به‌طور دقیق، محصول API موارد زیر را با هم دسته‌بندی می‌کند:
- مجموعه منابع میانای برنامه‌سازی کاربردی (نشانی‌های وب)
- طرح سرویس
- فراداده‌های ویژه کسب‌وکارتان برای پایش یا تجزیه‌وتحلیل (اختیاری)
منابع API دسته‌بندی‌شده در یک محصول API می‌تواند از یک یا چند API باشد، بنابراین می‌توانید منابع را ترکیب کنید و برای ایجاد مجموعه‌های ویژگی تخصصی، همان‌طور که در شکل زیر نشان داده شده است، مطابقت دهید.
می‌توانید چندین محصول API ایجاد کنید تا موارد استفاده‌ای را که نیازهای خاصی را برطرف می‌کنند پوشش دهید. برای مثال، می‌توانید محصول API ایجاد کنید که تعدادی از منابع نقشه‌برداری را دسته‌بندی می‌کند تا توسعه‌دهندگان بتوانند به‌راحتی نقشه‌ها را در برنامه‌هایشان ادغام کنند. علاوه‌براین، می‌توانید ویژگی‌های مختلفی را برای هر محصول API تنظیم کنید، مثلاً سطوح قیمت‌گذاری مختلف. برای مثال، می‌توانید ترکیب‌های محصول «میانای برنامه‌سازی کاربردی» زیر را ارائه دهید:
- محصول API که حد دسترسی پایینی، مثلاً ۱۰۰۰ درخواست در روز، را با قیمت ارزان ارائه می‌دهد. محصول API دوم که دسترسی به همان منابع را فراهم می‌کند، اما با حد دسترسی بالاتر و قیمت بالاتر.
- محصول API رایگانی که دسترسی فقط خواندنی به منابع ارائه می‌دهد. محصول میانای برنامه‌سازی کاربردی دوم که دسترسی خواندن/نوشتن به منابع یکسان را با هزینه اندک ارائه می‌دهد.
علاوه‌براین، می‌توانید دسترسی به منابع «میانای برنامه‌سازی کاربردی» را در محصول «میانای برنامه‌سازی کاربردی» کنترل کنید. برای مثال، می‌توانید منابعی را دسته‌بندی کنید که فقط توسعه‌دهندگان داخلی یا فقط مشتریان پولی بتوانند به آن‌ها دسترسی داشته باشند.
محصولات API سازوکار مرکزی برای کنترل دسترسی و صدور مجوز برای APIهای شما هستند. در Apigee، کلیدهای API نه برای خود APIها، بلکه برای محصولات API تأمین می‌شوند. به‌عبارت دیگر، کلیدهای API برای دسته‌های منابع با طرح خدمات پیوست‌شده تأمین می‌شوند.
توسعه‌دهندگان برنامه با ثبت کردن برنامه‌هایشان به محصولات API شما دسترسی پیدا می‌کنند، همان‌طور که در «ثبت کردن برنامه‌ها» توضیح داده شده است. وقتی برنامه‌ای تلاش می‌کند به محصول API دسترسی پیدا کند، Apigee در زمان اجرا مجوز را اعمال می‌کند تا مطمئن شود که:
- برنامه درخواست‌کننده اجازه دارد به منبع میانای برنامه‌سازی کاربردی خاصی دسترسی داشته باشد.
- برنامه درخواست‌کننده از سهمیه مجاز فراتر نرفته است.
- اگر تعریف شده باشد، دامنه‌های OAuth تعریف‌شده در محصول API با دامنه‌های مرتبط با کد دسترسی ارائه‌شده توسط برنامه مطابقت دارند.
درک مفاهیم کلیدی
پیش‌از ایجاد محصولات API، مفاهیم کلیدی زیر را مرور کنید.
کلیدهای میانای برنامه‌سازی کاربردی
وقتی برنامه توسعه‌دهنده‌ای را در سازمانتان ثبت می‌کنید، برنامه باید با حداقل یک محصول «میانای برنامه‌سازی کاربردی» مرتبط باشد. در نتیجه جفت کردن برنامه با یک یا چند محصول API، Edge کلید مصرف‌کننده یکتایی به برنامه اختصاص می‌دهد.
کلید مصرف‌کننده یا کد دسترسی به‌عنوان اطلاعات اعتباری درخواست عمل می‌کند. توسعه‌دهنده برنامه کلید مصرف‌کننده را در برنامه جاسازی می‌کند، بنابراین وقتی برنامه درخواستی به API میزبانی‌شده توسط Edge ارسال می‌کند، برنامه کلید مصرف‌کننده را به یکی از روش‌های زیر در درخواست ارسال می‌کند:
- وقتی API از درستی‌سنجی کلید API استفاده می‌کند، برنامه باید کلید مصرف‌کننده را مستقیماً ارسال کند.
- وقتی API از درستی‌سنجی «کد OAuth» استفاده می‌کند، برنامه باید کدی را که از کلید مصرف‌کننده استخراج شده است ارسال کند.
اجرای کلید API به‌صورت خودکار انجام نمی‌شود. چه از کلید مصرف‌کننده یا کد OAuth به‌عنوان اطلاعات اعتباری درخواست استفاده کنید، «پراکسی API» اطلاعات اعتباری درخواست را در پراکسی‌های API شما با افزودن خط‌مشی VerifyAPIKey یا خط‌مشی OAuth/VerifyAccessToken در جریان مناسب اعتبارسنجی می‌کند. اگر خط‌مشی اعمال اطلاعات اعتباری را در «پراکسی API» خود قرار ندهید، هر فردی می‌تواند «میاناهای برنامه‌سازی کاربردی» شما را فراخوانی کند. برای اطلاعات بیشتر، خط‌مشی «تأیید کلید API» را ببینید.
برای درستی‌سنجی اطلاعات اعتباری ارسال‌شده در درخواست، Edge مراحل زیر را انجام می‌دهد:
- اطلاعات اعتباری که با درخواست ارسال شده است را دریافت کنید. در مورد درستی‌سنجی کد OAuth، Edge بررسی می‌کند که کد منقضی نشده باشد، و سپس کلید مصرف‌کننده‌ای را که برای تولید کد استفاده شده است جستجو می‌کند.
- فهرست محصولات API را که کلید مصرف‌کننده به آن‌ها منسوب شده است بازیابی کنید.
- تأیید کنید که «پراکسی میانای برنامه‌سازی کاربردی» فعلی در «محصول میانای برنامه‌سازی کاربردی» قرار دارد و آیا مسیر منبع فعلی (مسیر نشانی وب) در «محصول میانای برنامه‌سازی کاربردی» فعال است یا نه.
- تأیید کنید که کلید مصرف‌کننده منقضی یا باطل نشده باشد، بررسی کنید که برنامه باطل نشده باشد، و بررسی کنید که توسعه‌دهنده برنامه فعال باشد.
اگر همه بررسی‌های بالا باموفقیت انجام شود، درستی‌سنجی اطلاعات اعتباری باموفقیت انجام می‌شود.
درنهایت، Edge به‌طور خودکار کلیدهای مصرف‌کننده تولید می‌کند، اما ناشران API باید بااستفاده از خط‌مشی‌های مناسب، بررسی کلید را در پراکسی‌های API اعمال کنند.
تأیید خودکار دربرابر دستی
به‌طور پیش‌فرض، همه درخواست‌های دریافت کلید برای دسترسی به محصول API از یک برنامه به‌طور خودکار تأیید می‌شوند. یا اینکه می‌توانید محصول میانای برنامه‌سازی کاربردی را پیکربندی کنید تا کلیدها را به‌طور دستی تأیید کند. در این مورد، باید درخواست‌های کلید را از هر برنامه‌ای که محصول API را اضافه می‌کند تأیید کنید. برای اطلاعات بیشتر، ثبت برنامه‌ها و مدیریت کلیدهای API را ببینید.
سهمیه‌ها
سهمیه‌ها می‌توانند از سرورهای پشتیبان شما دربرابر ترافیک بالا محافظت کنند و خط تولید شما را متمایز کنند. برای مثال، ممکن است بخواهید منابع با سهمیه بالا را به‌عنوان محصول ممتاز دسته‌بندی کنید و از همان دسته با سهمیه پایین‌تر به‌عنوان محصول پایه استفاده کنید. سهمیه می‌تواند به محافظت از سرورهای شما دربرابر ازکارافتادگی درصورت محبوبیت یک محصول و دریافت حجم زیادی از درخواست‌ها کمک کند.
برای کسب اطلاعات درباره پیکربندی سهمیه، خط‌مشی سهمیه را ببینید. برای کسب اطلاعات درباره استفاده از تنظیمات سهمیه محصول در خط‌مشی‌های سهمیه، به مقاله انجمن زیر مراجعه کنید: تنظیمات سهمیه در محصول API چگونه با خط‌مشی‌های سهمیه در پراکسی API تعامل دارد؟.
محدوده‌های OAuth
برای افزایش سطح امنیت، می‌توانید هر حوزه OAuth را به‌صورت فهرست جداشده با کاما تعریف کنید که باید در کدهای دسترسی ارسال‌شده ازطریق محصول وجود داشته باشد. هنگام ایجاد محصول، باید از همه محدوده‌هایی که سازمانتان استفاده می‌کند آگاه باشید. محدوده‌هایی که به محصول اضافه می‌کنید باید با محدوده‌های موجود مطابقت داشته باشد، درغیراین‌صورت محصول ایمن نیست.
برای اطلاعات بیشتر درباره استفاده از محدوده‌ها با خط‌مشی‌های Edge OAuth، به کار با محدوده‌های OAuth2 مراجعه کنید.
سطوح دسترسی
هنگام تعریف محصول API، می‌توانید سطوح دسترسی زیر را تنظیم کنید.
| سطح دسترسی | شرح |
|---|---|
| عمومی | محصولات API که برای همه توسعه‌دهندگان دردسترس هستند. می‌توانید آن‌ها را به درگاه‌های توسعه‌دهنده یکپارچه یا مبتنی بر Drupal اضافه کنید. |
| فقط خصوصی یا داخلی | محصولات API که برای استفاده خصوصی یا داخلی طراحی شده‌اند. توجه: بین سطوح دسترسی «خصوصی» و «فقط داخلی» تفاوت عملکردی وجود ندارد. برچسبی را انتخاب کنید که مخاطب موردنظر محصول API را به بهترین شکل توصیف می‌کند. برای درگاه یکپارچه، می‌توانید محصولات API خصوصی یا فقط داخلی را اضافه کنید و آن‌ها را درصورت نیاز دراختیار توسعه‌دهندگان برنامه قرار دهید. برای درگاه‌های توسعه‌دهنده مبتنی بر Drupal، می‌توانید دسترسی به محصولات API «فقط داخلی» یا «خصوصی» را در درگاه توسعه‌دهنده خود مدیریت کنید، همان‌طور که در بخش‌های زیر توضیح داده شده است:
|