معماری API-first در پلتفرم فروش
تقریباً هر پلتفرمی امروز میگوید API دارد. تفاوت در این است که API چه نسبتی با بقیه سامانه دارد: آیا لایهای است که بعداً روی یک نرمافزار موجود چسبانده شده، یا خودِ سامانه از طریق آن ساخته شده.
معیار سادهای برای تشخیص وجود دارد: هر کاری که در پنل مدیریت ممکن است، از طریق API هم ممکن است؟ اگر جواب منفی است، شما API دارید ولی API-first نیستید.
چرا این تفاوت مهم است
API الحاقی معمولاً بخشی از قابلیتها را پوشش میدهد — اغلب خواندن کالا و ثبت سفارش — و بقیه را نه. تا روزی که نیازتان در همان بخش باشد، تفاوتی حس نمیکنید.
مشکل روزی شروع میشود که بخواهید کاری بکنید که در آن بخش نیست: قیمت هزار کالا را گروهی بهروز کنید، وضعیت سفارش را از سامانه انبار تغییر دهید، یا مشتری جدید را از CRM بسازید. آنوقت جواب میشنوید که «این از طریق API نیست» و راهحل پیشنهادی معمولاً یکی از این دوتاست: کار دستی در پنل، یا نوشتن مستقیم در پایگاه داده.
دومی خطرناکتر است. نوشتن مستقیم در دیتابیس، منطق کسبوکار را دور میزند — همان منطقی که موجودی را رزرو میکند، اعتبار را میسنجد و رویداد را ثبت میکند. تا مدتی کار میکند و بعد به داده ناسازگار میرسد که کسی نمیفهمد از کجا آمده.
چه چیزی این معماری را ممکن میکند
پنل مدیریت هم یک مصرفکننده API است. این تنها تضمین واقعی است. اگر پنل مستقیم به پایگاه داده وصل باشد، همیشه قابلیتهایی خواهد داشت که API ندارد.
پوشش کامل عملیات. خواندن کافی نیست؛ ساخت، ویرایش، حذف و تغییر وضعیت هم باید باشد.
عملیات گروهی. بهروزرسانی هزار قیمت با هزار فراخوانی جدا، عملاً غیرممکن است.
رویداد. سامانه باید بتواند خبر بدهد که سفارشی ثبت شد یا موجودی تغییر کرد، بهجای اینکه طرف مقابل هر چند دقیقه بپرسد.
نسخهبندی. بدون آن، هر تغییر API یکپارچهسازیهای موجود را میشکند و در عمل تیم از تغییردادن میترسد.
چیزی که در عمل تفاوت میسازد
سه سناریوی رایج که با API-first ساده و بدون آن دردسر میشوند:
اتصال به ERP و حسابداری. جریان دوطرفه: سفارش و فاکتور به بیرون، موجودی و مانده اعتبار به داخل. اگر یکی از این جهتها API نداشته باشد، به همگامسازی فایلی میرسید با همه تأخیر و مغایرتش. الگوهایش در اتصال به ERP هست.
ورود کاتالوگ از تأمینکننده. فروشندهای که دو هزار قلم دارد، دستی وارد نمیکند.
کانال دوم. اپ موبایل یا پرتال B2B که باید همان کاتالوگ و سفارش را ببیند. این همان چیزی است که کامرس هدلس بر آن سوار میشود؛ هدلس بدون هسته API-first ممکن نیست.
رویدادها: بخشی که معمولاً غایب است
بدون رویداد، هر یکپارچهسازی به نظرسنجی دورهای تبدیل میشود: سامانه انبار هر پنج دقیقه میپرسد «سفارش جدیدی هست؟». این هم پرهزینه است و هم کند.
با رویداد — بهشکل webhook یا صف پیام — سامانه شما خبر میدهد و طرف مقابل واکنش نشان میدهد.
دو نکته که در استفاده از رویداد باید حل شوند: تحویل تکراری، چون رویداد ممکن است دوبار برسد و گیرنده باید بتواند تشخیص دهد؛ و ترتیب، چون رویدادها ممکن است نامرتب برسند و «سفارش لغو شد» نباید قبل از «سفارش ثبت شد» پردازش شود. هر دو با شناسه یکتا و شماره ترتیب حل میشوند، به شرطی که از ابتدا در طراحی باشند.
سؤالهایی که از فروشنده پلتفرم بپرسید
اگر در حال ارزیابی هستید، اینها بیشتر از هر بروشوری به شما میگویند کجا ایستادهاید:
پنل مدیریت شما از همان API استفاده میکند یا مستقیم به دیتابیس وصل است؟
کدام عملیات از طریق API در دسترس نیست؟
عملیات گروهی دارید؟ حداکثر حجم چقدر است؟
رویداد یا webhook دارید؟ برای چه اتفاقهایی؟
API نسخهبندی میشود؟ سیاست تغییرات ناسازگار چیست؟
مستندات را میشود قبل از قرارداد دید؟
آن سؤال آخر ساده است و بیشترین اطلاعات را میدهد. مستندات API، کیفیت واقعی آن را نشان میدهد بهتر از هر جلسهای.
چرا بعداً نمیشود اضافه کرد
این تصمیم برخلاف خیلی از تصمیمهای فنی، برگشتپذیر نیست — یا دستکم ارزان برگشتپذیر نیست.
اگر منطق کسبوکار در لایه رابط کاربری نوشته شده باشد، افزودن API یعنی بیرون کشیدن همان منطق و بازنویسیاش در لایهای مشترک، و بعد بازنویسی پنل روی آن. عملاً یعنی ساختن دوباره هسته.
به همین دلیل، وقتی پلتفرم انتخاب میکنید، این سؤال را در دسته «بعداً حلش میکنیم» نگذارید. یکپارچهسازیهایی که امروز لازم ندارید، دو سال دیگر لازم میشوند — و تا آن موقع، معماری تصمیمش را گرفته است.