اگه API نبودش، پا نمیداد این مقاله

اگه 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 documentation for Tessel 1عکس بالا، داکیومنتیشنِ API مرتبط با سخت افزار Tessel 1 هست.یه مثال دیگه توی این زمینه، زمانی هست که شما داری یه پردازش سنگین انجام میدی، وقتی همینجوری نشستی جلوی مانیتور و داری پاهات رو تکون میدی و لحظه شماری میکنی که صدای فن لپتاپ یا کامپیوترت قطع بشه و هر لحظه نگران منفجر شدنش نباشی، به این فکر کن که چجوری فَنِ سیستمت فهمیده که باید مثل ملوان زبل یه کنسرو اسفناج بزنه و یه یاعلی بگه و شروع کنه به چرخیدن وسط گودِ زورخونه! عملاً وقتی cpu سیستم پردازش سنگینی داره و داغ میکنه، فَنِ سیستم با یه ساز و کاری که قسمتیش API سخت افزاری هست مطلع میشه که وقتشه خودشو نشون بده.یکی از مثالهایی که میشه توی این زمینه زد، عکسِ زیره که بصورت کلی ساختار و روابط کرنل لینوکس رو نشون میده:Linux kernel apiو مثال دیگه ای که میشه زد، وقتیه که توی پنجره های مختلف داخل سیستم عامل ویندوز، دکمه ی x یا مینیمایز رو میزنیم، و حتی اکشن های دیگه ای که توی پیاده سازی ui ممکنه نیاز داشته باشه با سیستم عامل ارتباط برقرار کنه، نهایتاً میتونه به API های سیستم عامل ویندوز برسهبه به، دنیای شیرین برنامه نویسی. آخ که چه میکنه این برنامه نویسی با دلِ آدم. هر برنامه نویسی که با هر کدوم از زبونا برنامه نویسی کار میکنه، احتمال زیاد، خواسته یا ناخواسته، با API اون زبون سر و کله زده.برای مثال جاوا، یه هسته اصلی داره که شامل سینتکس، نحوه ساخت متغیر، انواع داده و غیره میشه، اما کنار اونا یعالمه کلاس مختلف توسط توسعه دهنده های این زبون پیاده سازی شده که به اسم JAVA API هم شناخته میشن که یسری ویژگی های تکمیلی کنار این زبون در اختیار برنامه نویس هایی که میخوان از این زبون استفاده کنن قرار میده. دقیقاً این شکلی نیستا ولی میتونیم اینجوری تصور کنیم که میشه گفت کیتِ توسعه نرم افزار یا همون Software Development Kit یا به اختصار sdk یکی از انواع APIهاست. میشه اینجوری هم گفت که یه SDK میتونه شامل API های مختلفی باشه . و البته در عین حال خودش هم میتونه یه API قلمداد بشه!برای مثال توسعه دهنده های موبایل که میخوان مثلاً برای سیستم عامل اندروید برنامه ای تولید کنن، از چیزی به اسم Android SDK استفاده میکنن که گوگل اون رو در اختیارشون قرار میده. اسمش روشه دیگه، کیتِ توسعه نرم افزار، یعنی میشه گفت بصورت کلی SDK یه کیت یا مجموعه ای از توابع و کتابخانه هایی هست که تولید کنندگان نرم افزار برای بهبود روند برنامه نویسی در اختیار برنامه نویس ها قرار میدن.یکی از معروف ترین مدلهای API که احتمالاً با شنیدن کلمه ی API به ذهن اغلب کسایی میرسه که توی کار فناوری اطلاعات هستن، وب سرویس هست. یه WEB API نوعی پروتکل هست که از طریق شبکه ی اینترنت و وب، تعامل بین اپلیکیشن های مختلف رو برقرار و امکان پذیر میکنه. Web Service هم صدا زده میشه و توی روندهای به روز تر برای توسعه، میتونیم تسک ها رو به زیر تسک های کوچیک تر تقسیم بندی کنیم و وب اپلیکیشن هایی داشته باشم که تحت عنوان سرویس و مایکروسرویس کارامون رو انجام بدن. بعضیا قبول ندارن که وب سرویسه ها نوعی از API هستن، ولی مشابه حالت قبل، از نظر تعریف چون که api رو واسط برنامه نویسی اپلیکیشن ترجمه کردیم، و وب سرویس دقیقاً یه واسطه هست که سرویس هم میتونه در اختیار همه قرار بده، میشه وب سرویس ها رو بهترین نوع APIها دونست.** بعد از بررسی انواع API میریم سراغ آشناییِ بیشتر با وب سرویس ها **حالا که با تقسیم بندی APIها آشنا شدیم، میتونیم بریم سراغ انواع API.چی؟ سوال داری؟ فرقِ “انواع” با “تقسیم بندی” چیه؟ انواع APIاینا کلمه هستن دیگه. توی قسمت قبلی انواع APIها رو با توجه به مدل کاریشون تقسیم بندی کردیم، اینجا قراره از نظر سطح دسترسی و پرمیشن و نوع عملکردی که ارائه میدن بررسی کنیم. همونطور که گفتم، API به نوعی واسطی هست برای برقراری ارتباط، این نوع ارتباط میتونه شامل موارد زیر باشه:که اصطلاحاً Public APIs هم شناخته میشن. هر سایتی که ما باز میکنیم داره از APIهای عمومی اطلاعات رو در اختیارمون قرار میده. وقتی اکسچنج های ایرانی چه توی بورس چه توی حوزه کریپتوکارنسی به شما قیمت لحظه ای نشون میدن، دارن این اطلاعات رو از APIهای اصلی میگیرن و در اختیار همه قرار میدن. اگه به این مورد علاقه دارین میتونین با مراجعه به این لینک گیت ها با انواع APIهای عمومی آشنای بشین. بعضی وقتا نمیخوایم APIمون رو در اختیار همه بذاریم. حالا یا بخیلیم، یا قرارداد nda امضا کردیم، یا میخوایم در ازای APIمون پول بگیریم یا هر مورد دیگه ای، اینجور وقتا معمولاً میتونیم سطح دسترسی تعریف کنیم. بصورت کلی وقتی قرار باشه بعضیا بیرون از ما از API استفاده کنن، API توی این مدل دسته بندی قرار میگیره.این مدل که Private API هم شناخته میشه، بیشتر برای مصارف داخلی به سیستم، یا مثلاً زمانی که شعبه های مختلف یه شرکت از جاهای مختلف میخوان باهم ارتباط برقرار کنن، استفاده میشه. اسمش روشه، ارتباط اینترنال یا داخلی.برای مثال ما توی شرکتمون یه اوپن استک داشتیم که میخواستیم کاربر بتونه با اون ارتباط برقرار کنه، خب اون خودش API داشت ولی ما اومدیم یه لایه API هم بینشون گذاشتیم که هم از نظر امنیت تقویت کنیم، هم صرفاً مواردی که لازم هست رو کلاینت دسترسی داشته باشه، و البته گاهی چندین عملکرد رو کلاینت صرفاً با کال کردن یه متد از API میتونست بهش دسترسی داشته باشه. این لایه ای که من پیاده سازی کردم از مدل Internal یا همون Private هست.ترکیبی پر رو، کم رو، یا نیم رو یا هر مدل ترکیب دیگه ای از انواع داده ها و انواع API قبلی که توضیح دادم، میشه Composite. میشه گفت دنباله ای از وظایف که همزمان و جهت رسیدن به نتیجه ی دلخواه اجرا میشن نه الزاماً برای یک درخواست خاص. کاربرد اصلی این مدل هم سرعت بخشیدن به روند اجرا و بهبود عملکرد سیستمه.خب. الوعده وفا. گفته بودم که میخوایم یذره بیشتر با انواع وب سرویس ها آشنا بشیم. میخواستم ادامه ی همین مقاله در مورد انواع وب سرویس ها هم بنویسم، ولی ترجیح دادم اون رو تحت عنوان مقاله ی دیگه ای بنویسم و لینکش رو همینجا میذارم، چون از یه طرف این مقاله یکم زیادی شاید طولانی بشه، و از طرف دیگه قرار بود سطح این مقاله متوسط باشه و اینجا به بعد یکمی همچین بگی نگی تخصصی تر میشه موضوع.خب! به پایان آمد این مقاله، حکایت همچنان باقیست تا زمانی که لینک مقاله ی وب سرویس ها رو هم اضافه کنم.موفق و پیروز و سلامت باشینفعلاً خدا نگهدارتونمنتشر شده در ویرگول توسط محمد قدسیان https://virgool.io/@mohammad.ghodsianhttps://virgool.io/@mohammad.ghodsian/api-c4k190m5mw0h

منبع

Author: admin

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *