در این مقاله اطلاعاتی را در ارتباط با عمومی‌سازی یک اَپی در اختیارتان قرار میدهیم . چیزی که من بین مشتریان مختلفم مشاهده کردم، این است که تعداد اَپی‌های خصوصی بسیار بیشتر از اَپی‌های عمومیست، و به ازای هر اَپی (API) عمومی، ۱۰ اَپی خصوصی وجود دارد. بعضی اَپی‌های خصوصی هستند که برای استفاده داخل سازمان و پشت فایروال ساخته شده و بعضی اَپی‌های دیگر در تمام دنیا، ولی فقط برای استفاده خصوصی برنامه‌های کاربردی موبایل و وب قابل دسترس هستند.
عمومی‌سازی یک اَپی، نیاز به برنامه‌ریزی دارد
۵ آیتمی که در این مقاله توضیح میدهیم مشخص می‌کنند، عمومی‌سازی یک اَپی (API) به سادگی تغییر تنظیمات فایروال و دادن اجازه دسترسی به اَپی داخلی شما نخواهد بود. برای این کار، ملاحظات و برنامه‌ریزی در مورد امنیت، تجربه توسعه‌دهندگان، محافظت، و کارایی مورد نیاز خواهد بود. اطمینان حاصل کنید که برنامه‌ریزی مناسب توسعه برای انتشار اَپی (API) خود به شرکا یا توسعه‌دهندگان عمومی انجام داده‌اید، تا خطرات عمومی‌سازی اَپی خود را برای استفاده خارج از سازمان کاهش دهید.
پنج کاری که باید پیش از عمومی‌سازی یک اَپی (API) خصوصی انجام داد
در طول زمان، بعضی از این آپی‌های خصوصی گزینه‌های مناسبی برای تبدیل شدن به اَپی‌های عمومی یا اشتراکی هستند. ولی نباید اینطور فرض کنیم که اَپی‌های خصوصی ما آمادگی عمومی‌سازی یک اَپی شدن را دارند. در اینجا ۵ کاری را بررسی می‌کنیم، که پیش از بردن اَپی‌هاتون به آنسوی فایروال باید انجام دهید.
۱.انجام بررسی کامل امنیتی
متوجه هستم، طراحی اَپی‌های داخلی باید با شتاب انجام شود که اغلب منجر به نادیده گرفته شدن بررسی‌های کامل طراحی و امنیتی نیز می‌شود. ولی وقتی اَپی را در اختیار عموم قرار دهیم، مطلقاً اولین کاری که باید انجام دهیم این است که به سراغ طراحی اَپی (API) رفته و ببینیم در چه جاهایی نیاز به تغییرات اساسی داریم.
تیندر برای فهمیدن این موضوع ضرر زیادی کرد. فوربِس بخوبی شرح داده که وقتی تیندر اَپی (API) خصوصی خودشون رو در اختیار عموم قرار داد، چه ایرادی بوجود آمد:
«متاسفانه دو عامل از عوامل تضمین کننده بالا بودن که کیفیت خدمات تیندر به کاربران، باعث بوجود آمدن ریسک و سوءاستفاده توسط افراد سودجو با توانایی‌های اندک هَک شدند. اولاً اینکه پردازش موقعیت مکانی بر روی کلاینت انجام می‌شد، به این دلیل داده‌های موقعیت مکانی واقعی افرادی که تیندر به عنوان گزینه مناسب برای کاربر انتخاب می‌کرد، بدون دخالت سرورهای تیندر مستقیماً برای آن کاربر ارسال می‌شد. دوماً، اینکه این داده‌ها بطرز خارق‌العاده‌ای و در حد ۳۰ متر یا حتی کمتر، دقیق بودند.»
بطور خلاصه، تیندر در بازبینی داده‌هایی که به اَپی (API) آنها ارسال می‌شد، کوتاهی کرده بود. بجای اینکه اَپی (API) موقعیت مکانی تقریبی را به اپلیکیشن موبایل کاربر ارسال کند، اپلیکیشن مختصات طول و عرض جغرافیایی دقیق افراد یافته شده را از اَپی تیندر دریافت می‌کرد.
وقتی اَپی (API) در اختیار عموم قرار گرفت، این موضوع تغییر نکرد و در نتیجه افراد یافته شده که اَپی (API) تیندر پیدا می‌کرد در معرض خطرات مختلفی قرار می‌گرفتند. البته این اشکال در حال حاضر مرتفع شده است.
نتیجه‌گیری: اینطور فرض نکنید که اَپی (API) شما برای استفاده‌ای غیر از استفاده اولیه طراحی شده است. وقت کافی به مرور تمامی endpointها اختصاص داده، و اطمینان حاصل کنید که داده‌های مناسب به توسعه‌دهندگان خارج از سازمان ارسال می‌شوند.
.
.
۲.مستندسازی اَپی (API) خود را بهبود دهید.
وقتی اَپی‌ها خصوصی هستند، بسیاری از جزئیات آن بصورت دهان به دهان منتقل می‌شوند. اگر کسی سؤالی در مورد چگونگی کارکرد یکی از اَپی‌ها دارد، چه شخصاً و چه از طریق سیستم پیام رسان داخل سازمان، به سراغ یکی از اعضای تیم رفته و سؤال را مستقیما می‌پرسد.
وقتی یک اَپی (API) عمومی شد، دیگر این موضوع ممکن نیست، و مستندسازی بهتری برای آن اَپی مورد نیاز خواهد بود.
برخی از سؤالاتی که مستندسازی شما باید قادر به پاسخ آنها باشد، عبارتند از:
- اَپی شما چه ویژگی‌ها و ظرفیت‌هایی دارد؟
- اَپی شما عملیات احراز هویت و صدور دسترسی را چگونه انجام می‌دهد؟
- چه endpointهایی وجود دارند، و جزئیات درخواست/پاسخ به چه صورت هستند؟
نتیجه‌گیری: مستندسازی اَپی (API) خود را بازبینی کنید، تا مطمئن شوید که مصرف‌کنندگان اَپی شما قادر به پاسخ دادن به سؤالاتشان در مورد چگونگی شروع به کار با اَپی (API) شما هستند.
.
۳.مثال‌هایی برای نحوه استفاده بنویسید.
اَپی‌های خصوصی معمولاً توسط اپلیکیشن‌هایی مورد استفاده قرار می‌گیرند که شما به کدِ منبع آن دسترسی دارید. بنابراین مثال‌های استفاده وجود خواهند داشت. وقتی اَپی خود را در دسترس عموم قرار دادید، مصرف‌کنندگان به مثال‌هایی برای درک چگونگی استفاده از اَپی (API) شما نیاز خواهند داشت.
مثال‌ها می‌توانند ترکیبی از کدهای cURL و تکه کدهای ۳ تا ۵ زبان برنامه‌نویسی محبوب بین مخاطبینتان باشند. دست‌کم، این مثال‌ها باید نشان‌دهنده چگونگی انجام امور ساده توسط اَپی (API) شما باشند.
همچنین قویاً توصیه می‌کنم که با ایجاد اپلیکیشن‌های آزمایشی، مثال‌های پیچیده بیشتری در کنار مثال‌های ساده قرار دهید که به توسعه‌دهندگان کمک کند بهتر بدانند چگونه با استفاده از امکانات مختلف اَپی (API) شما و ترکیب آنها، راهکارهای بزرگتری قابل دستیابی هستند.
نتیجه‌گیری: نمونه کدها و اپلیکیشن‌های نمایشی ایجاد کنید تا به توسعه‌دهندگان برای استفاده سریعتر از اَپی شما کمک کنند. می‌توانید از مقاله اخیر ما، مستندسازی خوب اَپی نیازمند کدهای نمونه است، برای درک بهتر چگونگی اضافه کردن نمونه کد به مستندسازی خود استفاده کنید.
.
۴.محدودیت سرعت و حفاظت از endpoint ایجاد کنید
اشتباهات غیرقابل اجتناب هستند. ممکن است در کدهایی که توسعه‌دهندگان می‌نویسند، باگی وجود داشته باشد که باعث شود بسیار بیشتر از آنچه لازم است از اَپی (API) شما استفاده کنند. یا حتی شاید، توسعه‌دهنده‌ای قصد از کار انداختن اَپی شما را داشته باشد.
قبل از عمومی کردن اَپی خود، یک لایه سوییچ اَپی (API) نصب کنید. لایه سوییچ باعث می‌شود مطمئن باشید که محدودیت سرعت در مورد درخواست های ورودی اعمال شده، و endpointهای شما از خطر استفاده بیش از سهوی یا عمدی که ممکن است به کاهش کارایی یا افزایش هزینه‌های زیرساخت سرورهای ابری شوند، در امانند.
نتیجه‌گیری: لایه سوییچ اَپی (API) همه endpointهای شما را از حملات مخرب و استفاده‌های بدون اجازه محافظت کرده، و به اَپی (API) شما امکان اجازه استفاده درجه بندی شده بر اساس اشتراک و مجوزها را می‌دهد.
چه درحال عمومی کردن اَپی خود هستید، و چه قصد بهبود اَپی خود را دارید، نصب لایه سوییچ برای اَپی چه بر روی سرور محلی و چه در سرورهای ابری، باید یکی از اولین قدم‌های شما باشد.
.
۵.تعریف KPIها و گزارشات مصرف برای ایجاد بهبودها
پس از عمومی کردن اَپی‌تان، لازم است از اینکه اَپی عمومی شما قادر به برطرف کردن اهداف کاری و فنی شما است یا خیر، اطمینان حاصل کنید. بسیاری از لایه‌های سوییچ اَپی (API) سیستمی برای تجزیه و تحلیل میزان استفاده فراهم می‌کنند.
توسط این آمار و ارقام می‌توان «شاخصه‌های کلیدی کارایی» (KPI) را تعریف کرد، که توسط صاحبان کسب‌و‌کار برای سنجش میزان موفقیت استفاده می‌شوند. این مشخصه‌ها همچنین می‌توانند برای اطمینان از اینکه زیرساخت‌های شما در مقیاس مورد انتظار ظاهر شده‌اند یا خیر، مورد استفاده قرار گیرند.
نتیجه‌گیری: از استراتژی محصول اَپی (API) خود به عنوان راهنما استفاده کنید، برای شروع تعدادی از معیارهای کلیدی را مورد سنجش قرار دهید. سپس معیارها جدید یا مختلفی را برای ارزیابی موفقیت کسب‌و‌کارتان بررسی کنید.
با مدیران و مجریان محصول برای مشخص کردن معیارهای لازم هم در بُعد فنی و هم در بُعد کاری و همچنین تحت نظر قرار دادن سلامت محصول اَپی (API) جدید و عمومی خود، همکاری کنید.