API چیست؟

واژه API مخفف Application Programming Interface می‌باشد و به معنی «رابط برنامه‌نویسی اپلیکیشن» است. ای‌پی‌آی در واقع مجموعه‌ای از دستورالعمل‌های مشخص و از پیش تعریف شده است که به نرم‌افزارها، سخت‌افزارها، کامپوننت‌ها یا سایت‌های اینترنتی اجازه می‌دهد از طریق آنها با یکدیگر در ارتباط باشند و از امکانات هم استفاده نمایند. ما برای برقراری ارتباطات به API نیاز داریم. با مثالی ساده شما می‌توانید اهمیت API را درک نمایید. فرض کنید برنامه Notepad امکان کپی و پیست را نداشت و نمی‌توانست از مطالب Google Chrome یا Firefox استفاده نماید و باید تمامی آن مطالب را تایپ می‌کردید! این یک مثال ساده از ارتباط بین نرم‌افزارها است. تمامی ارتباطاتی که بین نرم‌افزارها، سخت‌افزارها و... صورت می‌گیرد از طریق API است.

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

طراحی API تقریبا کار مشکلی است و مراحل انجام آن پیچیده است و نیاز به تخصص خاص خود دارد. API مجموعه‌ای از دستورات و توابع است که به دیگر نرم‌افزارها امکان دسترسی به سرویس‌ها یا اطلاعات عرضه شده توسط شما را می‌دهد. اگر ساده‌تر بخواهیم توضیح دهیم برای این که نرم‌افزاری امکان دسترسی به اطلاعات و یا سرویس‌هایی که شما ارئه می‌دهید داشته باشد، باید از یک واسطه به نام API استفاده کند. APIها رایگان و یا پولی هستند و بسته به میزان کیفیت و مقدار Access (اکسس یا دسترسی) که شما درخواست می‌دهید، قیمت آن APIها نیز متغیر خواهد بود. به طور معمول پایین‌ترین سطح‌های اکسس با محدودترین امکانات به صورت رایگان عرضه می‌شوند. همچنین برای اینکه تمام توسعه دهندگان از سراسر دنیا بتوانند از آنها استفاده نمایند، باید از یک سری استانداردها و الگوهای جهانی استفاده کنند.

برای استفاده از API باید مواردی که در ادامه ذکر می‌شود را در نظر داشت:

• در استفاده از APIها درخواست از طرف یک نرم‌افزار در چهارچوب یک فرمت خاص به نرم‌افزار دیگر ارسال می‌شود. به همین دلیل است که می‌گویند APIها ارائه دهنده داده‌های ساختار یافته هستند.
• در استفاده از APIها درخواست‌هایی که از طرف یک نرم‌افزار به نرم‌افزار ارائه دهنده API ارسال می‌شود از پیش تعیین شده هستند بنابراین پاسخ به این درخواست‌ها نیز از پیش تعیین شده و قابل پیشبینی است.
• ای‌پی‌آی‌ها توسط شرکت‌های بسیار بزرگ ایجاد می‌شوند و هدف آنها ارائه سرویس‌های جهانی است. کسانی که قصد استفاده از این APIها را دارند توسعه‌دهندگانی هستند که در این راه باید کاملا مستندات APIها را در اختیار داشته باشند تا سردرگم نشوند و به راحتی از جزئیات آن سر در بیاورند. بنابر این تمام APIها مستند هستند.
• ای‌پی‌آی‌ها یک API Key یا شناسه ای‌‌‌‌پی‌آی در اختیار توسعه‌دهندگان قرار می‌دهند، برای آن که به راحتی مشخص شود که Request یا درخواست از طرف چه سایت یا نرم‌افزاری ارسال شده است. در هر درخواست، این شناسه هم برای شرکت ارائه دهنده API ارسال می‌شود که از طریق آن، ماهیت اپلیکیشن شما برای آن سیستم مشخص شده و بر اساس توافقاتی که برای استفاده از API صورت گرفته، این شرکت خدمات را در اختیار شما قرار می‌دهد. استفاده دیگری که از این شناسه می‌شود این است که مشخص می‌کند هر شرکت توسعه دهنده هر چند وقت یکبار می‌تواند برای نرم‌افزار ارائه دهنده API درخواست ارسال کند. برخی از APIها در بازه‌های زمانی 30 دقیقه‌ای به درخواست‌های ارسال شده از طرف توسعه دهنده پاسخ می‌دهند و اگر توسعه دهنده در در طی این بازه بیش از یک درخواست به نرم‌افزار ارائه دهنده API ارسال نماید، این درخواست‌ها نادیده گرفته می‌شود و یا به اصطلاح Ignore می‌گردد و پاسخی به درخواست دهنده ارسال نمی‌شود.

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

