بطور کلی API-First چیست؟

رسیدن به اصل معنای API-First بودن (Getting to the Bottom of What It Means to Be API-First)

در جامعه‌ی API، بحثی همیشگی میان رویکردهای طراحی-محور و کدنویسی-محور وجود دارد. بسیاری از طرفداران توسعه‌ی API-First از اصول آن دفاع کرده و حتی از یک رویکرد مبتنی بر مشخصات برای طراحی API استفاده می‌کنند. در مقابل، برخی دیگر اشاره می‌کنند که طراحی API در دنیای مهندسی نرم‌افزار اغلب بسیار متفاوت به نظر می‌رسد. «آیا توسعه‌ی API به‌صورت طراحی-اول واقعی است؟ یا فقط خیال‌پردازی می‌کنیم؟» این پرسشی است که تبلیغ‌گر API، کین لین مطرح می‌کند.

گزارش «State of the API 2024» از Postman نشان می‌دهد که توسعه‌ی API-First رو به افزایش است. با این حال، یافته‌ها نشان می‌دهند که هنوز شکاف‌هایی در نحوه‌ی اجرای آن وجود دارد. من اخیراً با «نوآ شوارتز»، رئیس شبکه API در Postman، برای بررسی روندهای جدید صنعت API و آینده‌ی احتمالی توسعه‌ی API-First صحبت کردم. جای تعجب نیست که او از طرفداران سرسخت رویکرد API-First است. او می‌گوید: «وقتی API-First هستید، مشکلاتی مثل پراکندگی یا واگرایی از بین می‌روند.»

یک رویکرد طراحی‌محور در توسعه API می‌تواند چالش‌های فراوانی را حل کند، از جمله مشکلات UX/UI، تغییرات مخرب، تجربه‌ی ضعیف توسعه‌دهندگان و موارد دیگر. در ادامه، برخی یافته‌های Postman را بررسی می‌کنیم و تلاش می‌کنیم معنای واقعی API-First بودن و آینده‌ی صنعت را بهتر درک کنیم. یک اشاره: آینده چندان با فراگیری سیستم‌های کنترل نسخه تفاوتی ندارد.

شکاف موجود در اجرای عملی API-First

یکی از عدم‌تطابق‌های جالب در گزارش امسال Postman، میزان فراگیری API-First در برابر نحوه‌ی یادگیری API توسط توسعه‌دهندگان است. این مطالعه که بیش از ۵۶۰۰ توسعه‌دهنده و متخصص API را بررسی کرده، یافته است: «در سال ۲۰۲۴، حدود ۷۴٪ از پاسخ‌دهندگان API-First هستند؛ این رقم در سال ۲۰۲۳ برابر با ۶۶٪ بوده است.» محبوبیت API-First به دلیل زمان تولید سریع‌تر و بازیابی بهتر از خطاها روزبه‌روز بیشتر می‌شود.

درحالی‌که ۵۸٪ از توسعه‌دهندگان برای یادگیری API به مستندات داخلی رجوع می‌کنند، بخش قابل توجهی (۴۴٪) می‌گویند برای درک APIها، سورس‌کد را جست‌وجو می‌کنند. بسیاری نیز به چت یا ایمیل وابسته‌اند. این موضوع عجیب است. اگر سازمان‌ها واقعاً API-First بودند، باید مشخصات دقیق API، مستندات مرجع قابل‌فهم، و پورتال توسعه‌دهنده با قابلیت جستجو و دسترسی آسان فراهم می‌کردند.

به نظر شوارتز، این یافته‌های جداگانه نشان می‌دهد که اگرچه API-First جذاب است، اما در عمل ضعف‌هایی دارد. او می‌گوید: «این موضوع در چرخه‌ی پذیرش فناوری کاملاً طبیعی است. مردم می‌گویند به چیزی باور دارند و درباره‌اش تبلیغ می‌کنند، اما هنوز کاملاً آن را اجرا نمی‌کنند.» شاید افراد زیادی به API-First اعتقاد دارند، اما بقیه سازمان یا ابزارهایشان هنوز همگام نشده‌اند.

بررسی عمیق‌تر مفهوم API-First

در API-First، شما از انتها شروع نمی‌کنید. شوارتز API-First را طراحی API و ثبت همه چیز در یک مکان و پیروی از منبع حقیقت تعریف می‌کند؛ مشابه استفاده از کنترل نسخه. پیروی از یک منبع حقیقت — یعنی کار با یک مشخصات API — کمک می‌کند اختلافات همکاری که در آن اعضای تیم با اطلاعات پراکنده کار می‌کنند، از بین برود. او اضافه می‌کند که مستندسازی فراخوان‌های API و جزئیات احراز هویت در یک ابزار یکپارچه می‌تواند این موضوع را تقویت کند.

توسعه‌ی APIها به‌عنوان یک مرحله‌ی پس‌از‌افکار، مشکلاتی مثل ضعف UX، واگرایی API، و تغییرات مخرب ایجاد می‌کند. در عوض، شوارتز تأکید می‌کند که باید هدف و نقش API را در ابتدا مشخص کرد و تعیین نمود که پیش از آغاز کدنویسی، چگونه با UI تعامل خواهد داشت. داشتن گفتگو درباره ارکستراسیون داده‌ها از ابتدا می‌تواند UX را بهینه کند و از بازگرداندن داده‌های اضافی جلوگیری کند که ممکن است کارایی را کاهش داده یا باعث سنگینی سیستم شود.

