از روزگاران بسیار دور، خیلی پیش از رسالهٔ روی فیلدینگ دربارهٔ REST و تقریباً هم‌زمان با اولین باری که عبارت «هم‌راستایی استراتژیک» در جمع عمومی به زبان آمد، یک معمار سازمانی این پرسش را مطرح کرد: آیا نرم‌افزارمان را خودمان بسازیم یا بخریم؟ این پرسش یکی از قطعات کلاسیک پازل فناوری اطلاعات است؛ جست‌وجویی بی‌پایان برای روشنایی تا سازمان مطمئن شود پولش را با انتخاب درست منبع‌یابی ابزارهای نرم‌افزاری عاقلانه خرج می‌کند.
تقریباً هزار سال به جلو بیاییم، هنوز در زمینهٔ اقتصاد API و به‌ویژه برای OpenAPI همان پرسش را می‌پرسیم. OpenAPI توسط مجموعهٔ عظیمی از ابزارها و پلتفرم‌ها در تمام چرخهٔ حیات API پشتیبانی می‌شود؛ ابزارها و پلتفرم‌هایی که کارکردهای متفاوت دارند و اهداف متعددی را برآورده می‌کنند.
با این حال، اکوسیستم گستردهٔ OpenAPI همیشه برای معماران سازمانی (یا هر کسی که به دنبال ابزارهای OpenAPI است) ساده نیست. پیش از شروع جست‌وجو برای ابزارهای OpenAPI یا تصمیم به ساختن آن‌ها، باید از خودتان بپرسید اهداف‌تان چیست تا بتوانید پرسش «ساختن در برابر خریدن» را با موفقیت پاسخ دهید.
تجربهٔ ساخت ابزارهای OpenAPI
ساخت ابزارهای اختصاصی OpenAPI یا ایجاد ابزارهایی که دیگران مصرف کنند، مسیری است که بسیاری از توسعه‌دهندگان طی کرده‌اند. اکوسیستم ابزارها بسیار گسترده است. همان‌طور که وب‌سایت ابزارهای OpenAPI Initiative نشان می‌دهد، ابزارهای بی‌شماری از انواع مختلف وجود دارد و تعداد زیادی راه‌حل تجاری نیز در دسترس است تا به سازمان‌ها هم به‌عنوان ارائه‌دهندهٔ API و هم به‌عنوان مصرف‌کنندهٔ API کمک کند. با این حال، یک ابزار آماده همیشه نیازهای سازمانی را برآورده نمی‌کند، به دلایل متعدد.
اجلاس آستین ۲۰۲۴ ما به دلایل زیادی قابل توجه بود، از جمله سخنرانی آدام لِوِنتال دربارهٔ همین موضوع. لِوِنتال از شرکت Oxide Computer است و تجربهٔ ساخت ابزارهای OpenAPI از صفر را ارائه کرد. شرکت Oxide از OpenAPI برای راه‌حل «ابر خصوصی در جعبه» خود استفاده می‌کند؛ جایی که رویکرد کد-اول مبتنی بر زبان Rust را برای ساخت لایهٔ API و در نتیجه توصیفات OpenAPI پلتفرم خود ترجیح دادند.
تجربهٔ Oxide با اکوسیستم ابزارهای OpenAPI به گفتهٔ لِوِنتال چندان خوب نبود. یکی از نیازمندی‌های Oxide تولید کلاینت بر اساس توصیفات OpenAPI بود که از ابزار Dropshot خودشان تولید می‌شد. ابزارهای موجود OpenAPI برای Rust به‌سادگی نیازهای Oxide را برآورده نمی‌کردند، بنابراین شروع به ساخت ابزار داخلی خود به نام Progenitor کردند. Progenitor یک crate در Rust است که کلاینت API را بر اساس توصیف OpenAPI تولید می‌کند و بخش مهمی از نحوهٔ پشتیبانی Oxide از پلتفرم‌هایشان است.
مواجهه با اصطکاک در OpenAPI
سخنرانی لِوِنتال چالش‌هایی را که Oxide با OpenAPI داشت توصیف کرد. تجربهٔ لِوِنتال این بود که OpenAPI یک مشخصهٔ بسیار گسترده است که به موارد حاشیه‌ای زیادی پاسخ می‌دهد. او گفت: «هشت روش متفاوت برای گفتن یک چیز وجود دارد.» این انعطاف‌پذیری یعنی انتخاب‌های طراحی بسیار زیاد است و پیدا کردن گزینهٔ درست همیشه ساده نیست.
علاوه بر این، هدف پیاده‌سازی رویکرد کد-اول برای کنترل شکل API در کد به این معنا بود که باید بسیاری از موارد حاشیه‌ای نادیده گرفته می‌شدند. لِوِنتال گفت: «ما سعی می‌کردیم انعطاف‌ناپذیر باشیم و فقط یک روش خاص را دنبال کنیم.» او صراحتاً اعلام کرد که ساخت ابزاری که از OpenAPI استفاده می‌کند باید برای یک مورد استفاده یا صورت مسئلهٔ مشخص طراحی شود. او گفت: «نیازی نیست مسئلهٔ عمومی را حل کنید، باید مسئلهٔ خودتان را حل کنید.» این تمرکز تک‌منظوره ممکن است برای سازندگان ابزارهایی که طیف وسیعی از موارد استفاده را پوشش می‌دهند مناسب نباشد، اما برای سازمان‌هایی که نیاز مشخصی به پیاده‌سازی ابزارهای خودساخته دارند حیاتی است.
مسیر پیش رو: ساخت یک ابزار OpenAPI
نتیجه‌گیری لِوِنتال نشان می‌دهد که ساخت Progenitor با پشتیبانی OpenAPI تصمیم درستی بود: «OpenAPI درست بود… حتی اگر اکوسیستم آن‌طور که امیدوار بودیم نبود.» این نتیجه‌گیری بینش ارزشمندی دربارهٔ ارزش استفاده از OpenAPI ارائه می‌دهد، یعنی: اکوسیستم بسیار عظیم است و جامعهٔ توسعه‌دهندگان شما بدون شک ابزارهایی را که برای مصرف APIهایتان نیاز دارند پیدا خواهند کرد. اما این همیشه تضمین‌شده نیست. دلایلی که ممکن است مجبور شوید ابزارهای OpenAPI خود را بسازید عبارتند از:
- موارد استفادهٔ خاص: مورد Oxide خاص بود و کیفیت مورد نیازشان از یک مولد کد بسیار بالا بود. یک مورد استفادهٔ خارج از مسیرهای معمول، وزن بیشتری به استدلال ساخت ابزارهای OpenAPI می‌دهد.
- پشتیبانی از نسخه‌ها: سازندگان ابزارها با سرعت خودشان ابزارهایشان را توسعه می‌دهند. ممکن است فاصلهٔ قابل توجهی بین انتشار نسخهٔ جدید OpenAPI و پشتیبانی آن در یک ابزار خاص وجود داشته باشد. مثلاً بسیاری از ابزارهای اکوسیستم هنوز نسخهٔ ۳.۱ را اتخاذ نکرده‌اند و برخی فروشندگان بزرگ مثل Google Cloud Endpoints هنوز روی نسخهٔ ۲.۰ (Swagger) مانده‌اند. ساخت ابزار خودتان در این زمینه کنترل سرنوشت را به دست خودتان می‌دهد.
- مالکیت: ممکن است دلایلی وجود داشته باشد که بخواهید راه‌حل خودتان را بسازید چون بخش مهمی از مالکیت معنوی شما را تشکیل می‌دهد. اگر ابزار OpenAPI شما بخش مهمی از پشتهٔ نرم‌افزاری‌تان باشد و دلیل اصلی درآمدزایی شما، نیاز به کنترل حداکثری دارید. در این زمینه ساخت ابزار منطقی است.
این دلایل منحصر به OpenAPI نیستند. موارد استفاده، زبان‌های برنامه‌نویسی، محیط‌های عملیاتی و مقررات صنعتی همگی می‌توانند منجر به نیاز ساخت ابزار در هر فناوری شوند. با این حال، دلایل ساخت ابزارهای OpenAPI به‌طور کلی صدق نمی‌کنند.
استدلال‌های خرید ابزارهای OpenAPI
دلایل زیادی وجود دارد که چرا باید ابزارهای OpenAPI را بخرید یا از ابزارهای متن‌باز رایگان استفاده کنید. در مورد Oxide این گزینه به‌وضوح ممکن نبود، چون پشتیبانی از زبان Rust و تولید کد برای نیازهایشان کافی نبود. اما مورد Oxide چیزی نیست که اکثر توسعه‌دهندگان نرم‌افزار داشته باشند. ما از صفر ماشین نمی‌سازیم، سیستم‌عامل یا صفحهٔ مدیریت برای سیستم‌های سخت‌افزاری توسعه نمی‌دهیم. بسیاری از ما موارد استفادهٔ ساده‌ای داریم، مثل انتشار مستندات.
نکتهٔ کلیدی اینجاست که ابزارهای OpenAPI اغلب با «چیز دیگری» جفت می‌شوند تا یک کار یا وظیفهٔ خاص انجام دهند. مورد مستندات مثال واضحی است، اما طراحی API (وقتی کد-اول نباشد) در سطح تیم مثال دیگری است. ابزارهای تجاری مثل Postman Enterprise، SwaggerHub و Redoc Workflows قابلیت‌های همکاری و خودکارسازی ارائه می‌دهند که بر پایهٔ سازگاری با OpenAPI ساخته شده‌اند تا تجربهٔ طراحی یکپارچه‌ای به کاربران بدهند.
استدلال خرید در اینجا بسیار قوی است. سازمان شما به احتمال خیلی زیاد زمان و پول صرف ساخت یک ابزار طراحی با قابلیت همکاری نمی‌کند وقتی می‌تواند یکی را مستقیماً از قفسه بردارد. اصلی‌ترین هشدار البته همان چیزی است که لِوِنتال اشاره کرد: OpenAPI بسیار گسترده است و ممکن است ویژگی حیاتی برای نیاز شما وجود نداشته باشد. بنابراین انتخاب محصول سازگار با OpenAPI مانند هر تصمیم خرید دیگری است؛ باید پیش از خرید با درک دقیق نیازهایتان تحقیق کافی کنید.
نگاهی از زاویهٔ موارد استفاده به OpenAPI
بحث ساختن در برابر خریدن برای ابزارهای OpenAPI برای بسیاری از متخصصان API که به دنبال چیزی برای شتاب دادن به تلاش‌هایشان در ارائه یا مصرف API هستند، پاسخ سرراستی ندارد. همان‌طور که تجربهٔ لِوِنتال نشان می‌دهد، شروع از صفر و اطمینان از اینکه همهٔ کارهای لازم انجام شده دشوار است، همان‌طور که تلاش برای «کامل بودن ویژگی‌ها» دشوار است. همچنین این پرسش وجود دارد که آیا ابزارها واقعاً باید همه چیز را پیاده‌سازی کنند، چون در بسیاری موارد قابلیت‌هایی که ابزار را «کامل» جلوه می‌دهد توسط جامعهٔ توسعه‌دهندگان استفاده نمی‌شود.
بازسازی پیشنهادی که در نسخهٔ ۴ OpenAPI در راه است کمک خواهد کرد بخش‌هایی از مشخصه ماژولارتر شوند و در نتیجه برای برخی ابزارها که بی‌ربط هستند راحت‌تر نادیده گرفته شوند. با این حال، هنوز نیاز به پاسخ‌های ساده‌تری به این پرسش وجود دارد که برای یک مورد استفادهٔ خاص چه چیزی باید پیاده‌سازی شود. یک راه‌حل ممکن که OpenAPI Initiative می‌تواند کمک کند، ایجاد «پروفایل‌های» ابزار است که ویژگی‌های مهم برای یک مورد استفادهٔ کاملاً تعریف‌شده را توصیف می‌کند.
برای مثال، Tag Object را در نظر بگیرید. راهنمایی در مشخصه دربارهٔ «متادیتای اضافی» از طریق Tag صحبت می‌کند، اما اکثر پیاده‌سازان از تگ‌ها برای ناوبری در ابزارهای مستندات استفاده می‌کنند. بهبود مشخصه به شفاف‌سازی استفاده کمک می‌کند (همان‌طور که در بحث فعلی Moonwalk دربارهٔ این موضوع منعکس است)، اما ارائهٔ نگاهی از زاویهٔ مورد استفاده که استفاده از تگ‌ها برای مستندات را توصیف کند نیز ارزش بسیار زیادی خواهد داشت.
این نگاه از زاویهٔ مورد استفاده احتمالاً برای جامعهٔ گسترده‌تر OpenAPI بسیار مفید خواهد بود. همان‌طور که OpenAPI Initiative از یک جامعهٔ تک-مشخصه به جامعهٔ چند-مشخصه (با انتشار Overlay و Arazzo) حرکت می‌کند، یافتن راهی برای ارائهٔ بینش‌هایی از این دست در توسعهٔ آینده‌اش بسیار ارزشمند خواهد بود.
ساختن یا خریدن ابزارهای OpenAPI
برگردیم به پرسش اصلی: آیا باید ابزارهای OpenAPI را بسازیم یا بخریم؟ پاسخ این است: بستگی دارد. ما دلایل روشنی توصیف کردیم که چرا ساخت ابزارهای خودتان ایدهٔ خوبی است، اما باید برای پیچیدگی ذاتی یک استاندارد که سعی می‌کند انواع مختلفی از استانداردهای اینترنتی را نشان دهد آماده باشید.
پیچیدگی «پنهان» OpenAPI به‌ویژه وقتی مهم می‌شود که قصد ساخت یک محصول تجاری دارید که کاربران ممکن است ویژگی‌هایی را که در مشخصهٔ OpenAPI به‌عنوان موارد حاشیه‌ای تلقی می‌شوند مطالبه کنند. بسیاری از ما اما با آنچه از جامعهٔ ابزارها می‌توانیم بگیریم راضی خواهیم بود. تعداد عظیم ابزارها که بسیاری از آن‌ها بسیار بالغ هستند و ویژگی‌های OpenAPI را به‌خوبی پوشش می‌دهند، آنچه برای موفقیت در ساخت و مصرف APIها نیاز داریم را فراهم خواهند کرد.
