چگونه چهرهٔ APIها در حال تغییر می‌باشند؟

چند سال گذشته برای APIها بسیار مهم بوده است، از ظهور معماری API-first تا پذیرش گستردهٔ ابزارهایی مانند API gateways. و در سال ۲۰۲۴، هیچ نشانه‌ای از کند شدن دیده نمی‌شود — این فضا حتی سریع‌تر از قبل در حال تکامل است.

با نگاهی به برنامهٔ Austin API Summit که در مارس ۲۰۲۴ برگزار می‌شود، متوجه شدیم چندین موضوع مشابه بارها و بارها تکرار می‌شوند. هم‌راستایی این روندهای جدید نشان می‌دهد بسیاری از ما در حوزهٔ API دغدغه‌های مشترکی داریم. از تغییرات در بهترین شیوه‌ها در زمینهٔ استانداردها و درآمدزایی گرفته تا تغییرات عظیم در نحوهٔ توسعه و مستندسازی APIها، بسیاری از سخنرانان آستین آماده‌اند دربارهٔ مهم‌ترین تحولات فعلی صنعت صحبت کنند.

اغراق نیست اگر بگوییم توسعه‌دهندگان و شرکت‌های API-first باید این روندها را بپذیرند — یا حداقل به آن‌ها توجه کنند — تا مرتبط باقی بمانند. در این نوشتار، به چهار تغییر عمده در نحوهٔ تفکر دربارهٔ APIها در ۲۰۲۴ و معنای آن برای کسب‌وکارهای API-first می‌پردازیم.

۱. نسل جدیدی از زبان‌های توصیف API

مایکروسافت گرت جونز پرسش بلاغی زیر را مطرح می‌کند: «مگر جنگ توصیف APIها در ۲۰۱7 تمام نشد وقتی همه توافق کردیم OpenAPI Specification (OAS) راه آینده است؟ بله،» او ادامه می‌دهد، «اما چقدر از توصیف API خود راضی هستید؟»

پاسخ بسیاری از توسعه‌دهندگان API این است: «نه کاملاً.» در گزارش 2023 State of the API، پست‌من تمام انواع مشخصاتی را فهرست کرده که در چشم‌انداز API Platform به‌طور فعال استفاده می‌شوند:

OpenAPI
AsyncAPI
WSDL
Thrift
Protobuf
gRPC
GraphQL
RAML
Avro
API Blueprint
JSON Schema

طول این فهرست نشان‌دهندهٔ موجی از نارضایتی در حوزهٔ مستندسازی است، با اینکه OpenAPI (و AsyncAPI در سناریوهای رویدادمحور) بالغ و غالب است، اما همچنان برخی به دنبال گزینه‌های جایگزین هستند. نمی‌خواهیم آن‌قدر جسور — یا کلیک‌گیر — باشیم که بگوییم ۲۰۲۴ پایان OpenAPI خواهد بود. با این حال، نسل جدیدی از زبان‌های دامنه‌محور (DSLs) مانند Smithy آمازون و TypeSec متن‌باز مایکروسافت می‌توانند جریان را تغییر دهند.

گرت در آستین با ما خواهد بود تا توضیح دهد چگونه این زبان‌های انتزاعی‌تر، به گفتهٔ خودش، «ما را به یک رویکرد هدفمندتر در طراحی بازمی‌گردانند و فرصت می‌دهند ویژگی‌های تجاری مهم را در زمان طراحی برجسته کنیم.» مندی وِیلی از مایکروسافت نیز دربارهٔ استفادهٔ مایکروسافت از TypeSec برای ارائهٔ API در مقیاس عظیم در حالی که همچنان با اکوسیستم OpenAPI سازگار است، سخن خواهد گفت. مشتاقیم استدلال‌های آن‌ها دربارهٔ TypeSec و سایر DSLها را بشنویم.

۲. امنیت، استانداردها و غیرمتمرکزسازی

