در برنامه نویسی کامپیوتر، یک رابط کاربردی برنامه نویسی(API) مجموعه ای از زیرروال ها    (Subroutine)، تعاریف، پروتکل ها و ابزار ها به منظور ساخت یک نرم افزار کاربردی می باشد.

API چیست؟

به زبان عامیانه تر، API مجموعه ای از روش های تعریف شده و شفاف به منظور ارتباط بین اجزا مختلف نرم افزار می باشد. یک API خوب با فراهم کردن سنگ بناهای لازم، توسعه یک نرم افزار کامپیوتری را آسان تر می کند. یک API می تواند برای یک سیستم تحت وب، سیستم عامل، سیستم بانک اطلاعاتی، سخت افزار کامپیوتر و یا کتابخانه نرم افزار طراحی شده باشد. مشخصات API می تواند شکل های مختلفی داشته باشد اما این مشخصات اغلب شامل روال ها، ساختمان داده ها، دسته های اشیا، متغیر ها یا دستورات فراخوانی می باشد. POSIX،  Microsoft Windows API،  C++ Standard Template Library و Java API مثال هایی از حالت های مختلف API هستند. معمولا مستند سازی نیز برای API ها ارائه می شود تا استفاده از آن ها را راحت تر کند.

هدف

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

کاربردهای API

کتابخانه ها و چارچوب ها (فریم ورک)

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

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

قید های زبانی نیز جز API ها به شمار می روند. با نگاشتن ویژگی ها و توانایی های یک زبان به یک رابط که به زبان دیگری در حال اجرا می باشد، یک قید زبانی این امکان را فراهم می کند که از یک کتابخانه یا سرویس که به یک زبان نوشته شده است به هنگام توسعه نرم افزار های مختلف در زبان های دیگر استفاده شود. ابزار هایی نظیر  SWIG و  F2PY-که یک رابط ساز از فرترن به پایتون می باشد – ساخت چنین رابط هایی را آسان تر می کنند.

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

سیستم های عامل

یک API می تواند رابط میان یک برنامه و سیستم عامل را مشخص کند. برای مثال،  POSIX مجموعه ای از API های متداول را تعریف می کند که هدف آن این است که یک برنامه که برای یک سیستم عامل سازگار با POSIX نوشته شده را بتوان برای یک سیستم عامل سازگار با POSIX دیگر کامپایل کرد. لینوکس و  Berkeley Software Distribution نمونه هایی از سیستم عامل هایی هستند که از API های POSIX استفاده می کنند.

مایکروسافت تعهد بسیارقوی را نسبت به API های عقب سازگار – به خصوص درون کتابخانه Windows API(Win32)- نشان داده است در نتیجه نرم افزار های قدیمی تر می توانند با استفاده از تنظیمات خاصی برای فایل اجرایی که به نام Compatibility Mode شناخته می شود بر روی نسخه های جدیدتر ویندوز نیز به راحتی اجرا شوند.

تفاوت یک API با رابط دودویی نرم افزار(ABI) در این است که یک API بر مبنای کد منبع است در حالی که ABI بر مبنای دودویی(باینری) می باشد. برای مثال، POSIX در واقع API ها را ارائه می دهد در حالی که Linux Standard Base، ABI را فراهم می کند.

رابط برنامه نویسی راه دور

Remote API ها یا API های راه دور، به توسعه دهندگان اجازه می دهند تا منابع از راه دور را به کمک پروتکل دست کاری کنند. پروتکل ها در واقع استاندارد هایی مشخص برای ارتباطات هستند که به تکنولوژی های مختلف اجازه می دهند بدون توجه به زبان برنامه نویسی یا پلتفرم اجرایی، با یکدیگر کار کنند. برای مثال، Java Database Connectivity API به توسعه دهندگان اجازه می دهد تا انواع مختلفی از بانک های اطلاعاتی را با استفاده از یک مجموعه از توابع جستجو کنند. همچنین  API روش فراخوانی از راه دور جاوا از پروتکل  Java Remote Method برای فراخوانی توابعی استفاده می کند که به صورت از راه دور عمل می کنند اما برای توسعه دهنده به صورت محلی به نظر می رسند. در نتیجه API های راه دور برای حفظ انتزاع اشیا در برنامه نویسی شی گرا بسیار مفید هستند. یک فراخوانی روش که به صورت محلی بر روی یک شی نماینده اجرا می شود با استفاده از پروتکل راه دور، روش متناظر را بر روی یک شی راه دور فراخوانی می کند و نتیجه را برای استفاده محلی به صورت یک مقدار دریافت می کند. هرگونه تغییر در شی نماینده منجر به تغییری متناظر در شی راه دور خواهد شد.

