اگه API نبودش...

سطح این مقاله: متوسط و مناسب تمام افرادِ علاقه‌مند

- وی در اعماقِ تَهِ دریای افکارَش غوطه‌وران میپِلِکید که ناگهان ندایی برآمد:
- و تو چه میدانی API چیست؟
- خواست خردمندانه سخنی گوید، دهان که گشود، آبِ دریا رفت تو حلقش داشت خفه میشد، دوباره ندا اومد:
- نمیخواد چیزی بگی بابا میفتی رو دستمون!

داستان از اون جایی شروع شد که توی شرکت ما، و مشخصا توی تیم فنی، بین تیمای مختلف مثل زیرساخت و برنامه‌نویسا، به مرور فهمیدیم که شاید یسری کلمات و تعاریف و ابزارها و ... باشه که طرف مقابل زیاد درک دقیقی ازش نداره. میپرسین مثلاً چی؟ یکیش همین API. ما وقتی توی صحبتامون در مورد api صحبت میکردیم پیش میومد که مثلاً یکی از بچه‌های زیرساخت میپرسید آقا این api که هی میگین چیه جزئیاتش؟ میشه واسه مام توضیح بدین...
از طرفی هم مدتی بود روندی توی شرکت پیش گرفتیم که هر کسی بیاد در مورد یه مطلبی در حد آشنایی بقیه یه جلسه آموزشی کوتاه اجرا کنه، مثلاً توی یکی از همین جلسات بود که من فهمیدم ابزاری به اسم sed توی لینوکس وجود داره و چه کاربردایی میتونه داشته باشه، یا حتی اگه میتونین جلوی خنده خودتون رو بگیرین، توی یکی از همین جلسات من متوجه شدم که دیگه وقتشه به جای استفاده از nano برم سراغ vim

خلاصه سرتون رو درد نیارم، قرار شد من خلاصه و جامع بیام در مورد API صحبت کنم، و نه قرار بود خیلی فنی باشه نه خیلی عمومی. واسه همین گفتم بیام یه مقاله بنویسم که هم بتونم توی ارائه ازش استفاده کنم هم باقی بمونه شاید به درد کسی خورد. خیلیا میگن بهترین راهِ اطمینان از یادگیریِ چیزی، یاد دادنش به دیگرانه، از طرفی تجربه ثابت کرده حتی اگه بتونی چیزی رو توضیح بدی، با نوشتن فرق داره و موقع نوشتن بهتر میتونی دوره و منظم‌تر کنی موارد رو، حتی اگه ساده‌ترین مطلب باشه.

خب از تعریفش شروع کنیم (خدا اموات ویکیپدیا رو بیامرزه):

An application programming interface (API), is a computing interface that defines interactions between multiple software intermediaries.

و به زبون فارسی (ولی از نوعِ سَختِش!):

میانای برنامه‌سازی کاربردی یا واسط برنامه‌نویسی نرم‌افزار کاربردی یا ای‌پی‌آی (به انگلیسی: API، مخفف Application Programming Interface) که به صورت خلاصه به آن واسط برنامه‌نویسی هم گفته می‌شود، واسط بین یک کتابخانه یا سیستم‌عامل و برنامه‌هایی است که از آن تقاضای سرویس می‌کنند.

راستش رو بخواین تا حالا خودم هم اینجوری تعریف api رو نخونده بودم! میانای برنامه‌ساز کاربردی! بگذریم...

خب، به زبون خودمونی، API یجوری لایه‌ی واسطه هست و کمک میکنه قسمت‌های مختلف چه نرم‌افزاری چه سخت‌افزاری بتونن با همدیگه ارتباط برقرار کنن. برای مثال حتی کوچیک‌ترین اجزای سیستمای سخت‌افزاری و نرم‌افزاری هم اگه بخوان با هم هر نوع ارتباطی داشته باشن باید زبون همدیگه رو بفهمن و این مسئولیت هم به عهده لایه‌ای به اسم api هست اغلب.