قبلاً دربارهٔ اینکه چگونه استانداردهای بانکداری باز در جهان در حال تغییر فضاهای فین‌تک هستند، بسیار نوشته‌ایم. همچنین به‌تازگی دربارهٔ اینکه هویت غیرمتمرکز چگونه بانکداری را دگرگون خواهد کرد، نوشته‌ایم.

در ظاهر، این روندها متناقض به نظر می‌رسند — غیرمتمرکزسازی دربارهٔ انعطاف‌پذیری و توانمندسازی کاربر است، در حالی که استانداردها دربارهٔ قراردادن همه چیز در قالب‌های مشخص هستند. اما در عمل، غیرمتمرکزسازی به استاندارد نیاز دارد تا مؤسسات مالی بزرگ آن را جدی بگیرند.

با رسمی‌تر شدن روند توسعهٔ API، شاهد ظهور استانداردهای مختلف هستیم. و در سوی دیگر — امنیت و استانداردها شاید برادر نباشند، اما قطعاً پسرعمو هستند — نیاز به امنیت قوی‌تر نیز در حال افزایش است.

کریس وود، متخصص بانکداری باز، می‌گوید: «هرچند استانداردهایی مانند FAPI بسیار مستحکم هستند و با بازار تکامل یافته‌اند، اما پیاده‌سازی آن‌ها می‌تواند پیچیده باشد.» او آن‌ها را نعمتی دوپهلو می‌داند: «بخش‌های عالی داریم، مانند استفاده از استانداردهای باز مثل OpenAPI برای تعریف APIهایی که بازار باید اجرا کند،» و «بخش‌های نه‌چندان عالی، مانند اینکه نهادهای استاندارد همچنان به اسناد حجیم PDF تکیه می‌کنند.»

در این حوزه، سخنرانان ما موضوعاتی دربارهٔ استانداردها و امنیت API پوشش خواهند داد: مدیریت مجوز API با استفاده از سرور هویت و درگاه، فراتر رفتن از OAuth با چارچوب‌های مجوزدهی دقیق‌تر، و شناسایی و مقابله با بزرگ‌ترین تهدیدهای امنیتی API طبق OWASP.

وود نتیجه‌گیری می‌کند: «با موج بعدی استانداردسازی — که احتمالاً با PSD3 در اتحادیه اروپا آغاز می‌شود — در آستانهٔ کشف این هستیم که آیا استانداردهای API می‌توانند واقعاً یک توانمندساز باشند و یک اکوسیستم باز و یکپارچه ایجاد کنند.»

در سوی دیگر ماجرا، ممکن است در آستانهٔ کشف این باشیم که چه اتفاقی می‌افتد وقتی ارائه‌دهندگان API نتوانند استانداردهای امنیتی لازم را رعایت کنند — استانداردهایی که برای پیروی از قوانین رو‌به‌رشد حفاظت از داده ضروری هستند…

۳. APIها، هوش مصنوعی و اتوماسیون

جای تعجب نیست که AI در ۲۰۲۴ موضوعی بزرگ و شاید بحث‌برانگیز خواهد بود، و این در برنامهٔ همایش آستین نیز بازتاب دارد. برای مثال، پل دوماس از گارتنر سخنرانی اصلی دربارهٔ استفاده از GenAI برای تولید API خواهد داشت. او می‌گوید:

«انسان‌ها نمی‌توانند با قدرت محاسباتی APIها رقابت کنند. چگونه این قدرت را مدیریت کنیم، بر خروجی آن نظارت داشته باشیم و از آن بهره ببریم؟ [در ۲۰۲۴ و بعد از آن،] ما بیشتر بر توانایی‌هایی تکیه خواهیم کرد که در انسان وجود دارد و ماشین نمی‌تواند تقلید کند.»

به عبارت دیگر، چگونه می‌توانیم همچنان APIهایی بسازیم که «لمس انسانی» خود را حفظ کنند؟ چالشی که ابزارهای خودکار — چه مبتنی بر AI و چه بدون آن — با آن روبه‌رو هستند.

