سیستم های عامل
(مواردی کاربردی از 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
- مواردی کاربردی از api