یه مثالی که خیلی رایج هست برای توضیح، وسایل برقیه. شما به عنوان تولید‌کننده وسایل برقی، نیاز داری که به کمک پریزهای برقی، برق لازمه رو تأمین کنی، پس میای سیم میذاری پشت دستگاه و دیگه کاری نداری که برق چجوری رسیده بهش، میخواد انرژی پشتش خورشیدی باشه یا ذغالی! مهم اینه که یه برقی به دستگاه برسه.
یه مثال دیگه اداره پست هست. شما بسته‌ای که میخوای به یکی برسونی رو تحولی اداره پست میدی و دیگه کاری نداری که چجوری میخواد بسته رو برسونه به مقصد. ولی صبر کن ببینم؟ مگه ما موقع تحویل بسته پستی نمیتونیم مشخص کنیم چجوری بسته ارسال بشه؟ از طرفی اداره پست هم لازمه ساز و کاری داشته باشه که تعیین کنه چه مدل بسته‌هایی و با چه بسته‌بندی‌ای و تحت چه شرایطی میتونن ارسال بشن. میشه بصورت کاملاً انتزاعی در نظر گرفت که توی apiها هم موضوعات این چنینی میتونه وجود داشته باشه.

برای اینکه بیشتر با این مفهوم آشنا بشیم، مستقیم شیرجه بزنیم توی انواع کُلیش:

تقسیم بندی API

اگه بخوایم بصورت کلی‌تر، مفهوم api رو تقسیم‌بندی کنیم، میشه به موارد زیر اشاره کرد (طبیعتاً شاید بشه به گونه‌های دیگه تقسیم بندی کرد):

تقسیم بندی API - سخت افزاری

چی؟ سخت‌افزاری؟ مگه نگفتیم API یعنی اپلیکیشن‌پروگرمینگ‌اینترفیس؟
شاید عجیب باشه، ولی اولاً ما وقتی میگیم پروگرمینگ، میتونیم منظورِ سخت‌افزاری هم داشته باشیم، در ثانی، اگه بخوایم با مفهوم کُلیِ API آشنا بشیم، حتی از نظر سخت‌افزاری هم API لازمه. برای درک بهترش عکس زیر رو ببینیم:

عکس بالا، داکیومنتیشنِ API مرتبط با سخت‌افزار Tessel 1 هست.

یه مثال دیگه توی این زمینه، زمانی هست که شما داری یه پردازش خیلی سنگین انجام میدی. منظورم خیلی خیلی سنگینه، در حد حداکثر توان سیستمت. دفعه بعدی که همینجوری نشستی جلوی مانیتور و داری پاهات رو تکون میدی و صدای دندون‌قروچه‌ات سوهانِ مغزت شده و لحظه شماری میکنی که صدای فن لپتاپ یا کامپیوترت قطع بشه و هر لحظه نگران منفجر شدنش نباشی، به این فکر کن که چجوری فَنِ سیستمت فهمیده که باید مثل ملوان زبل یه کنسرو اسفناج بزنه و یه یاعلی بگه و شروع کنه به چرخیدن وسط گودِ زورخونه!
عملاً وقتی cpu سیستم پردازش سنگینی داره و داغ میکنه، فَنِ سیستم با یه سازوکاری که قسمتیش API سخت افزاری هست مطلع میشه که وقتشه خودی نشون بده.

تقسیم بندی API - سیستم عامل

یکی از مثال‌هایی که میشه توی این زمینه زد، عکسِ زیره که بصورت کلی ساختار و روابط کرنل لینوکس رو نشون میده:

و مثال دیگه‌ای که میشه زد، وقتیه که توی پنجره‌های مختلف داخل سیستم‌عامل ویندوز، دکمه ی x یا مینیمایز رو میزنیم، و حتی اَکشن‌های دیگه‌ای که توی پیاده‌سازی ui ممکنه نیاز داشته باشه با سیستم‌عامل ارتباط برقرار کنه، نهایتاً میتونه به API‌های سیستم‌عامل ویندوز برسه.

