سلام. اگر کلمه‌ی API تا حالا به گوشتون خورده و دوست دارید معنی‌ش رو بدونید، احتمالاً این پست به دردتون می‌خوره. در این سلسله پست‌ها می‌خوام از پایه یه سری مفاهیم رو توضیح بدم تا برسیم به API و بعد طراحی API-first.
وقتی یک وسیله‌ای نیاز به برق شهری داره، احتمالاً یک دوشاخه براش تعبیه شده و وقتی شما یک دوشاخه می‌بینید، یاد پریز می‌افتید:
پریز یعنی چی؟
اگه بخوام بگم که از نظر من مهم‌ترین توصیف از پریز چیه، می‌گم که یه interface ـه. حالا interface یعنی چی؟
ببینید به دست آوردن برق کاریه که به ۱۰۲۳۹۸۱ روش می‌شه انجامش داد؛ یکی از طریق سوزوندن بنزین تو ماشین برق تولید می‌کنه، یکی از طریق انرژی خورشیدی این‌کارو می‌کنه، یکی هم ممکنه هسته‌ی اورانیوم رو بشکافه و با بخارکردنِ آب توسط اون حرارت به دست اومده توربین بچرخونه و ... نهایتاً برق به دست بیاره!
خب. حالا سؤال اینه که آیا شما وقتی می‌خواید خونتون رو جارو برقی بکشید، باید اصلاً به این‌که برقش از کجا و چطوری تولید شده فکر کنید؟ نه! شما فقط یه کاربرِ عادی هستید و هزارتا مشغله و بدبختی دارید و فقط می‌خواید برق رو بگیرید و استفاده‌اش کنید.
حالا طراحِ دو شاخه اومده چیکار کرده؟ گفته که خب یه سری چیزها که متغیرن؛ مثلِ نحوه‌ی به دست آوردنِ برق، نوعِ دستگاه‌هایی که ساخته می‌شن، و مردمی که از دستگاه‌ها استفاده می‌کنن.
ولی ما می‌تونیم یه بخشی رو ثابت طراحی کنیم و اسمش رو بذاریم «پریز». این‌طوری فارغ از این‌که اون پشت داره چطور برق به دست می‌آد، یا دستگاهی که ازش قراره استفاده کنه چیه، یه زبان مشترکی داریم که می‌تونیم با هم سرش توافق کنیم:
الآن تو مثال بالا می‌تونیم آدمی رو که داره هندل می‌زنه برداریم و یک قطار بذاریم که از طریق سوزوندن سوخت، برق تولید می‌کنه. ولی مادامی که برق رو از طریق یک پریز ارائه بدن، هر کس که بخواد جاروبرقی بکشه می‌تونه با دوشاخه ازش استفاده کنه.
انگار که این پریز، این‌جا اومده و کار آدم‌ها رو با یک لایه‌ی میانیِ مشترک ساده کرده و از یک طرف به «نحوه‌ی به دست آوردن برق (جزئیات پیاده‌سازی)» به عنوان یک عملِ انتزاعی نگاه کرده، و از طرف دیگه هم «نحوه‌ی استفاده از برق (کاربری)» رو به شکل یک انتزاع دیده. در نتیجه هر دوی این طرفین می‌تونن به شکل‌های دلخواه تغییر کنن و یک انعطافِ خیلی زیادی به این شکل ایجاد شده.
دو شرطِ بالا کافیه تا خدمت‌دهنده و خدمت‌گیرنده بتونن به راحتی با هم تعامل کنن و خدمتِ «ارائه‌ی برق» انجام بشه.
این کلمه مخفف Application Programming Interface ـه. اگه مفهومِ اینترفیس به خوبی تو مغزتون جا رفته باشه، متوجه‌شدنِ API اصلاً سخت نیست.
توی مثالِ پریز، یک خدمت‌رسان داشتیم (که برق ارائه می‌داد) و یک خدمت‌گیرنده (که می‌خواست وسیله‌ی برقی استفاده کنه). نرم‌افزارها هم خیلی وقت‌ها خدماتی رو ارائه می‌دن؛ از ساده تا پیچیده. برای مثال ممکنه یک نرم‌افزار هر یک از این خدمات رو بخواد ارائه بده:
بیاید روی مثالِ آخر صحبت کنیم: یک نرم‌افزار داریم که متنِ یادداشتی رو می‌گیره و «یک جای امن» ذخیره‌ش می‌کنه. فرض کنیم یه سری آدم هم داریم که یادداشت‌هایی دارن ولی هیچ جای امنی ندارن که اونو ذخیره کنن.
حالا این آدم‌ها چطور یادداشت‌هاشونو بدن دستِ اون نرم‌افزار؟ یه راهش اینه که خودشون اجتهاد کنن و در قالبِ دلخواهشون اون رو بنویسن و به جای دلخواهشون بفرستنش:
الآن نرم‌افزارِ خفن باید با بدبختی یادداشت‌ها رو جمع کنه، متن اصلی‌شون رو جدا کنه و نهایتاً اون‌ها رو در جای امن قرار بده. علتِ این‌که این‌همه زحمتِ اضافه باید بکشه، اینه که از قبل مشخص نکرده که تحتِ چه «اینترفیس»ـی می‌شه باهاش ارتباط گرفت. اگر بیاد و اینترفیسش رو مشخص کنه، افرادی که می‌خوان ازش سرویس بگیرن می‌تونن دقیق‌تر باهاش ارتباط بگیرن:
الآن هر کس بخواد از خدماتِ نرم‌افزارِ خفن استفاده کنه، کافیه یادداشتش رو به اون آدرس ارسال کنه و نرم‌افزارِ خفن براش یادداشتش رو در یک جای امن ذخیره می‌کنه.
این جداسازیِ جزئیاتِ پیاده‌سازی (این‌که نرم‌افزارِ خفن چه «جای امن»ـی و چجوری داره ذخیره‌سازی می‌کنه) از کاربری (متن هر کاربر یه چیز متفاوتیه و هر کاربر به دلیل متفاوتی می‌خواد متن ذخیره کنه) و گذاشتنِ یک لایه‌ی ثابت در این وسط، در واقع تعریفِ API ـه. نرم‌افزارِ ما کلی چیز داخلِ خودش داره (مثلاً رمزنگاری، کپی‌کردن یادداشت‌ها روی ۳ قاره‌ی مختلف، و غیره) ولی یک «اینترفیس» تعریف کرده که می‌گه فقط متنِ یادداشتتون رو به من بدید و بقیه‌ی اجزای پیاده‌سازی‌ش رو کاری نداشته باشید. کاربرها هم با استفاده از اون «اینترفیس» با نرم‌افزار تعامل می‌کنن و یادداشتشون رو می‌فرستن.
حالا پس‌فردا یک شرکتی به نام «سوپراپ‌سازان تقویم‌ساز آسیا» که کارشون ارائه‌ی تقویمِ اذان‌گوئه، شاید بخواد به اپلیکیشنش بخش «یادداشت‌ها» اضافه کنه. اما خودش جای امنی نداشته باشه که یادداشت‌ها رو توش ذخیره کنه و بخواد از خدمتی که نرم‌افزار خفن ارائه می‌کنه استفاده کنه. مادامی که بتونه با اینترفیسِ مذکور با نرم‌افزار خفن تعامل کنه، می‌تونه مثلِ یک خدمت‌گیرنده‌ی دیگه یادداشت‌هاشو روی فضای امن ذخیره‌سازی کنه و در روزِ نیاز بهشون دسترسی داشته باشه.
همچنین شاید نرم‌افزار خفن، از هفته‌ی دیگه بخواد به جای این‌که روی ۳ تا قاره ذخیره‌سازی رو انجام بده، یک کپی هم روی کره‌ی مریخ نگهداری کنه که در صورتِ از بین‌رفتنِ کره‌ی زمین و انقراض نسل بشر، هنوز یادداشت‌های افراد قابلِ دسترسی باشن. در این صورت هم API هیچ تغییری نمی‌کنه؛ چون جزئیات پیاده‌سازی درش دخیل نبوده و کاربران کماکان می‌تونن مثلِ قبل با نرم‌افزار تعامل کنن.
امیدوارم مطالب پست به دردتون خورده باشه. می‌دونم که متن، رویکرد و روندِ پست خیلی ایرادات داره و واقعاً باید بهتر بشه. پس حتماً بهم بازخورد بدید تا اصلاحش کنم. متشکرم.