رابط برنامه نویسی تحت وب

رابط برنامه نویسی وب یا Web API رابط های تعریف شده ای هستند که از طریق آن ها برهم کنش هایی میان یک تشکیلات و برنامه هایی که از دارایی های آن استفاده می کنند اتفاق می افتد. رویکرد API یک رویکرد معماری است که محور آن ارائه یک رابط که امکان برنامه نویسی بر روی آن فراهم باشد برای خدماتی است که در برنامه های کاربردی متفاوت برای مصرف کنندگان مختلف مورد استفاده قرار می گیرند. منظور از یک API وقتی در زمینه توسعه وب مورد بررسی قرار می گیرد در واقع مجموعه ای از پیام های درخواست  HTTP به همراه تعریف ساختار پیام های پاسخ می باشد که معمولا به زبان XML و یا فرمت JSON  می باشد. یک مثال خوب در این زمینه می تواند مربوط به API یک شرکت حمل بار باشد که می توان آن را بر روی یک وب سایت تجارت الکترونیکی اضافه کرد تا سفارش خدمات حمل و نقل و باربری را آسان تر کرده و به صورت خودکار نرخ های به روز خدمات باربری را-بدون نیاز به این که طراح سایت جدول تعرفه های حمل و نقل را به صورت یک بانک اطلاعاتی در بانک اطلاعاتی وب وارد کند- بر روی فاکتور نهایی منظور کند. با وجود این که Web API از لحاظ تاریخی تقریبا مترادف با خدمات وب درنظر گرفته شده، روند اخیر( که با نام  Web 2.0 شناخته می شود) نشان دهنده دور شدن آن از خدمات وب بر مبنای پروتکل دسترسی آسان به اشیا(SOAP) و معماری سرویس گرا (SOA) و نزدیک تر شدن آن به شیوه مستقیم تر منابع تحت وب به صورت REST و معماری منبع گرا(ROA) می باشد. بخشی از این روند مربوط به حرکت وب معنایی به سمت RDF که یک مفهوم برای ترویج تکنولوژی های مهندسی آنتولوژی بر مبنای وب است، می باشد. Web API ها امکان ترکیب چندین API را در داخل نرم افزار های جدیدی که به آن ها Mashup گفته می شود فراهم می کند. در فضای شبکه های مجازی، web API ها برای جوامع مجازی تحت وب، به اشتراک گذاری محتوا و داده میان کاربران و برنامه ها را آسان تر کرده اند. با این روش، محتوایی که در یک مکان تولید می شود می تواند به صورت پویا در چندین محل در وب ارسال یا بروزرسانی شود.

طراحی API

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

افراد مختلفی تاکنون توصیه نامه هایی را برای چگونگی طراحی API ها نوشته اند که به عنوان مثال می توان به  Joshua Bloch، Kin Lane و Michi Henning اشاره کرد.

سیاست های انتشار API

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

سیاست های اصلی برای انتشار API ها عبارتند از:

• خصوصی: API تنها برای مصارف داخلی شرکت می باشد.
• شراکتی: تنها شرکای تجاری مشخصی می توانند از API استفاده کنند. برای مثال،شرکت های خدمات اتومبیل مانند  Uber و  Lyft به توسعه دهندگان شخص ثالث مورد تایید خود اجازه می دهند تا به طور مستقیم از داخل اپلیکیشن های خود اقدام به درخواست اتومبیل کنند. این کار به شرکت ها اجازه می دهد کنترل کیفیت را از طریق کنترل اپلیکیشن هایی که به API دسترسی دارند عملی کنند.
• عمومی: API برای استفاده عموم می باشد. برای مثال، مایکروسافت Windows API  را به صورت عمومی منتشر می کند یا اپل نیز API های خود یعنی  Carbon و  Cocoa را به صورت عمومی منتشر می کند. هدف این شرکت ها از این کار این است که بتوان برای پلتفرم های آن ها نرم افزار تولید کرد.

پیامد های API عمومی

زمانی که یک API عمومی می شود، یکی از فاکتور های مهم پایداری رابط آن است. تغییرات اعمالی توسط یک توسعه دهنده بر روی بخشی از API- برای مثال اضافه کردن پارامتر های جدید به یک فراخوانی تابع- ممکن است سازگاری API را با سایر استفاده کنندگان برهم بزند.