تقسیم بندی API - زبانهای برنامه‌نویسی

بَه‌بَه، دنیای شیرین برنامه‌نویسی. آخ که چه میکنه این برنامه‌نویسی با دلِ آدم. هر برنامه‌نویسی که با هر کدوم از زبونای برنامه‌نویسی کار میکنه، احتمال زیاد، خواسته یا ناخواسته، با API اون زبون سر و کله زده.
برای مثال جاوا، یه هسته اصلی داره که شامل سینتکس، نحوه ساخت متغیر، انواع داده و غیره میشه، اما کنار اونا یعالمه کلاس مختلف توسط توسعه‌دهنده‌های این زبون پیاده‌سازی شده که قسمتیش به اسم JAVA API هم شناخته میشن و یسری ویژگی‌های تکمیلی کنار این زبون در اختیار برنامه‌نویس‌هایی که میخوان از این زبون استفاده کنن قرار میدن.

تقسیم بندی API - کیت توسعه نرم افزار SDK

دقیقاً این شکلی نیستا ولی میتونیم اینجوری تصور کنیم که میشه گفت کیتِ توسعه نرم‌افزار یا همون Software Development Kit یا به اختصار sdk یکی از انواع APIها میتونه باشه. میشه اینجوری هم گفت که یه SDK میتونه شامل API‌های مختلفی باشه. و البته در عین حال خودش هم ممکنه API قلمداد بشه!

برای درک بهتر به این مثال توجه کنیم که توسعه‌دهنده‌های نرم‌افزارهای موبایل وقتی میخوان مثلاً برای سیستم‌عامل اندروید برنامه‌ای تولید کنن (در حالتِ اصطلاحاً native) از چیزی به اسم Android SDK استفاده میکنن که گوگل اون رو در اختیارشون قرار میده (و بصورت مشابه برای ios از iOS SDK).
اسمش روشه دیگه، کیتِ توسعه نرم‌افزار، یعنی میشه گفت SDK یه کیت یا مجموعه‌ای از موارد و توابع و کتابخونه‌هاییه که برای بهبودِ روندِ برنامه‌نویسی در اختیار برنامه‌نویس‌ها قرار میگیره.

تقسیم بندی API - وب سرویس

یکی از معروف‌ترین مدلهای API که احتمالاً با شنیدن کلمه‌ی API به ذهن اغلب کسایی که توی کار فناوری‌اطلاعات هستن میرسه، وب‌سرویس هست. برای درک بهتر بریم سراغ مفهوم WEB API که نوعی پروتکل هست که از طریق شبکه‌ی اینترنت و وب یا هر نوع شبکه‌ای، میتونه تعامل با و یا بین اپلیکیشن‌های مختلف رو برقرار و امکان‌پذیر میکنه. Web Service‌ها هم سرویس‌هایی هستن که میتونن API ارائه بدن و توی روندهای به‌روز‌تر برای توسعه، میتونیم تسک‌ها رو به زیر تسک‌های کوچیک‌تر تقسیم‌بندی کنیم و وب‌اپلیکیشن‌هایی داشته باشم که تحت عنوان سرویس و مایکروسرویس کارامون رو انجام بدن، و یکی از روش‌های مرسوم برای ارتباط بین این سرویس‌ها یا مایکرو‌سرویس‌ها، در نظر گرفتن نوعی API به عنوان لایه واسطه هست که مزایای زیادی در اختیارمون میذاره.
برای مثال:
- امکان استفاده درپروژه‌های مختلف
- عدم وابستگی به زبون یا پلتفرمی خاص
- به‌کار‌بردنِ تکنولوژی‌های مختلف کنار همدیگه
- سهولت توی اضافه حذف یا ویرایش موارد و تسک‌ها
- بالا بردنِ سرعت پاسخگویی، بهبودِ مقیاس‌پذیری
- افزایش تعداد درخواست‌های قابل بررسی
- پیاده‌سازیِ روش‌های مختلف امنیتی
- و موارد مشابه یا غیرمشابهِ دیگه