جالب است که وضعیت فعلی API-First را می‌توان با دوران قبل از استاندارد شدن کنترل نسخه مقایسه کرد. امروزه تصور اینکه همکاری، کد را فقط روی سیستم محلی خود نگه دارد و آن را در کنترل نسخه ثبت نکند، غیرممکن است. شوارتز معتقد است توسعه‌ی طراحی-اول API نیز به چنین مرحله‌ای خواهد رسید. «چرخه‌ی پذیرش عقب‌تر از چرخه‌ی تبلیغ است. این یک فرصت برای API-First بودن است.»

همراه‌کردن همه با رویکرد API-First

گزارشی اخیر از APIContext نشان می‌دهد که ۷۵٪ از APIها دارای اندپوینت‌های ناسازگار هستند، که نشان‌دهنده‌ی واگرایی API از منبع حقیقت در محیط عملیاتی است. پس چگونه می‌توان دیگران را به مزایای API و حرکت به سمت رویکرد طراحی-اول ترغیب کرد؟

از نگاه شوارتز، API-First یعنی همکاری. APIها ذاتاً یک محصول دوطرفه‌اند و همکاری اولیه مزایای قابل توجهی برای ذینفعان ایجاد می‌کند. API-First به تولیدکنندگان کمک می‌کند APIهایی بسازند که بتوانند در سراسر اپلیکیشن‌ها استفاده شوند، و طراحی مستقل از پلتفرم برای این موضوع ضروری است.

رویکرد API-First همچنین می‌تواند به نسخه‌بندی و استراتژی‌های بازنشستگی کمک کند، زیرا یکپارچگی یکپارچه‌تری ایجاد می‌شود. با این حال، شوارتز اعتراف می‌کند که برخی شرکت‌ها مدیریت تغییر را بسیار بهتر از دیگران انجام می‌دهند. او می‌گوید: «در AWS، زمانی که یک تغییر مخرب رخ می‌داد — که بسیار نادر بود — تا زمانی که با تمام مشتریان صحبت نمی‌کردیم، آن را اجرا نمی‌کردیم. اگر نمی‌توانستیم به همه برسیم، آن را کنار می‌گذاشتیم.» او به یاد دارد که یک API روی یک سیستم توکار، فقط برای یک مشتری حفظ شد! البته SLAهای امروزی چنین چیزی را عملی نمی‌دانند، اما این داستان نشان‌دهنده‌ی تعهد عمیق به برخورد با API به‌عنوان یک قرارداد و احترام به تجربه توسعه‌دهنده است.

او ادامه می‌دهد که APIها باید قابل استفاده باشند، که نیازمند تمرکز بیشتر بر API-First است. «مسئولیت ارائه یک API در طول زمان تغییر کرده است. تجربه‌ی خوب توسعه‌دهنده اکنون یک اصل پایه است.» آسان بودن اولین فراخوان و فرآیند ساده‌ی ورود می‌تواند یک API را موفق یا نابود کند. چه API عمومی باشد و چه داخلی، انتظار این است که کاربردپذیری و سهولت استفاده در حد استانداردهایی مثل Stripe باشد.

چشم‌انداز آینده API-First: داستانی برای هر صنعت

شوارتز می‌گوید: «تمام نرم‌افزارها تبدیل به API خواهند شد.» او اضافه می‌کند: «وقتی محصول، API باشد، نیاز به پذیرش آن بیشتر می‌شود.» گذار کامل مدافعان امروز API-First به سطح «عمل‌کنندگان واقعی API-First» به‌مرور اتفاق خواهد افتاد. اما شاید لازم باشد یک‌سری اتفاقات منفی — مانند تغییرات مخرب، قطعی‌ها، سختی در کشف APIها یا آسیب‌پذیری‌ها — صنعت را به این سمت سوق دهد.

او توضیح می‌دهد: «واگرایی نتیجه عدم API-First بودن است.» در ابزارهای زیرساخت-به‌عنوان-کد مانند Ansible، قابلیت‌های تشخیص واگرایی کمک می‌کنند سیستم‌ها هماهنگ بمانند و تغییرات غیرمنتظره را کاهش دهند. مشابه همین، سرمایه‌گذاری روی ابزارهای مدیریت API می‌تواند قابلیت‌های بازرسی و کشف فراهم کند که با نگه‌داشتن توسعه در مسیر درست، از واگرایی جلوگیری می‌کند.

حاکمیت قوی‌تر API نیز می‌تواند این تحول را پیش ببرد. اگرچه برخی، «حاکمیت» را واژه‌ای ناخوشایند می‌دانند، مدیران ارشد به آن متوسل شده‌اند تا از پراکندگی API جلوگیری کنند. حاکمیت حتی می‌تواند اثرات مثبت بزرگی ایجاد کند، مانند اطمینان از اینکه سیستم‌های سلامت از استاندارد API مبتنی بر FHIR پیروی می‌کنند تا داده‌ی بیمار به‌درستی منتقل شود. شوارتز می‌گوید: «شاید حاکمیت کلمه‌ی جذابی نباشد، اما نیت آن مثبت است. تا زمانی که در نهایت به مشتری خدمت کند، نیرویی سازنده است.»

حتی سازمان‌های قدیمی مانند USPS — تأسیس‌شده در قرن ۱۸ — اکنون در تقریباً تمام مراحل پردازش لجستیک خود به صدها API متکی هستند. همین رشد گسترده در صنایعی مانند بازی، بانکداری و حتی فراتر از آن دیده می‌شود. او می‌گوید: «واقعیت این است که در هر صنعتی یک داستان API وجود دارد.»