من سعی میکنم هر روز یک پیادهروی طولانی داشته باشم. این ذهنم را روشن میکند، به من کمک میکند تصویر بزرگتر را ببینم و موضوعات جدید نوشتاری را کشف کنم. پیادهروی منظم همچنین ثابت شده است که فواید زیادی برای سلامتی دارد، از جمله بهبود سلامت قلب و عروق، کاهش ریسک افسردگی، بهبود متابولیسم و بهبود سلامت مفاصل. یک مطالعه حتی پیادهروی منظم را با حجم بالاتر مغز در سنین بالاتر مرتبط دانست.
پیادهروی اغلب به عنوان ابزاری برای شکل دادن به آگاهی و ارتقای درک و فهم ما از جهان استفاده میشود. من ایده strollology را دوست دارم، که توسط جامعهشناس سوئیسی Lucius Burckhardt ابداع شده است و اساساً در مورد علم راه رفتن است. فیلسوفان یونان باستان نیز در آگورا آتن قدم میزدند تا کنجکاویهای فکری خود را الهام بخشند. خلاصه اینکه، پیادهروی تأثیری بر مغز دارد.
چرا در یک بلاگ API درباره پیادهروی صحبت میکنم؟ خب، در سخنرانی افتتاحیه خود در Platform Summit 2024، من گشتی در برخی از روندهای اصلی اقتصاد API در سال ۲۰۲۴ زدم. من چند روند در جامعه API را بررسی کردم، نقش APIها در هوش مصنوعی، حاکمیت، نقض امنیت، استانداردهای جدید، تجربه توسعهدهنده و غیره را تجزیه و تحلیل کردم. همچنین واقعاً در صحنه به جلو و عقب قدم زدم.
بنابراین، بیایید از میان برخی از این روندها همانطور که در سال ۲۰۲۴ بودند عبور کنیم. میتوانید ارائه را تماشا کنید یا خلاصه متنی من را برای جزئیات خاص و زمینه بیشتر بخوانید. من این را مرور موضوعات رایجی میبینم که جامعه API درباره آنها بحث میکرد و نشانهای از مسیر آینده است.
همهگیری API
اولین نکته ساده این است که APIها همهجا حاضر هستند. APIها بسیاری از تجربههای کاربری، اکوسیستمهای شریک و معماریهای داخلی را پشتیبانی میکنند. آنها معماری ترکیبی را امکانپذیر میسازند و اساس بسیاری، اگر نه همه، شیوههای توسعه نرمافزار هستند. طبق نظرسنجی ۱۹ام Developer Economics از SlashData، نزدیک به ۹۰٪ توسعهدهندگان از APIها استفاده میکنند.
در سال ۲۰۲۳، من روی صحنه توضیح دادم که APIها چگونه بسیاری از قابلیتهایی را که در زندگی روزمره خود بدیهی میدانیم، پشتیبانی میکنند. اما APIها همچنین در حال گسترش در موارد استفاده داخلی هستند، مانند معماریهای مبتنی بر MACH، پوششدهندههای پایگاه داده، یکپارچهسازی دادههای غیرهمزمان، امنیت و احراز هویت کاربر. آنها اساس بسیاری از جریانهای کاری DevOps و اکوسیستمهای شریک هستند.
روندهای فناوری نوظهور در صنایع مختلف همچنان به شدت به APIها در پسزمینه متکی هستند. اما حتی با این گسترش، آگاهی آنها در داخل IT به طور گسترده اندک است. همانطور که Marco Palladino، CTO شرکت Kong، برای مقالهای که من برای InfoWorld درباره حاکمیت API نوشتم گفت: «با وجود اهمیت آنها، تعداد کمی از اهمیت APIها در IT یا اقتصاد جهانی آگاه هستند، زیرا این اساساً یک انقلاب خاموش بوده است.»
هوش مصنوعی و APIها
یکی دیگر از روندهای برجسته در گشت و گذار ما در اکوسیستم API، ظهور هوش مصنوعی است. هوش مصنوعی به سرعت به مصرفکننده انبوه رسید، به طوری که ChatGPT تنها در پنج روز به یک میلیون کاربر رسید. اکنون، چند سال پس از تب LLM، اکوسیستم هوش مصنوعی با مدلها و عاملهای هوش مصنوعی جدید در آستانه تواناییهای خودمختار رونق دارد. از طرف توسعهدهنده، طبق گزارش GitHub، ۹۲٪ برنامهنویسان اکنون از ابزارهای هوش مصنوعی استفاده میکنند.
من این دو حوزه را همزیست میبینم — توسعه هوش مصنوعی باعث رشد بیشتر و وابستگی به APIها شده است، زیرا توسعهدهندگان اغلب ویژگیهای محصولات هوش مصنوعی را از طریق APIها یکپارچه میکنند. عاملهای هوش مصنوعی خود از APIها برای دریافت داده، آموزش مجدد مدلها، تعامل با SaaS شخص ثالث و انجام تغییرات استفاده خواهند کرد.
هوش مصنوعی همچنین میتواند در سمت دیگر برای اطلاعرسانی طراحی API، تست API و امنیت API استفاده شود. هوش مصنوعی میتواند مدیریت API را با تولید مستندات با نمونههای بیشتر و بهبود تجربه پورتال توسعهدهنده تقویت کند. به عبارت دیگر، «آن APIها را برای شما تولید میکند و کدی را که APIها را مصرف میکند تولید خواهد کرد»، گفت Paul Dumas، استراتژیست API و تحلیلگر سابق Gartner در Austin API Summit 2024.
با این حال، هوش مصنوعی هنوز در حال تکامل است. مدلهای زبانی بزرگ (LLM) هنوز مستعد نادرستی، هالوسیناسیون، سوگیری و نگرانیهای حریم خصوصی و مالکیت معنوی هستند. بنابراین، با این روند — قدم بزنید، بدوید نه.
زبانهای توصیف API
زبانهای تعریف API همچنان در حال تکامل هستند. OpenAPI specification (که قبلاً Swagger نام داشت) هنوز نیروی غالب در استانداردهای API است و تکرار آن ادامه دارد، با نسخه ۴ با نام رمز Moonwalk در حال توسعه است. اما ما همچنین شاهد ورود فرمتهای جدید توصیف API بودهایم.
Arazzo، به معنای «قالیچه» در ایتالیایی، یک مشخصه جالب است. از OpenAPI Initiative، این افزونه برای OpenAPI به عنوان روشی استاندارد برای توصیف جریانهای کاری یا یک سری فراخوانهای API مرتبط طراحی شده است. همانطور که پوشش دادیم، موارد استفاده ممکن برای Arazzo شامل توالیهای قابل استفاده مجدد فراخوان برای هوش مصنوعی، اتصال امنیت، سیستمهای مدیریت منابع انسانی (HRM) و سیستمهای بهداشتی است.
TypeSpec، به عنوان مثال، یک زبان توصیف است که توسط مایکروسافت به صورت متنباز منتشر شده است. شکل و عملکرد آن بسیار شبیه TypeScript است و هدف آن کاهش مانع توسعه API مبتنی بر طراحی است. (خبر خوب این است که میتواند OpenAPI تولید کند، بنابراین همچنان با اکوسیستم سازگار است).
انحراف API
به طور کلی، من بسیاری از مزایای استفاده از رویکرد مبتنی بر مشخصه برای طراحی API را میبینم. اکثر افراد در فضای API موافقند که این میتواند به عنوان منبع حقیقت برای همکاری و ایجاد APIهای سازگار با تجربه توسعهدهنده با کیفیت عمل کند. با این حال، فرهنگهای واقعی مستندسازی-اول هنوز در ابتدای راه هستند — طبق مطالعه EMA، ۷۰٪ سازمانها حداقل ۳۰٪ از APIهای خود را مستندسازی نکردهاند.
آنچه بدتر است این است که APIها تمایل دارند از مشخصات خود در محیط تولید منحرف شوند. یک گزارش صنعتی از APIContext در ۲۰۲۴ نشان داد که ۷۵٪ APIها دارای نقاط انتهایی غیرمطابق هستند. این چندان خوب نیست، زیرا یک API که از رفتار مورد انتظار خود منحرف میشود میتواند باعث سردرگمی، شکستن توافقنامههای سطح سرویس و حتی ایجاد تغییرات مخرب در سمت کلاینت شود. چرا انحراف رایج است؟ چند دلیل ریشهای برای انحراف API وجود دارد، مانند نبود تست مداوم، جریانهای کاری قابل تکرار و کمبود آگاهی و انضباط در مورد استانداردهای توسعه طراحی-اول.
حاکمیت API
این ما را به یک کلمه شرکتی میرساند که به طور شگفتانگیزی اخیراً محبوب شده است — حاکمیت. پیروی از موضوع ما، حاکمیت مانند تابلوهای راهنمای مسیر است که به پیادهها کمک میکند روی مسیر مشخص باقی بمانند. حاکمیت API در پاسخ به نه تنها کمبود استانداردسازی بالا بلکه افزایش چشمگیر APIها در سراسر سازمانها به وجود آمده است.
سازمانهای بزرگ اغلب مجموعهای از فرمتهای API را به طور همزمان استفاده میکنند، از REST تا SOAP، معماریهای رویدادمحور، GraphQL، gRPC و غیره. در حالی که استفاده از ابزار مناسب برای کار بد نیست، پیچیدگی زمانی افزایش مییابد که سبکهای طراحی مختلف استفاده شوند، همراه با چندین دروازه و راهکار مدیریت API. این یک دستور العمل برای مشکلات پراکندگی است.
حاکمیت API معانی زیادی دارد و با یک محصول جامع حل نمیشود. اما به طور کلی، به متمرکز کردن استانداردهای طراحی و الگوهای امنیتی (شامل حوزههایی مانند هویت و کنترل دسترسی) اشاره دارد. موجودی یا فهرستبندی APIها، نظارت بر فرآیندهای مدیریت تغییر مناسب و تلفیق ابزارها و دروازههای پراکنده.
بسیاری از شرکتها هماکنون ابتکارات حاکمیت API را اتخاذ میکنند. به عنوان مثال، برنامه داخلی Atlassian در حال توسعه استانداردهای گسترشپذیری برای انجام بررسیهای خودکار برای اعمال قوانین و سیستماتیک کردن فرآیند مدیریت تغییر API است. این منجر به افزایش ثبات برای شرکای آنها با یکپارچهسازی کمتر شکست خورده میشود.
تجربه توسعهدهنده
به نظر من بهترین مسیرها چرخهای هستند. اگر ادامه دهید، به جایی که شروع کردهاید باز میگردید. گم نمیشوید! تجربه توسعهدهنده عالی (DX) بیش از داشتن نقطه شروع سریع و آسان است. APIهای با تجربه توسعهدهنده با کیفیت اطمینان میدهند که توسعهدهندگان در طول مسیر از کشف، ثبتنام، تست، یکپارچهسازی، نگهداری و نسخهبندی گم نمیشوند.
جالب اینکه، ۸۸٪ شرکتهای نظرسنجی شده توسط Lunar.dev میگویند مسائل مرتبط با APIهای شخص ثالث نیازمند توجه هفتگی هستند. بنابراین، تلاشهای بیشتر برای نگهداری مداوم برای پشتیبانی از یکپارچهسازی APIها فراتر از لحظه «Hello World» لازم خواهد بود. ابتکارات هوش مصنوعی که به صورت برنامهنویسی با شرکا ارتباط دارند، به پورتالها و داشبوردهای توسعهدهنده با کیفیت وابسته هستند که قابل فهم و ناوبری آسان باشند.
بنابراین، چه چیزی تجربه توسعهدهنده API عالی را امروزه میسازد؟ بسیاری از اصول پایه هنوز معتبر هستند: مستندات عالی، تغییرات پایدار، پیامهای خطای قابل فهم برای انسان، مشخصات OpenAPI عمومی، قابلیتهای self-service، نمونه کد و طراحی و نامگذاری سازگار. یک مثال جالب از ارائهدهنده API که تجربههای توسعهدهنده جدید را پیشگام کرده، Plaid است که یک عامل مکالمهای به نام Bill (بیارتباط!) در پورتال توسعهدهنده خود دارد.
اما فراتر از تجربههای مبتنی بر API، از SDKها تا مهندسی پلتفرم، نقش تجربه توسعهدهنده همچنان در حال تقویت است. من استدلال میکنم که DX اکنون از یک مزیت رقابتی به یک انتظار تبدیل شده است، و اکثر افراد موافقند که سرمایهگذاری در DX در بلندمدت هزینهها را کاهش میدهد.
حملات به APIها
تعجبآور نیست که با افزایش وابستگی به APIها، تعداد حملات نیز افزایش یافته است. بخشی از مشکل این است که مسائل ساده کنترل دسترسی ناقص فراگیر هستند. گزارش ۲۰۲۴ از Akamai نشان داد که حملات وب به برنامهها و APIها بین Q1 2023 و Q1 2024، ۴۹٪ افزایش یافته است. آنها همچنین گزارش دادند که ۱۰۸ میلیارد حمله API از ژانویه ۲۰۲۳ تا ژوئن ۲۰۲۴ ثبت شده است. احراز هویت و مجوز ناکارآمد API در قلب بسیاری از این نقضها قرار دارد.
در سال ۲۰۲۴، همچنین افزایش بحث در مورد shadow APIها و zombie APIها را دیدیم. گزارش State of API Security، انجام شده توسط Salt Labs، نشان داد که APIهای قدیمی zombie به عنوان یک نگرانی اصلی در میان متخصصان فناوری بررسی شدهاند. آسیبپذیریهای دیگر در ۱۰ مورد برتر OWASP برای APIها ظاهر شدهاند، شامل ریسکهای مربوط به شکاف منطق کسبوکار، کمبود مدیریت موجودی و غیره.
فراتر از پایش امنیت زمان اجرا، بسیاری معتقدند که بخش مدیریت هویت و دسترسی میتواند بسیاری از مسائل مرتبط با امنیت API، پراکندگی و حاکمیت را حل کند. به ویژه در سازمانهای بزرگ، کنترل هویت مشتری میتواند سازگاری با جریانهای امنیتی استاندارد را فراهم کند و به کاهش پراکندگی با یکپارچهسازی مدیریت دسترسی با سیاستهای مبتنی بر نقش داخلی کمک کند.
کسبوکار API-محور
مدلهای کسبوکار API-محور همچنان در حال رشد هستند، با ۶۲٪ از پاسخدهندگان که میگویند شرکتشان از APIها برای تولید درآمد استفاده میکند، طبق گزارش State of the API 2024 از Postman. از دیدگاه توسعه، API-محور نیز میتواند مزایای ملموس تولید کند. «وقتی API-محور هستید، مشکلاتی مانند پراکندگی و انحراف میتوانند از بین بروند»، Noah Schwartz، رئیس شبکه API Postman، به من گفت. با این حال، او اعتراف میکند که API-محور در عمل کمی متفاوت است و همه به همان اندازه پیشرفت نکردهاند و به برخی خلأها در ابزارها و توسعه مبتنی بر مشخصات اشاره میکند.
روند جالب دیگر اخیراً جداسازی مدیریت API است، که به مهاجرت از پلتفرمهای مدیریت چرخه کامل API به ابزارهای سبک و هدفمند مربوط میشود. ایده این است که استفاده از بهترین دروازههای API میتواند هزینهها را کاهش دهد و از ویژگیهای اضافه مرتبط با پلتفرمهای بزرگتر جلوگیری کند.
مسیرهای خوش
این یک برش عرضی از موضوعات جالبی است که جامعه API در سال ۲۰۲۴ درباره آنها بحث میکرد. پس، سال ۲۰۲۵ چگونه خواهد بود؟
به طور کلی، من پیشبینی میکنم علاقه بیشتری به تعامل بین APIها و هوش مصنوعی باشد. فکر میکنم شاهد علاقه بیشتر به APIها به عنوان پایهای برای هوش مصنوعی عاملمحور، نحوه موقعیتدهی APIها برای مصرف هوش مصنوعی و بهینهسازی یکپارچهسازی و فراخوانهای backend برای عملکرد و صرفهجویی در هزینه خواهیم بود. APIهای باز بیشتری برای اتصال ساختار پشت صحنه لازم است. در غیر این صورت، توسعهدهندگان راههای جایگزین برای دسترسی به دادهها پیدا خواهند کرد — یک معضل که Z بهخوبی آن را شناسایی میکند.
محدودیت دیگر خود دادهها است. عاملهای هوش مصنوعی به دلیل دادههای ناکافی یا دستهبندی نادرست یا عدم دسترسی به آنها محدود شدهاند. من معتقدم APIها، علاوه بر مکانیسمهای استاندارد بازیابی پایگاه داده، نقش مهمی در اتصال سیستمها برای توانمندسازی عاملها با زمینه و قابلیتهای بیشتر ایفا خواهند کرد.
توسعههای هیجانانگیز بیشتری در مسیر به سمت سال جدید وجود دارد. منتظر بینشهای خاصتر باشید زیرا به زودی پیشبینیهای روند ۲۰۲۵ را بررسی خواهیم کرد.
