api چیست ؟
در حوزه توسعه نرم‌افزار، به کرات واژه API به گوش می‌خورد اما اکثر برنامه‌نویسان مبتدی خیلی با ماهیت این اصطلاح آشنا نیستند که در همین راستا در این مقاله قصد داریم به طور مفصل با ماهیت و نحوه عملکرد API آشنا شویم اما پیش از هر چیز نیاز به یک مقدمه داریم. پیش از فراگیر شدن سیستم‌های کامپیوتری در صنایع مختلف، انسان به عنوان کسی که قرار بود با نرم‌افزارهای کامپیوتری بیشترین تعامل را داشته باشد در نظر گرفته می‌شد به طوری که فارغ از کاری که نرم‌افزار انجام می‌داد، از ویرایش تصاویر گرفته تا ارسال ایمیل و غیره، انسان به عنوان موجودیتی که قرار بود با نرم‌افزار مذکور کار کند مرکز توجه قرار داشت به طوری که وی از طریق User Interface یا به اختصار UI به تعامل با نرم‌افزار می‌پرداخت؛ به مرور زمان و پیشرفت فناوری، این نیاز احساس شد تا به جای تعامل انسان با نرم‌افزار، خودِ نرم‌افزارها نیز بتوانند بدون دخالت انسان با یکدیگر تعامل داشته باشند و این در حالی بود که یک سیستم کامپیوتری بر خلاف انسان چشم و گوش نداشت تا با دیدن رابط کاربری بتواند مثلا روی دکمه خاصی کلیک کند تا دیتای مد نظرش را به دست آورد، مضاف بر اینکه یک نرم‌افزار همانند انسان‌ها نیازی نداشت تا برای ارتباط با نرم‌افزاری دیگر از یک رابط کاربری (UI) زیبا و کاربرپسند برخوردار باشد و اینجا بود که مفهوم API شکل گرفت.
Application Programming Interface چیست؟
API مخفف واژگان Application Programming Interface است که به صورت تحت‌الفظی می‌توان آن را به «رابط برنامه‌نویسی نرم‌افزار» ترجمه کرد. به طور خلاصه، API شبیه همان UI است، با این تفاوت که به جای انسان، یک سیستم کامپیوتری قرار است با آن تعامل داشته باشد. در واقع، از آنجا که می‌توان واژه Interface را به «فصل مشترک» در فارسی ترجمه کرد، می‌توان گفت که API فصل مشترکی مابین دو نرم‌افزار یا اپلیکیشن است.
مثالی از دنیای واقعی به منظور درک بهتر مفهوم API
برای درک بهتر این موضوع، چیزی همچون الکتریسته را مد نظر قرار می‌دهیم بدین شکل که می‌توان الکتریسته را به عنوان یک سرویس در نظر گرفت که از طریق پریز برق در اختیار ما قرار می‌گیرد تا انرژی لپ‌تاپ، پنکه، جاروبرقی و هر آن چیزی که برای کار کردن نیاز به برق داشته باشد را تامین کند؛ اگر بخواهیم در این رابطه تشبیهی انجام دهیم، سرویسی همچون الکتریسته، همان سرویسی است که یک شرکت نرم‌افزاری مثل گوگل در اختیار ما قرار می‌دهد؛ مثلا به ما اجازه می‌دهد تا به دیتای گوگل‌مپ دسترسی داشته باشیم! حال اپلیکیشن موبایلی که طراحی کرده‌ایم هم نقشی همانند لپ‌تاپ، پنکه یا جاروبرقی را دارد که در مثال قبل برای کار کردن نیاز به الکتریسته داشت، اما در این حوزه این اپلیکیشن برای کار کردن نیاز به دیتای گوگل‌مپ دارد؛ در حقیقت، در نظر گرفتن یکسری استاندارد در پریزهای برق باعث می‌گردد مصرف‌کننده (که در اینجا انسان نیست بلکه دیوایس‌هایی همچون لپ‌تاپ، پنکه و جاروبرقی است) بدون هیچ‌گونه دغدغه‌ای برق مصرفی خود را تأمین کند.
به طور کلی، از جمله مزایای این استاندارد می‌توان به موارد زیر اشاره کرد:
– سازنده وسایل خانگی فقط روی طراحی خود دورهات تمرکز می‌کنند و هیچ کاری به مسایل مربوط به تامین برق ندارند.
– وسیله برقی به راحتی می‌تواند به پریزهای برق مختلف وصل شود.
– اگر یک وسیله برقی را از ایران به انگلستان ببریم، به سادگی با استفاده از یک تبدیل می‌توان از منبع برق ۱۱۰ ولت آن کشور استفاده کرد و کماکان نیازی به ایجاد تغییر روی وسیله برقی نیست.
– وسیله برقی اصلا نمی‌داند که نیروی برق دارد توسط نفت تولید می‌شود یا انرژی خورشیدی بلکه فقط مصرف‌کننده است.
– وسیله برقی اصلا نیازی ندارد بداند که انرژی الکتریسته به چه شکلی به دستش رسیده است.
– همچنین پریز برق هم برایش هیچ فرقی نمی‌کند که یک لپ‌تاپ متصل شده است یا پنکه بلکه فقط این وظیفه را دارا است تا به تامین الکتریسته بپردازد.
حال همان‌طور که برای روشن کردن لپ‌تاپ نیاز داریم تا دوشاخه آداپتور آن را به پریز بزنیم و نیاز به توضیح نیست که ابعاد پریز و دوشاخه از یک استاندارد خاص تبعیت می‌کنند تا بتوانند با یکدیگر جفت شوند، ما نیز برای اینکه اپلیکیشن موبایل‌مان بتواند با سرویس گوگل ارتباط برقرار سازد تا مثلا بتوانیم داخل اپ خود از گوگل‌مپ استفاده نماییم، نیاز به چنین درگاهی داریم که API نام دارد که همچون مثال پریز و دوشاخه، اپلیکیشن موبایل ما و سرویس گوگل‌مپ هم باید از یکسری استاندارد برای ارتباط برقرار کردن با یکدیگر تبعیت کنند که در غیر این صورت چنین ارتباطی هرگز شکل نخواهد گرفت.
همان‌طور که برق وسایل الکتریکی منزل‌مان توسط شبکه توزیع برق تامین می‌گردد، اپلیکیشن‌های مختلف هم برای دستیابی به دیتای مورد نیاز خود به شبکه اینترنت نیاز دارند.
منظور از Layer of Abstraction چیست؟
برای روشن شدن این اصلاح، ابتدا مثالی از API سیستم‌عامل ویندوز می‌زنیم. فرض کنیم دولوپری هستیم که قصد داریم یک نرم‌افزار دسکتاپ برای سیستم‌عامل ویندوز بنویسیم که نیاز به توضیح نیست یکی از بخش‌های نرم‌افزار را هم رابط کاربری (UI) آن است که از طریق پنجره‌های مختلف در معرض دید کاربر قرار می‌گیرد؛ فرض کنیم که کمپانی مایکروسافت اقدام به عرضه API اختصاصی ویندوز برای دولوپرهای علاقمند به توسعه نرم‌افزار برای این سیستم‌عامل نمی‌کرد که در چنین فضایی هر دولوپری مجبور می‌شد تا بسته به نیاز و سلیقه خود اقدام به طراحی پنجره‌ها کند و همین موضوع منجر به این می‌شد تا یکپارچگی ظاهری بین نرم‌افزارهای مختلف از بین رود اما این در حالی است که ویندوز از چیزی تحت عنوان Windowing API برخوردار است که یک SDK است که این وظیفه را دارا است تا کلیه مسائل مربوط به ظاهر یک پنجره همچون دکمه بستن، ری‌سایز کردن پنجره و … را هندل کند و دولوپرها صرفا نیاز دارند تا چیزهایی همچون اندازه اولیه، عنوان و محتویات داخل پنجره را مشخص کنند و الباقی تنظیمات را به API بسپارند (در ادامه با مفهوم SDK آشنا خواهید شد.)
چنین اتفاقی اصطلاحا Layer of Abstraction نامیده می‌شود، بدین صورت که Windowing API سیستم‌عامل ویندوز به منزلهٔ لایه‌ای انتزاعی است که مابین دولوپر و سیستم‌عامل قرار می‌گیرد تا دولوپر درگیر مسائل فنی، هزاران خط کدی که برای ساخت یک پنجره ساده نیاز است و … نگردد و صرفا با چند خط کد ساده نیاز خود را عملی سازد (در مثال تأمین نیروی الکتریسته هم دقیقا این لایه انتزاعی وجود دارد بدین شکل که ما به عنوان یک انسان فقط با پریز برق سروکار داریم و اینکه داخل پریز چه اتفاقی می‌افتد، سیم‌های فاز و نول چه رنگی هستند، انرژی چگونه از پُست برق تا سر کنتور می‌آید و … هیچ ربطی به ما ندارد.)
حال که با مفهوم Layer of Abstraction آشنا شدیم، دیگر نیاز به توضیح نیست که اگر وزارت نیرو اقدام به تغییر زیرساخت‌ها کند، به جای برقی که از سَد می‌آید، برق نیروگاه‌های سیکل ترکیبی را وارد شبکه انتقال برق سازد و یا تجهیزات قرار گرفته داخل پُست‌های انتقال برق را نوسازی کند و کارهایی از این دست، مادامی که انرژی مورد نیاز منازل تامین گردد، کلیه این تغییرات هیچ فرقی برای مصرف‌کننده نخواهند داشت! در حوزه توسعه نرم‌افزار، فرض کنیم سرویسی که ما به عنوان یک دولوپر از API مرتبط با آن استفاده می‌کردیم با زبان Java رو روی سرورهای AWS آمازون بود اما شرکت مذکور تصمیم می‌گیرد که آن را با Node.js بازنویسی کرده و روی سرورهای Azure مایکروسافت عرضه کند که در چنین شرایطی مادامی که اصطلاحاً Endpoint مرتبط با آن API تغییر نکند، هیچ فرقی برای دولوپرها نخواهد کرد.
به همین منوال، سرویس‌های عرضهکننده API همچون گوگل یا فیسبوک هم مادامی که دست به تغییر استانداردهای خود نزنند و اختلالی در کار دولوپرهایی که پیش از این سرویس‌های آن‌ها را مورد استفاده قرار می‌دادند ایجاد نکنند، در نتیجه می توانند به سادگی سرورهای خود را بروزرسانی کنند، یا حتی محل فیزیکی دیتاسنترهای خود را تغییر، و یا بین سرویس‌های کلود مختلف سوئیچ کنند !
به طور مثال، فرض کنیم اپلیکیشنی تحت عنوان «A» وجود دارد که توسعه‌دهنده‌اش این امکان را برای سایر توسعه‌دهندگان فراهم آورده تا از API آن استفاده کنند. حال فرض کنیم اپلیکیشنی نوشته‌ایم تحت عنوان «B» و این در حالی است که اپلیکیشن «A» در چارچوب خاصی به اپلیکیشن «B» اجازه می‌دهد تا از امکاناتی که دارا است استفاده کند (با مراجعه به سایت ProgrammableWeb می‌توانید به لیست جامعی از API سرویس‌های مختلفی که توسط شرکت‌های مطرحی همچون گوگل، فیسبوک، توییتر و … عرضه شده‌اند دست یابید.) در عین حال، در حین استفاده از API لازم است یکسری استاندارد حتماً مد نظر قرار داده شوند که برخی از مهم‌ترین آن‌ها عبارتند از:
– دیتایی که از طریق API مبادله می‌گردد ساختاریافته است: به عبارتی، درخواست از طرف نرم‌افزار «B» در چارچوب یک فرمت استاندارد صورت می‌گیرد که از قبل توسط توسعه‌دهندگان نرم‌افزار «A» تعریف شده است.
– نتیجهٔ تعامل با API قابل‌پیش‌بینی است: در واقع، درخواست‌هایی که برای نرم‌افزار «A» ارسال می‌شوند باید در یک چارچوب خاصی باشند و از همین روی پاسخ به چنین درخواست‌هایی همواره مشخص و قابل‌پیش‌بینی خواهند بود.
آشنایی با انواع API
با در نظر گرفتن این نکته که API سازوکاری است که از آن طریق تعامل سیستم با سیستم به جای تعامل کاربر با سیستم صورت می‌گیرد، می‌توان دسته‌بند‌ی‌های مختلفی برای ای‌پی‌آی‌ها در نظر گرفت که عبارتند از:
– API سخت‌افزاری: زمانی که مثلا با اجرای یک بازی حرفه‌ای فشار زیادی روی سیستم خود می‌آوریم، می‌بینیم که فن سیستم شروع به تند چرخیدن می‌کند و این به دلیل آن است که CPU نسبت به حالت عادی در معرض فشار بیشتر است و بالتبع داغ شده است و باید خنک گردد که این سازوکار از طریق ارتباط مابین API های سخت‌افزاری صورت می‌گیرد.
– API سیستم‌عاملی: پیش از این در قالب مثال توسعه یک نرم‌افزار دسکتاپ توضیح دادیم که API مرتبط با یک سیستم‌عامل همچون ویندوز به چه شکل کار می‌کند.
– API زبان‌های برنامه‌نویسی: زبانی همچون سی‌شارپ یا جاوا یک هسته اصلی دارد که شامل سینتکس این زبان، نحوه ساخت متغیر، دیتا تایپ‌ها و … می‌شود اما در کنار آن‌ها صدها کلاس مختلف توسط توسعه‌دهندگان این زبان عرضه شده که تحت عنوان C# API یا Java API شناخته می‌شوند که فیچرهای تکمیلی این زبان‌ها را در دسترس دولوپرها قرار می‌دهند.
– کیت‌های توسعه نرم‌افزار: Software Development Kit یا به اختصار SDK نیز نوعی دیگی از API است که توسط شرکت‌های مختلفی همچون گوگل، فیسبوک و … عرضه می‌شوند تا دولوپرها با استفاده از این کیت‌ها بتوانند اقدام به توسعهٔ نرم‌افزار کنند که از آن جمله می‌توان به Android SDK اشاره کرد.
– API تحت وب (وب سرویس): این نوع API یکی از متداول‌ترین و کاربردی‌ترین انواع API است که ادامه تمرکز روی همین مقوله خواهیم کرد. API تحت وب یا اصطلاحا Web API به هر پروتکلی گفته می‌شود که از طریق شبکه اینترنت و وب تعامل مابین اپلیکیشن‌های مختلف را امکان‌پذیر سازد و از همین روی Web Service نیز نامیده می‌شود، زمانی که پای API های تحت وب به میان می‌آید، باید با سازوکار پروتکل HTTP و HTTPS آشنا باشیم.
درآمدی بر انواع وب سرویس‌ها
به طوری کلی، وب سرویس‌ها را می‌توان به دسته‌های GraphQL ،SOAP ،PRC و یکی از معروف‌ترین آن‌ها در حال حاضر REST دسته‌بندی کرد که در ادامه آن‌ها را مورد بررسی قرار خواهیم داد.
– PRC: این اصطلاح مخفف واژگان Programmable Remote Client است. این نوع وب سرویس در دو نوع مدل XML-RPC و JSON-RPC عرضه شده است و همان‌طور که از نام آن‌ها مشخص است، مدل اول از فرمت XML پشتیبانی می‌کند و مدل دوم از JSON.
– SOAP: این اصطلاح مخفف واژگان Simple Object Access Protocol است که به منزله پروتکلی است که متد ارتباطی، نحوه ارسال درخواست، دریافت پاسخ و همچنین فرمت پاسخ‌ها را تعیین می‌کند. به عبارتی، این نوع API راهی است که از آن طریق سیستم‌ها از طریق فرمتی که قابل‌درک برای هر دو طرف کانکشن است می‌توانند با یکدیگر ارتباط برقرار سازند که معمولا درگاه‌های بانکی از این فرمت پشتبانی می‌کنند.
– REST: این اصطلاح که مخفف واژگان Representational State Transfer است بر خلاف موارد قبل یک پروتکل حساب نمی‌شود بلکه نوعی معماری است که نسبت به بقیه کاربرد آسان‌تری دارد و به همین دلیل هم هست که امروزه فراگیر شده است.
– GraphQL: استانداردی برای طراحی و توسعه API است که به صورت اپن‌سورس توسط کمپانی فیسبوک توسعه داده شده است که در حقیقت در پاسخ به نقدهایی که به REST وارد است طراحی شده تا بتواند به عنوان راه‌کاری جامع و اثربخش در توسعه API مورد استفاده قرار گیرد.
به خاطر داشته باشیم که دیتا از طریق وب سرویس‌های مختلف به اشکال گوناگونی می‌تواند رد و بدل شود که از جمله مهم‌ترین آن‌ها می‌توان به XML ،JSON و یا HTML اشاره کرد.
تقسیم‌بندی ای‌پی‌آی‌ها از بُعد سطح دسترسی
علاوه بر تقسیم‌بندی‌های فوق، Web API را می‌توان از نقطه نظر سطح دسترسی (Permission) به دسته‌های مختلفی تقسیم‌بندی کرد که عبارتند از:
– Open APIs: این دست API ها که اصطلاحا Public APIs نیز نامیده می‌شوند، بدون هیچ‌گونه محدودیت در سطح دسترسی برای کاربرد B2C در اختیار دولوپرها قرار می‌گیرند که برای مشاهده لیستی از آن‌ها، می‌توانید به لینک Public APIs در گیت‌هاب مراجعه نمایید.
– Partner APIs: این گروه از API ها صرفا در اختیار کسب‌وکارهای به اصطلاح B2B و B2C است و همچون مورد قبل (Open APIs) هر دولوپری به آن‌ها دسترسی ندارد و معمولا پولی هستند.
– Internal APIs: این گروه از API ها که تحت عنوان Private APIs نیز شناخته می‌شوند، صرفا برای مصرف داخلی یک سیستم طراحی می‌شوند. به طور مثال، لیست مقالاتی که در سایدبار سمت چپ سکان آکادمی در معرض دید کاربران قرار می‌گیرد از طریق یک Private API (API خصوصی) ایجاد شده که صرفا برای استفاده توسط خودِ سایت سکان آکادمی توسعه داده شده است.
API Economy چیست؟
کسب درآمد از طریق عرضه API چیزی است که تحت عنوان API Economy شناخته می‌شود. پیش از این گفتیم که برخی API ها هستند که اصطلاحا Public (عمومی) می‌باشند و بالتبع شرکت عرضهکننده به صورت مستقیم نمی‌تواند از آن‌ها کسب درآمد کند اما در مقابل برخی شرکت‌ها هم هستند که از طریق عرضه API سرویس‌های اختصاصی خود، به کسب درآمد می‌پردازند بدین شکل که مثلا تا ده هزار درخواست در ماه رایگان است اما اگر به طور مثال اپلیکیشنی طراحی نموده‌ایم که تعداد کاربران زیادی دارد و بالتبع بار بیشتری روی سرورهای شرکت مذکور وارد می‌آورد، برای این منظور باید سرویس پریمیوم خریداری کنیم.
طراحی API
این نکته را همواره باید مد نظر قرار داد که طراحی API از پایه کار نسبتاً دشواری است که مراحلی پیچیده و بسیار تخصصی دارا است. برای آنکه یک تصویر کلی از پروسه طراحی API داشته باشیم، باید گفت که عموما API ها با توجه به برخی الگوها و استانداردها ساخته می‌شوند تا تمامی توسعه‌دهندگان از سراسر دنیا بتوانند بدون سردرگمی از آن‌ها استفاده کنند که بررسی این موضوع خارج از این بحث است.
تامین امنیت API
اگر همه چیز به درستی و با دقت پیش برود، عرضه API خطری امنیتی برای شما محسوب نمی‌شود اما نیاز به توضیح نیست که هرچه راه‌های ارتباطی با سرورهای خود را بیشتر کنید، راه‌های نفوذ به آن نیز افزایش می‌یابد و از آنجایی که برخی API ها به برخی از امکانات سرویس دسترسی می‌دهند که مثلا تعامل با دیتای ذخیره‌شده روی دیتابیس هم بخشی از آن‌ها است و مسلما از حساسیت بالایی برخوردار است، می‌تواند در صورت پیاده‌سازی غیراصولی خسارت‌های زیادی به بار آورد که برای حل این قبیل مشکلات چندین راه‌کار وجود دارد.
سعی کنید API خود را بر روی سروری جداگانه و متفاوت از دیتابیسی که به آن متصل می‌شود راه‌اندازی کنید. همچنین اگر به کاربران خود امکان اضافه کردن و یا ویرایش اطلاعات را نیز می‌دهید، خود را برای مقابله با هر نوعی از Injection آماده کنید.
یکی دیگر از حملات سایبری خطرناک Distributed Denial of Service یا به اختصار DDoS نام دارد که نیاز دارید تا راه‌کارهای حفاظتی برای مقابله با این حملات را نیز رعایت کنید
