در حوزهٔ توسعهٔ نرم‌افزار به کرات واژهٔ 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 همچون گوگل یا فیسبوک هم مادامی که دست به تغییر استانداردهای خود نزنند و اختلالی در کار دولوپرهایی که پیش از این سرویس‌های آن‌ها را مورد استفاده قرار می‌دادند ایجاد نکنند، به سادگی می‌توانند سرورهای خود را آپگرید کنند، محل فیزیکی دیتاسنترهای خود را تغییر دهند، بین سرویس‌های کلود مختلف سوئیچ کنند و غیره.
به طور مثال، فرض کنیم اپلیکیشنی تحت عنوان «الف» وجود دارد که توسعه‌دهنده‌اش این امکان را برای سایر توسعه‌دهندگان فراهم آورده تا از API آن استفاده کنند. حال فرض کنیم اپلیکیشنی نوشته‌ایم تحت عنوان «ب» و این در حالی است که اپلیکیشن «الف» در چارچوب خاصی به اپلیکیشن «ب» اجازه می‌دهد تا از امکاناتی که دارا است استفاده کند (با مراجعه به سایت ProgrammableWeb می‌توانید به لیست جامعی از API سرویس‌های مختلفی که توسط شرکت‌های مطرحی همچون گوگل، فیسبوک، توییتر و ... عرضه شده‌اند دست یابید.) در عین حال، در حین استفاده از API لازم است یکسری استاندارد حتماً مد نظر قرار داده شوند که برخی از مهم‌ترین آن‌ها عبارتند از:
- دیتایی که از طریق API مبادله می‌گردد ساختاریافته است: به عبارتی، درخواست از طرف نرم‌افزار «ب» در چارچوب یک فرمت استاندارد صورت می‌گیرد که از قبل توسط توسعه‌دهندگان نرم‌افزار «الف» تعریف شده است.
- نتیجهٔ تعامل با API قابل‌پیش‌بینی است: در واقع، درخواست‌هایی که برای نرم‌افزار «الف» ارسال می‌شوند باید در یک چارچوب خاصی باشند و از همین روی پاسخ به چنین درخواست‌هایی همواره مشخص و قابل‌پیش‌بینی خواهند بود.
آشنایی با انواع API
با در نظر گرفتن این نکته که API سازوکاری است که از آن طریق تعامل سیستم با سیستم به جای تعامل کاربر با سیستم صورت می‌گیرد، می‌توان دسته‌بند‌ی‌های مختلفی برای ای‌پی‌آی‌ها در نظر گرفت که عبارتند از:
- ای‌پی‌آی سخت‌افزاری: زمانی که مثلاً با اجرای یک گیم حرفه‌ای فشار زیادی روی سیستم خود می‌آوریم، می‌بینیم که فن سیستم شروع به تند چرخیدن می‌کند و این به دلیل آن است که سی‌پی‌یو نسبت به حالت عادی در معرض فشار بیشتر است و بالتبع داغ شده است و باید خنک گردد که این سازوکار از طریق ارتباط مابین ای‌پی‌آی‌های سخت‌افزاری صورت می‌گیرد.
- ای‌پی‌آی سیستم‌عاملی: پیش از این در قالب مثال توسعهٔ یک نرم‌افزار دسکتاپ توضیح دادیم که ای‌پی‌آی مرتبط با یک سیستم‌عامل همچون ویندوز به چه شکل کار می‌کند.
- ای‌پی‌آی زبان‌های برنامه‌نویسی: زبانی همچون جاوا یک هستهٔ اصلی دارد که شامل سینتکس این زبان، نحوهٔ ساخت متغیر، دیتا تایپ‌ها و ... می‌شود اما در کنار آن‌ها صدها کلاس مختلف توسط توسعه‌دهندگان این زبان عرضه شده که تحت عنوان Java API شناخته می‌شوند که فیچرهای تکمیلی این زبان را در دسترس دولوپرها قرار می‌دهند.
- کیت‌های توسعهٔ نرم‌افزار: Software Development Kit یا به اختصار SDK نیز نوعی دیگی از ای‌پی‌آی‌ها است که توسط شرکت‌های مختلفی همچون گوگل، فیسبوک و ... عرضه می‌شوند تا دولوپرها با استفاده از این کیت‌ها بتوانند اقدام به توسعهٔ نرم‌افزار کنند که از آن جمله می‌توان به Android SDK اشاره کرد.
- ای پی آی تحت وب (وب سرویس): این نوع ای‌پی‌آی یکی از متداول‌ترین و کاربردی‌ترین انواع ای‌پی‌آی است که ادامه تمرکز روی همین مقوله خواهیم کرد. ای‌پی‌آی تحت وب یا اصطلاحاً Web API به هر پروتکلی گفته می‌شود که از طریق شبکهٔ اینترنت و وب تعامل مابین اپلیکیشن‌های مختلف را امکان‌پذیر سازد و از همین روی Web Service نیز نامیده می‌شود (وب اپلیکیشنی که محتوای خود را از طریق چندین و چند ای‌پی‌آی مختلف تأمین کند اصطلاحاً Mashup نامیده می‌شود.) زمانی که پای ای‌پی‌آی‌های تحت وب به میان می‌آید، باید با سازوکار پروتکل HTTP و HTTPS آشنا باشیم که برای این منظور توصیه می‌کنیم به دورهٔ رایگان وب چگونه کار می‌کند؟ مراجعه نمایید.
درآمدی بر انواع وب سرویس‌ها
به طوری کلی، وب سرویس‌ها را می‌توان به دسته‌های GraphQL ،SOAP ،PRC و یکی از معروف‌ترین آن‌ها در حال حاضر REST دسته‌بندی کرد که در ادامه آن‌ها را مورد بررسی قرار خواهیم داد.
- PRC: این اصطلاح مخفف واژگان Programmable Remote Client است. این نوع وب سرویس در دو نوع مدل XML-RPC و JSON-RPC عرضه شده است و همان‌طور که از نام آن‌ها مشخص است، مدل اول از فرمت اکس‌ام‌ال پشتیبانی می‌کند و مدل دوم از جیسون (نیاز به توضیح است که این وب سرویس امروزه کاربرد چندانی ندارد.)
- SOAP: این اصطلاح مخفف واژگان Simple Object Access Protocol است که به منزلهٔ پروتکلی است که متد ارتباطی، نحوهٔ ارسال درخواست، دریافت پاسخ و همچنین فرمت پاسخ‌ها را تعیین می‌کند. به عبارتی، این نوع ای‌پی‌آی راهی است که از آن طریق سیستم‌ها از طریق فرمتی که قابل‌درک برای هر دو طرف کانکشن است می‌توانند با یکدیگر ارتباط برقرار سازند (معمولاً درگاه‌های بانکی از این فرمت پشتبانی می‌کنند.)
- REST: این اصطلاح که مخفف واژگان Representational State Transfer است بر خلاف موارد قبل یک پروتکل حساب نمی‌شود بلکه نوعی معماری است که نسبت به بقیه کاربرد آسان‌تری دارد و به همین دلیل هم هست که امروزه فراگیر شده است که برای کسب اطلاعات بیشتر، می‌توانید به آموزش آشنایی با مفهوم RESTful API و مقالهٔ آشنایی با نحوهٔ استفاده از RESTful API در پایتون مراجعه نمایید.
- GraphQL: استانداردی برای طراحی و توسعهٔ API است که به صورت اپن‌سورس توسط کمپانی فیسبوک توسعه داده شده است که در حقیقت در پاسخ به نقدهایی که به REST وارد است طراحی شده تا بتواند به عنوان راه‌کاری جامع و اثربخش در توسعهٔ ای‌پی‌آی مورد استفاده قرار گیرد (برای یادگیری GraphQL می‌توانید به دوره رایگان آموزش GraphQL مراجعه کنید).
به خاطر داشته باشیم که دیتا از طریق وب سرویس‌های مختلف به اشکال گوناگونی می‌تواند رد و بدل شود که از جملهٔ مهم‌ترین آن‌ها می‌توان به XML ،JSON و یا HTML اشاره کرد.
تقسیم‌بندی ای‌پی‌آی‌ها از بُعد سطح دسترسی
علاوه بر تقسیم‌بندی‌های فوق، Web API را می‌توان از نقطه نظر سطح دسترسی (پرمیشن) به دسته‌های مختلفی تقسیم‌بندی کرد که عبارتند از:
- Open APIs: این دست ای‌پی‌آی‌ها که اصطلاحاً Public APIs نیز نامیده می‌شوند، بدون هیچ‌گونه محدودیت در سطح دسترسی برای کاربرد B2C در اختیار دولوپرها قرار می‌گیرند که برای مشاهدهٔ لیستی از آن‌ها، می‌توانید به لینک Public APIs در گیت‌هاب مراجعه نمایید.
- Partner APIs: این گروه از ای‌پی‌آی‌ها صرفاً در اختیار کسب‌وکارهای به اصطلاح B2B و B2C است و همچون مورد قبل (Open APIs) هر دولوپری به آن‌ها دسترسی ندارد و معمولاً پولی هستند.
- Internal APIs: این گروه از ای‌پی‌آی‌ها که تحت عنوان Private APIs نیز شناخته می‌شوند، صرفاً برای مصرف داخلی یک سیستم طراحی می‌شوند. به طور مثال، لیست مقالاتی که در سایدبار سمت چپ سکان آکادمی در معرض دید کاربران قرار می‌گیرد از طریق یک Private API (ای‌پی‌آی خصوصی) ایجاد شده که صرفاً برای استفاده توسط خودِ سایت سکان آکادمی توسعه داده شده است.
API Economy چیست؟
کسب درآمد از طریق عرضهٔ ای‌پی‌آی چیزی است که تحت عنوان API Economy شناخته می‌شود. پیش از این گفتیم که برخی ای‌پی‌آی‌ها هستند که اصطلاحاً پابلیک (عمومی) می‌باشند و بالتبع شرکت عرضه‌کننده به صورت مستقیم نمی‌تواند از آن‌ها کسب درآمد کند اما در مقابل برخی شرکت‌ها هم هستند که از طریق عرضهٔ ای‌پی‌آی سرویس‌های اختصاصی خود، به کسب درآمد می‌پردازند بدین شکل که مثلاً تا ده هزار ریکوئست در ماه رایگان است اما اگر به طور مثال اپلیکیشنی طراحی نموده‌ایم که تعداد کاربران زیادی دارد و بالتبع بار بیشتری روی سرورهای شرکت مذکور وارد می‌آورد، برای این منظور باید سرویس پریمیوم خریداری کنیم.
طراحی API
این نکته را همواره باید مد نظر قرار داد که طراحی API از پایه کار نسبتاً دشواری است که مراحلی پیچیده و بسیار تخصصی دارا است. برای آنکه یک تصویر کلی از پروسهٔ طراحی ای پی آی داشته باشیم، باید گفت که عموماً ای‌پی‌آی‌ها با توجه به برخی الگوها و استانداردها ساخته می‌شوند تا تمامی توسعه‌دهندگان از سراسر دنیا بتوانند بدون سردرگمی از آن‌ها استفاده کنند که بررسی این موضوع خارج از این بحث است.
تأمین امنیت API
اگر همه چیز به درستی و با دقت پیش برود، عرضهٔ API خطری امنیتی برای شما محسوب نمی‌شود اما نیاز به توضیح نیست که هرچه راه‌های ارتباطی با سرورهای خود را بیشتر کنید، راه‌های نفوذ به آن نیز افزایش می‌یابد و از آنجایی که برخی ای‌پی‌آی‌ها به برخی از امکانات سرویس دسترسی می‌دهند که مثلاً تعامل با دیتای ذخیره‌شده روی دیتابیس هم بخشی از آن‌ها است و مسلماً از حساسیت بالایی برخوردار است، می‌تواند در صورت پیاده‌سازی غیراصولی خسارت‌های زیادی به بار آورد که برای حل این قبیل مشکلات چندین راه‌کار وجود دارد.
سعی کنید API خود را بر روی سروری جداگانه و متفاوت از دیتابیسی که به آن متصل می‌شود راه‌اندازی کنید. همچنین اگر به کاربران خود امکان اضافه کردن و یا ویرایش اطلاعات را نیز می‌دهید، خود را برای مقابله با هر نوعی از Injection آماده کنید که برای کسب اطلاعات بیشتر، توصیه می‌کنیم به مقالات زیر مراجعه نمایید:
یکی دیگر از حملات سایبری خطرناک Distributed Denial of Service یا به اختصار DDoS نام دارد که نیاز دارید تا راه‌کارهای حفاظتی برای مقابله با این حملات را نیز رعایت کنید که برای این منظور توصیه می‌کنیم به مقالهٔ DDoS (دیداس) چیست؟ مراجعه نمایید.