وقتی بخش هایی از یک API عمومی تغییر داده می شوند و در نتیجه ناپایدار می شوند باید این قسمت ها را به صورت مشخص به عنوان ناپایدار ثبت کرد. برای مثال در کتابخانه Google Guava بخش هایی که در حال حاضر ناپایدار در نظر گرفته شده اند- ولی ممکن است وضعیت آن ها در آینده تغییر کند- به صورت کد @Beta نمایش داده می شوند.

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

مستندسازی API

مستندسازی API در واقع خدماتی را که یک API ارائه می دهد توصیف می کند و نحوه استفاده از آن ها را بیان می کند و هدف آن پوشش دادن تمامی چیزهایی است که یک کاربر API باید از آن ها اطلاع داشته باشد. مستندسازی برای توسعه و نگهداری نرم افزاری هایی که از API استفاده می کنند کاملا حیاتی است. مستندات API به طور معمول در فایل های مربوط به مستندسازی قرار دارد اما می توان آن را در فضای مجازی مانند بلاگ ها، انجمن ها و وب سایت های پرسش و پاسخ نیز پیدا کرد. فایل های مستندسازی سنتی اغلب به وسیله یک سیستم مستندسازی مانند Javadoc یا Pydoc ارائه می شوند که ساختار و ظاهری ثابت و یکنواخت دارند. با این حال، نوع محتوایی که در مستندات قرار می گیرد برای هر API متفاوت است. برای درک راحت تر،مستندات API می تواند شامل شرح دسته ها و روش ها در API و همچنین سناریو های متداول استفاده، قطعه کد ها، منطق های طراحی، بحث و توضیح در مورد عملکرد و قراردادها باشد اما جزئیات اجرایی خدمات API معمولا از مستندسازی حذف می شوند. محدودیت های مربوط به نحوه استفاده از API نیز معمولا توسط مستندات پوشش داده می شوند. برای مثال، مستندات یک تابع API می تواند اعلام کند که پارامتر های آن تابع نمی تواند تهی باشد یا خود تابع اصطلاحا thread safe نیست. به دلیل این که مستندات API بسیار کامل و جامع است بروزرسانی آن برای نویسندگان و همچنین خواندن دقیق آن برای کاربران می تواند سخت باشد که منجر به باگ های نرم افزاری می شود.

مستندات API را می توان با اطلاعات فراداده مانند حاشیه نویسی های جاوا غنی تر کرد. این فراداده می تواند توسط کامپایلر، ابزار و محیط run-time مورد استفاده قرار بگیرد تا رفتار های خاصی را پیاده سازی کند.

جنجال کپی رایت

در سال 2010، شرکت  Oracle Corporation، شرکت گوگل را به دلیل توزیع پیاده سازی نسخه جدیدی از جاوا به صورت جاسازی شده در سیستم عامل اندروید مورد پیگرد قانونی قرار داد.گوگل هیچگونه مجوزی برای تولید دوباره API جاوا به دست نیاورده بود. البته چنین مجوزی برای یک پروژه OpenJDK مشابه قبلا صادر شده بود. رای قاضی  William Alsup در این پرونده به این ترتیب بود که در ایالات متحده نمی توان API ها را تحت قانون کپی رایت قرار داد و این که پیروزی برای Oracle قانون حفظ کپی رایت را به طرز چشمگیری گسترش می دهد و اجازه ایجاد کپی رایت برای دستور های ساده نرم افزاری را نیز می دهد.

“قبول کردن ادعای Oracle به معنای این است که به هر شخصی اجازه بدهیم تا یک نسخه از یک کد که برای اجرای مجموعه ای از دستورات به کار می رود را تحت حفاظت کپی رایت قرار دهد و در نتیجه با این کار، دیگران از نوشتن نسخه های متفاوت از آن کد برای اجرای بخشی( یا کل) آن مجموعه دستورات منع می شوند.”

اما در سال 2014 ، رای Alsup در تجدید نظر برگردانده شد. اگرچه این سوال که آیا چنین استفاده ای از API ها، استفاده منصفانه به شمار می رود یا خیر بی پاسخ باقی ماند.

در سال 2016، پس از دو هفته دادگاه، یک هیئت منصفه اعلام کرد که پیاده سازی دوباره API جاوا توسط شرکت گوگل، استفاده منصفانه بوده است. البته Oracle قول داده که برای این تصمیم تقاضای تجدید نظر خواهد کرد.