مقدمه

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

بخش های زیر شما را با محصولات API و مفاهیم کلیدی مرتبط آشنا می کند.

محصول API چیست؟

به‌عنوان یک ارائه‌دهنده API، محصولات API را ایجاد می‌کنید تا API‌های خود را بسته‌بندی کنید و آنها را برای مصرف در اختیار توسعه‌دهندگان برنامه قرار دهید. می توانید محصولات API را به عنوان خط تولید خود در نظر بگیرید.

به طور خاص، یک محصول API موارد زیر را با هم ترکیب می کند:

• مجموعه منابع API (URI)
• طرح خدمات
• فراداده مخصوص کسب و کار شما برای نظارت یا تجزیه و تحلیل (اختیاری)

منابع API همراه در یک محصول API می‌تواند از یک یا چند API باشد، بنابراین می‌توانید منابع را برای ایجاد مجموعه‌های ویژگی‌های تخصصی، همانطور که در شکل زیر نشان داده شده است، ترکیب و مطابقت دهید.

می‌توانید چندین محصول API ایجاد کنید تا موارد استفاده‌ای را که نیازهای خاص را برطرف می‌کنند، برطرف کنید. به عنوان مثال، می‌توانید یک محصول API ایجاد کنید که تعدادی از منابع نقشه‌برداری را در کنار هم قرار می‌دهد تا توسعه‌دهندگان بتوانند به راحتی نقشه‌ها را در برنامه‌های خود ادغام کنند. علاوه بر این، می‌توانید ویژگی‌های مختلفی را روی هر محصول API تنظیم کنید، مانند سطوح مختلف قیمت‌گذاری. برای مثال، ممکن است ترکیبات محصول API زیر را ارائه دهید:

• یک محصول API با محدودیت دسترسی کم، مانند 1000 درخواست در روز، با قیمت مقرون به صرفه. یک محصول API دوم که دسترسی به منابع مشابه را دارد، اما با محدودیت دسترسی بالاتر و قیمت بالاتر.
• یک محصول API رایگان که دسترسی فقط خواندنی به منابع را ارائه می دهد. دومین محصول API که دسترسی خواندن/نوشتن به همان منابع را با هزینه اندک فراهم می کند.

علاوه بر این، می توانید دسترسی به منابع API را در یک محصول API کنترل کنید. به عنوان مثال، می‌توانید منابعی را که فقط برای توسعه‌دهندگان داخلی یا فقط با پرداخت هزینه به مشتریان قابل دسترسی هستند، دسته‌بندی کنید.

محصولات API مکانیسم مرکزی مجوز و کنترل دسترسی به API های شما هستند. در Apigee، کلیدهای API، نه برای خود API ها، بلکه برای محصولات API ارائه می شوند. به عبارت دیگر، کلیدهای API برای مجموعه‌ای از منابع با یک طرح خدمات پیوست شده ارائه می‌شوند.

توسعه دهندگان برنامه با ثبت برنامه های خود، همانطور که در ثبت برنامه ها توضیح داده شده است، به محصولات API شما دسترسی پیدا می کنند. هنگامی که یک برنامه سعی می کند به یک محصول API دسترسی پیدا کند، مجوز توسط Apigee در زمان اجرا اعمال می شود تا اطمینان حاصل شود که:

• برنامه درخواست کننده مجاز به دسترسی به یک منبع API خاص است.
• برنامه درخواست کننده از سهمیه مجاز فراتر نرفته است.
• اگر تعریف شده باشد، دامنه های OAuth تعریف شده در محصول API با موارد مرتبط با رمز دسترسی ارائه شده توسط برنامه مطابقت دارد.

مفاهیم کلیدی را درک کنید

قبل از ایجاد محصولات API خود، مفاهیم کلیدی زیر را مرور کنید.

• کلیدهای API
• تأیید کلید خودکار در مقابل دستی
• سهمیه ها
• دامنه های OAuth
• سطوح دسترسی

کلیدهای API

وقتی برنامه یک برنامه‌نویس را در سازمان خود ثبت می‌کنید، برنامه باید حداقل با یک محصول API مرتبط باشد. در نتیجه جفت شدن یک برنامه با یک یا چند محصول API، Edge یک کلید مصرف کننده منحصر به فرد را به برنامه اختصاص می دهد.

کلید مصرف کننده یا نشانه دسترسی به عنوان اعتبار درخواست عمل می کند. توسعه‌دهنده برنامه کلید مصرف‌کننده را در برنامه جاسازی می‌کند، به طوری که وقتی برنامه درخواستی به یک API میزبان Edge می‌دهد، برنامه کلید مصرف‌کننده را به یکی از روش‌های زیر در درخواست ارسال می‌کند:

• وقتی API از تأیید کلید API استفاده می کند، برنامه باید کلید مصرف کننده را مستقیماً ارسال کند.
• هنگامی که API از تأیید OAuth Token استفاده می کند، برنامه باید رمزی را ارسال کند که از کلید مصرف کننده مشتق شده است.

اجرای کلید 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، می توانید سطوح دسترسی زیر را تنظیم کنید.