بعضیا قبول ندارن که وب‌سرویس‌ها نوعی از API هستن، ولی مشابه حالت قبل، از نظر تعریف، چون که API رو واسط برنامه‌نویسی اپلیکیشن ترجمه کردیم، و وب‌سرویس دقیقاً یه واسطه هست که میتونه به عنوان واسطه، خدماتی در اختیار قرار بده، میشه وب‌سرویس‌ها رو بهترین نوع APIها دونست.

*** بعد از بررسی انواع API توی قسمت بعد، میریم سراغ آشناییِ بیشتر با وب سرویس‌ها ***

انواع API

حالا که با تقسیم‌بندی APIها آشنا شدیم، میتونیم بریم سراغ انواع API.
چی؟ سوال داری؟ فرقِ "انواع" با "تقسیم‌بندی" چیه؟

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

انواع API - مدل Open

که اصطلاحاً Public APIs هم شناخته میشن. خیلی وقتا ما وقتی سایتی رو ما باز میکنیم داره از APIهای عمومی اطلاعات رو در اختیارمون قرار میده. مثلا وقتی اکسچنج‌های ایرانی چه توی بورس چه توی حوزه کریپتوکارنسی به شما قیمت لحظه‌ای نشون میدن، خودشون دارن این اطلاعات رو از APIهای اصلی میگیرن که بعضیاشون عمومی و قابل استفاده تمام همه هست و اون‌هارو به هر کسی که درخواست بده میفرستن. اگه به این مورد علاقه دارین میتونین با مراجعه به این لینک گیت‌هاب با لیست خوبی از API های عمومیِ رایگان و بعضاً کار-راه-انداز آشنا بشین.

انواع API - مدل Partner

بعضی وقتا نمیخوایم APIمون رو در اختیار همه بذاریم. حالا یا بَخیلیم، یا قرارداد nda امضا کردیم، یا میخوایم در ازای APIمون پول بگیریم یا هر مورد دیگه‌ای، اینجور وقتا معمولاً میتونیم سطح دسترسی تعریف کنیم. بصورت کلی وقتی قرار باشه بعضیا بیرون از ما از API استفاده کنن، APIمون توی این مدل دسته‌بندی قرار میگیره.

انواع API - مدل Internal

این مدل که Private API هم شناخته میشه، بیشتر برای مصارف داخلی سیستم، یا مثلاً زمانی که شعبه‌های مختلف یه شرکت از جاهای مختلف میخوان باهم ارتباط برقرار کنن، استفاده میشه. اسمش روشه، ارتباط اینترنال یا داخلی یا خصوصی.
برای مثال، ما توی شرکتمون یه اوپن‌استک داشتیم که میخواستیم کاربر بتونه با اون ارتباط برقرار کنه، خب اوپن‌استک خودش API داشت ولی ما اومدیم یه لایه API هم بینشون گذاشتیم که هم از نظر امنیت تقویت کنیم، هم کلاینت یا درخواست‌دهنده صرفاً به مواردی که لازم هست و ما تعیین میکنیم چی هستن دسترسی داشته باشه، و البته گاهی کلاینت صرفاً با کال کردن یه متد از API میتونست به چندین عملکرد دسترسی داشته باشه. این لایه یا APIای که من پیاده‌سازی کردم، مثالی از مدل Internal یا همون Private هست، و البته کمی با چاشنی کامپوزیت.

انواع API - مدل Composite

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

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

خب! به پایان آمد این مقاله، حکایت همچنان باقیست تا زمانی که لینک مقاله‌ی وب‌سرویس‌ها رو هم اضافه کنم.

موفق و پیروز و سلامت باشین

فعلاً خدا نگهدارتون

بروزرسانی: مقاله زیر برای آشنایی بیشتر با وب‌سرویس‌ها منتشر شد :

منتشر شده در ویرگول توسط محمد قدسیان https://virgool.io/@mohammad.ghodsian

https://virgool.io/@mohammad.ghodsian/api-c4k190m5mw0h