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

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

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