شما هرگز برای ایجاد یک برداشت اول، شانس دومی ندارید. یک API اغلب نخستین نقطه‌ی تماس یک توسعه‌دهنده با یک سرویس نرم‌افزار-به‌عنوان-خدمت است. این API باید همان‌گونه که انتظار می‌رود عمل کند، در غیر این صورت خطر ایجاد یک برداشت بد وجود دارد که در ذهن آن‌ها باقی می‌ماند. ارائه‌ی یک تجربه‌ی توسعه‌دهنده‌ی کمتر از حد استاندارد می‌تواند به بازخورد منفی و در نتیجه آسیب به اعتبار برند شما منجر شود. در بدترین حالت، می‌تواند مشکلات امنیتی API و حتی در برخی موارد مشکلات قانونی ایجاد کند.
متأسفانه APIها همیشه آن‌طور که باید عمل نمی‌کنند. APIها تمایل دارند از مشخصات خود فاصله بگیرند، گاهی به‌دلیل نبود نگهداری منظم. زمانی که این اتفاق رخ می‌دهد، مشخصات با رفتار محیط تولید مطابقت ندارد و مشکلاتی ایجاد می‌شود. این وضعیت با نام API drift شناخته می‌شود. API drift یک پدیده‌ی رایج است، همان‌طور که APIContext در وایت‌پیپر اخیر خود با عنوان OpenAPI Specifications in the Real World گزارش کرده است؛ این پژوهش بر اساس ۶۵۰ میلیون فراخوان API به بیش از ۱۰٬۰۰۰ نقطه‌پایان API مختلف انجام شده است. در ادامه برخی از یافته‌های کلیدی آمده است که باید نشان دهند چرا تیم‌های API باید همیشه مشخصات API خود را به‌روز نگه دارند.
۷۵٪ از APIها Endpoints ناسازگار دارند
طبق گفته‌ی APIContext، ۷۵٪ از APIهای تولیدی آزمایش‌شده دارای مغایرت با OpenAPI Specification منتشرشده‌ی خود بودند. هرچقدر هم که مشخصات دقیق باشند، هنگام توسعه APIها ممکن است از مشخصات فاصله بگیرند. برخی انواع APIها نسبت به دیگران بیشتر مستعد drift هستند. برخی APIهای حوزه‌ی بانکداری، فین‌تک، و مدیریت ایمیل انبوه، ۰٪ drift داشتند. اما برخی APIهای دیگر مانند Box یا Pivotal Tracker نرخ drift بسیار بالاتری داشتند.
برخی از رایج‌ترین خطاها عبارت‌اند از:
- API قالب اشتباه برمی‌گرداند
- API داده‌ی اشتباه برمی‌گرداند
- API به‌صورت مبهم پاسخ می‌دهد
- معیارهای قبولی/رد به‌درستی تعریف نشده‌اند
برای خطاهای قالب اشتباه، APIContext توصیه می‌کند که اشیای ساخت‌یافته به‌صورت null یا خالی بازگردانده شوند. برای خطاهای مقدار، توصیه می‌کنند که یک وضعیت HTTP برگردانده شود تا اشکال‌زدایی در صورت بروز مشکل آسان‌تر شود.
۴۳٪ از APIها مشخصات عمومی API ندارند
پس از جست‌وجوی عباراتی مانند “OpenAPI Specification”، APIContext دریافت که تنها ۵۷٪ از APIها دارای مشخصات API عمومی هستند. مشخصات عمومی API یکی از مهم‌ترین عوامل در ارائه‌ی تجربه‌ی مناسب برای توسعه‌دهنده است. همچنین می‌تواند باعث تسهیل یکپارچه‌سازی API و مستندات خودکار API شود. و در نهایت، مشخصات عمومی API یک فرصت عالی برای بازاریابی API شماست.
اغلب بانک‌های بریتانیا OpenAPI مربوط به Open Banking خود را سفارشی‌سازی نمی‌کنند
با وجود اینکه بانک‌های بریتانیا موظف به رعایت استانداردهای خاص Open Banking هستند، بسیاری از آن‌ها برای سفارشی‌سازی OpenAPI خود قدم اضافی برنمی‌دارند. این موضوع می‌تواند باعث بروز خطا شود و همچنین یک فرصت ارزشمند برای تقویت برند را از بین ببرد.
بانک‌ها می‌توانند مشخصات را برای hostname خاص خود (که همان URL پایه‌ی سرویس است) سفارشی‌سازی کنند. ارائه‌ی مستنداتی شامل endpoints مشخص باعث می‌شود کاربران بدانند دقیقاً چگونه از API استفاده کنند. این کار همچنین فرصت مناسبی برای نشان دادن به‌روز بودن، امنیت و نگهداری مناسب API بانکی است.
OpenAPI 2.0 همچنان استفاده‌ی چشمگیری دارد
مشخصات OpenAPI (OAS) نسخه‌ی ۲.۰ با وجود گذشت حدود ۱۰ سال از انتشار آن، همچنان محبوب است. ۳۰٪ از APIهای بررسی‌شده توسط APIContext هنوز از OAS 2.0 استفاده می‌کردند. از میان ۵۴٪ استفاده‌کنندگان OAS 3.0، نسخه‌های کوچک ۳.۰.۰ و ۳.۰.۱ رایج‌ترین بودند. تنها ۷٪ از جدیدترین نسخه یعنی ۳.۱.۰ استفاده می‌کنند که در اوایل ۲۰۲۱ منتشر شد. استفاده از نسخه‌های قدیمی OAS تا حدی به‌دلیل برخی ارائه‌دهندگان سرویس است که به‌عنوان گلوگاه در به‌روزرسانی API عمل می‌کنند. به‌عنوان مثال، AWS Gateway از OAS 3.1 پشتیبانی نمی‌کند و Gateway API گوگل فقط از OAS 2.0 پشتیبانی می‌کند.
۵۲٪ از APIها طی شش ماه گذشته به‌روزرسانی نشده‌اند
APIContext دریافت که بیش از نیمی از مشخصات API طی شش ماه گذشته به‌روزرسانی نشده‌اند. زمانی که مشخصات API به‌روزرسانی می‌شود، در برخی سازمان‌ها هر چند روز یک‌بار به‌روز می‌شود. این تفاوت نشان‌دهنده‌ی دیدگاه‌های مختلف نسبت به مشخصات API است. کسانی که مشخصات را منظم به‌روز می‌کنند، آن را بخشی از چرخه‌ی توسعه و یک بهترین‌روش برای نگهداری API می‌دانند. کسانی که به‌طور منظم به‌روزرسانی نمی‌کنند، فلسفه‌ی متفاوتی نسبت به مشخصات دارند.
بدون OAS 3.0، توسعه‌دهندگان API نمی‌توانند از ویژگی‌های جدید مانند OpenAPI Links استفاده کنند، که رابطه میان عملیات‌ها و پاسخ‌ها را توصیف می‌کند. همچنین نمی‌توانند از مؤلفه‌های قابل‌استفاده‌مجدد در OAS 3.0 بهره ببرند، که باعث سنگین‌تر و وقت‌گیرتر شدن کار می‌شود.
در نهایت، بدون ارتقا به OAS 3.0، توسعه‌دهندگان نمی‌توانند از ویژگی‌های جدید مانند پشتیبانی بهتر از APIهای asynchronous یا Webhookها بهره‌مند شوند. بااین‌حال، رایج‌ترین دلیل برای به‌روزرسانی نکردن منظم OAS، عدم تمایل به نسخه‌ی تحمیلی JSON Schema است. وابستگی به ارائه‌دهندگان سرویس قدیمی مانند Google API Gateway یا AWS Gateway نیز یکی دیگر از دلایل رایج است.
جمع‌بندی نهایی درباره API Drift
APIContext گزارش خود را با برخی بهترین‌روش‌ها برای جلوگیری از API drift به پایان می‌برد. نخست اینکه توصیه می‌کند OAS عمومی، قابل‌جست‌وجو و دارای یک لینک مستقیم یا مخزن GitHub باشد که به‌طور منظم به‌روزرسانی شود. همچنین توصیه می‌کنند APIهای تولیدی را با Spec منتشرشده تست کنید تا drift به حداقل برسد.
APIهای نادرست و غیرقابل‌اعتماد نقش بزرگی در عدم تمایل برخی کاربران به پذیرش API دارند. بنابراین اطمینان از پایبندی API به مشخصات خود، باعث تشویق پذیرش API می‌شود، زیرا توسعه‌دهندگان می‌دانند که می‌توانند به API اعتماد کنند و اینکه API درست کار خواهد کرد. همچنین به کاهش ریسک از دست دادن کاربران و مشتریان بالقوه کمک می‌کند، که می‌تواند بر شهرت برند تأثیر منفی داشته باشد و هم‌زمان امنیت API را افزایش دهد.
طبق داده‌های Akamai، فراخوان‌های API بیش از ۸۰٪ از کل ترافیک اینترنت را تشکیل می‌دهند. می‌توان گفت افزایش شدید استفاده از API در دهه‌ی گذشته، ارتباط زیادی با پذیرش فرمت‌های استاندارد API مانند OpenAPI دارد. این فرمت‌ها بخش مهمی از همه‌چیز هستند، از تست API تا حذف Shadow APIها.
با توجه به اهمیت توصیف دقیق API، تأکید گسترده‌تر بر مزایای به‌روزرسانی منظم مشخصات API می‌تواند گامی بزرگ برای کاهش API drift باشد. با درنظرگرفتن اینکه چقدر می‌توان کسب کرد و چقدر ممکن است از دست برود، انگیزه‌های فراوانی برای جلوگیری از API drift با به‌روز نگه‌داشتن مشخصات API وجود دارد.