یک مثال مناسب در این حوزه Twitter است. بیشتر مردم کلاینت توییتر مورد علاقه‌شان را به جای رابط وب ترجیح می‌دهند. شما می‌توانید با استفاده از وسیله‌هایی مانند گوشی‌های تلفن، موبایل‌های هوشمند، iPod یا کامپیوتر از توییتر  استفاده نمایید. وجود داشتن این امکانات نشان دهنده این است که توییتر از یک API عالی و منحصر به فرد استفاده می‌کند.

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

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

انواع مختلفی از API در سخت‌افزارها و نرم‌افزارها وجود دارند. برخی از انواع شناخته‌شده‌ی API عبارتند از:

• ای‌پی‌آی‌ سیستم عامل ویندوز برای برنامه‌نویسی و ارتباط با هسته ویندوز
• ای‌پی‌آی‌ سایت توییتر برای توسعه‌ی رابط کاربری سفارشی روی کامپیوترهای رومیزی و گوشی‌های موبایل
• ای‌پی‌آی‌ جاوا برای برنامه‌نویسی و ارتباط با هسته‌ی کتابخانه‌های جاوا
• ای‌پی‌آی‌ نقشه گوگل برای نمایش نقشه و دریافت اطلاعات در مورد مکان‌های مختلف جهان
• ای‌پی‌آی‌ بانک‌های مختلف برای انجام پرداخت آنلاین

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

• دسترسی به API را توسط یک سیستم شناسایی کاربر قدرتمند حفاظت کنید، حتی اگر آن API را به رایگان ارائه می‌کنید.
• سعی کنید سرویس API خود را بر روی سروری جداگانه و متفاوت از دیتابیسی که به آن متصل می‌شود، راه اندازی کنید.
• اگر به کاربران خود امکان اضافه کردن و یا ویرایش اطلاعات را نیز می‌دهید، خود را برای مقابله با حملات Injection آماده کنید.
• یکی دیگر از حملات سایبری خطرناک Denial of Service یا DOS نام دارد که نیاز دارید تا راهکارهای حفاظتی برای مقابله با این حملات را نیز رعایت کنید.

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

نمی‌توان گفت که APIها همیشه مفید هستند. شرکت‌های مختلفی برای کسب سود بیشتر، سرویس‌های مختلف و APIهایی که اپلیکیشن‌های شما به آنها وابسته هستند را از دسترس خارج کرده‌اند. مثال‌هایی که نشان دهنده این نقص هستند:

• شرکت توییتر از یک سال پیش محدودیت‌هایی برای اپلیکیشن‌های وابسته به APIهای این شرکت وضع کرده است. این تصمیم باعث می‌شود که عملا برنامه‌های وابسته به توئیتر بی‌استفاده شوند و کاربران فقط امکان استفاده از برنامه‌ها و وبسایت این شرکت را خواهند داشت و بدین ترتیب توییتر می‌تواند مطمئن باشد که درآمدزایی مبتنی بر نمایش تبلیغات، به صورت موثر و متمرکزتری انجام می‌شود.
• شرکت گوگل طی تصمیماتی سرویس‌هایی مانند Google Health و Google Reader را که گمان می‌ر‌فت به سمت زیان‌ده بودن پیش می‌روند از دسترس خارج کرد و این سرویس‌ها هیچوقت دوباره راه‌اندازی نشدند. مسلما این تصمیمات برای کاربرانی که از اپلیکیشن‌های وابسته استفاده می‌کنند ناخوشایند خواهد بود و این اپیکیشن‌ها بلااستفاده می‌شود.

با این حال و با وجود نقص‌های که استفاده از ای‌پی‌آی دارد همواره استفاده از آن در حال گسترش است و طرفدار زیادی دارد.

در حوزهٔ توسعهٔ نرم‌افزار به کرات واژهٔ 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 وارد است طراحی شده تا بتواند به عنوان راه‌کاری جامع و اثربخش در توسعهٔ ای‌پی‌آی مورد استفاده قرار گیرد.

به خاطر داشته باشیم که دیتا از طریق وب سرویس‌های مختلف به اشکال گوناگونی می‌تواند رد و بدل شود که از جملهٔ مهم‌ترین آن‌ها می‌توان به 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 آماده کنید که برای کسب‌ اطلاعات بیشتر،‌ توصیه می‌کنیم به مقالات زیر مراجعه نمایید:

- آشنایی با مفهوم SQL Injection در زبان PHP۱۳۷
- XPath Injection: آشنایی با آسیب‌پذیری داکیومنت‌های XML۱۶۱

یکی دیگر از حملات سایبری خطرناک Distributed Denial of Service یا به اختصار DDoS نام دارد که نیاز دارید تا راه‌کارهای حفاظتی برای مقابله با این حملات را نیز رعایت کنید که برای این منظور توصیه می‌کنیم به مقالهٔ زیر مراجعه نمایید:

 DDoS (دیداس) چیست؟۲۵۲