کریستن وومک از مایکروسافت گفته است ساخت دستی SDKها پرهزینه، زمان‌بر و نیازمند توسعهٔ چندزبانه است. خودکارسازی وظایفی مانند تولید SDK صرفه‌جویی چشمگیری در زمان و هزینه ایجاد می‌کند بدون اینکه کاربرپسندی را قربانی کند.

مایکروسافت برای حل این مشکل، Kiota — یک ابزار خط فرمان متن‌باز — را تأمین مالی می‌کند که می‌تواند برای هر API توصیف‌شده با OpenAPI یک کلاینت تولید کند. سایر شرکت‌ها معتقدند AI می‌تواند راه‌حل بهتری برای غنی‌سازی مستندات و تجربهٔ توسعه‌دهنده باشد.

به‌عنوان مثال، تاد کرپلمن از Plaid یک چت‌بات AI به نام Bill ساخته تا به توسعه‌دهندگان در پیمایش مستندات Plaid کمک کند.

در جای دیگر، روبن سیتبون از Sipios استدلال می‌کند که هر محصولی را می‌توان با استفاده از GenAI بهبود داد. او در آستین دربارهٔ استفاده از GenAI در APIهای داخلی برای تقویت ویژگی‌ها، بهبود پاسخ‌ها با استفاده از یک API آموزش‌دهنده، و افزودن امنیت و انطباق به APIها صحبت خواهد کرد.

با وجود تمام پیشرفت‌هایی که تاکنون دیده‌ایم، هنوز ظرفیت عظیمی برای استفاده از AI در جنبه‌های مختلف توسعهٔ API وجود دارد — به‌ویژه بخش‌هایی که زمان‌بر، حساس یا تکراری هستند.

۴. کسب درآمد از APIها

در چند سال اخیر، نگرش‌ها به APIها از پروژه‌های سرگرمی و ابزارهای داخلی برای تکنولوژی‌دوستان به سمت ارائه‌های جدی کسب‌وکار تغییر کرده است. این تغییر هنوز ادامه دارد… و برخی معتقدند پایان “API-first” همان “API-only” است.

بازار مدیریت API که اکنون بیش از ۴٫۵ میلیارد دلار ارزش دارد، پیش‌بینی می‌شود تا سال ۲۰۳۰ به بیش از ۲۵ میلیارد دلار برسد. طبق The New Stack، این رشد «بر اساس یک ایدهٔ واحد هدایت می‌شود: APIها کاملاً بر دنیای دیجیتال کنترل دارند.»

ما از قبل مدل‌هایی مانند نتفلیکس را دیده‌ایم، که صدها میکروسرویس برای ارائهٔ ویدئو به دستگاه‌های مختلف استفاده می‌کند. آن‌ها زمانی در یک پست وبلاگی در ۲۰۱۳، APIها را «گردن باریک» در ساعت شنی استعاری پشتهٔ فناوری خود نامیدند.

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

و هرچند امنیت و انطباق همیشه برای APIها حیاتی بوده است، اما تبدیل APIها به محصول این اهمیت را چند برابر می‌کند. لینک دوباره ماجرا به استانداردسازی می‌رسد: پل بین مستندات انسان‌خوان و ماشین‌خوان (و بنابراین قابل‌بررسی توسط ماشین) چیزی است که می‌تواند خطاها را کاهش دهد.

APIها در حال تغییرند... و در عین حال همان‌اند

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

در نهایت، بسیاری از موارد فوق بهبود هستند، نه جایگزینی. این همان نتیجه‌گیری است که دیوید براون، مدیرعامل Toro Cloud، و کن لین، API Evangelist، در یک قسمت پادکست Coding Over Cocktails دربارهٔ زبان‌های توصیف API به آن رسیده‌اند:

«این ذهنیت که "GraphQL بهتر از OpenAPI است" یا بالعکس ممکن است کمکی نکند. مسئله این نیست که کدام‌یک جنگ را می‌برد. بیایید مزایا و موارد استفادهٔ هرکدام را بررسی کنیم و ببینیم چگونه می‌توانند مکمل یکدیگر باشند.»