مروری بر مفاهیم پایه در توسعه API
برای اطلاع از مفاهیم پایه درAPI ابتدا باید درمورد خود apiصحبت کنیم api یکی از موضوعات مهم و مطرح در دهه اخیر است. پیشتازان تکنولوژی در حوزه فناوری اطلاعات نظیر گوگل، فیس‌بوک، اپل و تویتر امروزه راه‌کارهای فناورانه‌ی زیادی را به مردم عرضه کردند و حتی صنعت‌های جدیدی را نیز شکل داده‌اند. یکی از کلیدی‌ترین عوامل موفقیت این شرکت‌ها APIهایی هستند که مردم و تجهیزات مختلف را به زیرساخت‌ها و پلتفرم‌های زیرین متصل می‌کنند. دنیا در حال تغییر است. برای نمونه:
شرکت Salesforce به واسطه باز نمودن سرویس‌های پایه‌ای برای شرکای خود، یک اکوسیستم بزرگ و ثروتمند از شرکا ایجاد نموده است. امروزه اغلب ترافیک‌های Salesforce از طرق APIها می باشد و نه وب‌سایت. در اواسط سال ۲۰۱۱ بیش از ۶۰ درصد ترافیک Salesforce به واسطه APIها بوده است.
– هسته اصلی زیرساخت‌های محاسباتی خود را از طریق AWS (که عملاً به واسط APIها در دسترس می‌باشد) باز نمود و در حال حاضر اکثر پهنای باند آن برای AWS صرف می‌شود و نه فروشگاه اینترنتی آن .
< > تحول چشمگیری در روش نمایش فیلم‌های تلویزیونی و انواع ویدئوها بر روی تجهیزات مختلف ایجاد نمود که نه تنها روش اجاره ویدئو را تغییر داد و به طور کل آن روش را منسوخ نمود بلکه تاثیر به‌سزایی در صنعت تلویزیون‌های کابلی در کشورهای اروپایی و آمریکایی داشت. APIها این امکان را فراهم ساختند تا این شرکت بتواند از انواع مختلف تجهیزات را پشتیبانی نموده و محتوای خود را بر روی رسانه‌ها و انواع تلفن‌های هوشمند، تبلت‌ها و … نمایش دهد. همچنین روند رشد صنعت‌هایی نظیر تلفن‌های هوشمند، زیرساخت‌های شبکه، مراکز داده، ظهور رایانش ابری، اینترنت اشیا و داده‌های عظیم نیز در ظهور و رشد APIها تاثیر چشمگیری داشته‌اند.
اما مساله مهمی که در اینجا وجود دارد این است که باید به نحوی از پایداری، امنیت و پشتیبانی فنی و تجاری APIها اطمینان حاصل شود زیرا دیگر همه خدمات در یک مجموعه مشخص متمرکز نیست بلکه سیستمی از تعهدات میان افراد مختلف ایجاد شده است. یعنی باید امکانی فراهم شود تا APIهای تامین‌کنندگان مختلف محتوا و سرویس در کنار هم قرار گرفته و شرکت‌های طرف ثالث، همکاران، شرکاء و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از هر کدام از آنها یا ترکیبی از آنها استفاده نموده و سرویس ارزش افزوده جدید خلق نمایند. به همین ترتیب باید به نحوی از مدل‌های کسب‌وکار مختلفی که در این زنجیره وجود دارد حمایت شود به عبارتی باید بستری برای تبدیل و تبادل ارزش میان اعضای زنجیره فراهم گردد. برای حل این دست چالش‌ها به وجود پلتفرمی یکپارچه برای مدیریت API ها نیاز است که بتواند کل چرخه زندگی API را مدیریت نمایند.
در این مستند در ابتدا مفاهیم پایه این حوزه نظیر تعریف API، انواع پروتکل‌ها، زبان‌های توصیف و فرمت های داده شرح داده خواهد شد و سپس تحلیلی کوتاه از روند تکنولوژی روز در هر یک از مفاهیم فوق ارائه شده است.
تعریف API
واسط برنامه کاربردی یا API، امکان به کارگیری داده‌ها یا کارکردمندی‌های یک سیستم نرم‌افزاری را فراهم می‌نماید. API روشی پایدار، سازمان‌یافته و استاندارد برای دسترسی به منابع نرم‌افزاری و اتصال سیستم‌های مختلف نرم‌افزاری به یکدیگر می‌باشد. برای طراحی سیستم‌های با کیفیت بالا و امکان به اشتراک گذاری داده و کارکردمندی‌ها به صورت کارا، وجود API ضروری می‌باشد. همچنین API راه‌حلی برای اتصال، یکپارچه‌سازی و توسعه سیستم‌های نرم‌افزاری پیچیده و بزرگ مقیاس است می‌باشد.
به‌طور خاص یک API ابزاری از پروتکل‌ها و روتین‌ها است که چگونگی تعامل یک برنامه با دیگر برنامه‌ها یا سرویس‌ها را مشخص می‌سازد. امروزه به دلیل اقبال عمومی به مهاجرت داده‌ها و برنامه‌ها به ابر از یک سو و رشد روز افزون سیستم‌ها و زیرساخت‌ها از سوی دیگر، نیاز است تا داده‌های قابل‌حملی ایجاد شوند تا بتوان این داده‌ها را به سادگی به بسترهای مختلف منتقل نمود و حتی المکان داده‌ها و سرویس‌هایی مستقل از بستر و زیرساخت ایجاد کرد.
به طور ساده می توان گفت افراد از واسطهای کاربری به‌منظور کار با نرم‌افزارها بهره می‌برند. اما مخاطب برنامه‌های کاربردی صرفاً انسان‌ها نمی‌باشند یک برنامه‌های کاربردی نیز می‌تواند از برنامه‌های کاربردی دیگری استفاده کند منتها این ارتباط از طریق یک واسط برنامه کاربردی یا به‌اختصار API، انجام می‌گیرد. برخی از کاربردهای APIها عبارتند از:
اتصال اجزای سیستمی به هم
اتصال دستگاه‌های قابل‌حمل و مرورگرها
اجرا و پردازش مجموعه‌ای از دستورات از یک نقطه واحد
امکان اتصال بدون توجه به زبان برنامه‌نویسی و پلتفرم پیاده‌سازی شده
مفهوم APIها یک مفهوم عمومی است که می‌تواند به صورت‌های مختلف استفاده شود درنتیجه تعاریف مختلفی برای آن وجود دارد:
API یک سرویس وبی است که منابع را از طریق فناوری وب مانند HTTP ارائه می‌دهد. این نوع APIها برای ساخت سیستم‌های توزیع‌شده استفاده می‌شوند.
یک API، ساده، قابل‌دسترس و راحت است. مانند یک سوکت که برنامه‌های مختلف می‌توانند به‌راحتی(به‌مانند اتصال وسایل الکترونیکی به شبکه برق) به آن متصل شوند.
یک API، اتصالی بین داده‌های داخل یک سازمان و خارج از آن برقرار می‌کند.
به‌عنوان مثال یک مدیر IT می‌تواند به‌طور یکپارچه و از هر نقطه‌ای حجم بزرگی از داده‌ها را وارد یا استخراج نماید (امکان اتصال و دسترسی برنامه‌های خارج از سازمان به منابع موجود در سازمان به‌صورتی امن، قابل‌کنترل و پیگیری). APIها معمولاً قابل‌مشاهده نبوده و دارای واسط کاربری نیستند و کاربر نهایی به‌طور مستقیم به آنها متصل نمی‌شود؛ بلکه APIها درون سیستم‌ها قرار دارند و توسط نرم‌افزارها فراخوانی می‌شوند و برای ارتباط بین ماشین‌ها و یکپارچه‌سازی دو یا چند سیستم بکار می‌روند. در حقیقت برنامه نویسان و توسعه‌دهندگان برنامه‌ها تنها کسانی هستند که مستقیماً با APIها در ارتباط می‌باشند.
مزایای و ارزش‌های API
برخی از ارزش‌های قابل ارائه توسط APIها را به شرح زیر برشمرد:
داده‌ها و اطلاعات یکی از دارایی‌های مهم سازمان‌ها و خصوصاً دولت‌ها به شمار می‌روند. با کمک APIها می‌توان امکان دسترسی همگان به این داده‌ها را به روشی استاندارد فراهم نمود که خود سبب افزایش شفافیت و گستره کاربرد داده‌های دولتی خواهد شد.
با وجود API محتوا یک بار تولید شده و بارها انتشار خواهد یافت. بنابراین از یک سو، استفاده متمرکز و کارا از داده‌ها رخ خواهد داد و از سوی دیگر طیف وسیعی از مخاطبان می‌توانند از آنها استفاده نمایند.
با به اشتراک گذاری داده‌ها و کارکردها از طریق API، امکان ساخت سرویس‌های ارزش افزوده و ارائه آنها با انواع روش‌های عرضه نظیر برنامه‌های کاربری موبایل، وب و … و این خود موجب گسترش کسب و کارها می‌گردد.
APIها در بهترین حالت می‌توانند یک مدل کسب و کار باشند و در کمترین حالت یک کانال توزیع سرویس هستند که سبب افزایش دامنه مشتریان، ارتباط با همکاران و تعامل با شرکا خواهند شد.
به واسطه API یکپارچه‌سازی سیستم‌ها به روشی استاندارد و یکسان رخ خواهد داد و توسعه ماژولار سیستم اصلی یا زیرسیستم‌ها با قابلیت استفاده مجدد تسهیل می‌گردد.
با بکارگیری API زمان رسیدن محصول و ایده به بازار به میزان قابل توجهی کاهش خواهد یافت.
رشد و توسعه API
طبق پیش بینی موسسه گارتنر ۵۰ درصد تعاملات B2B در سال ۲۰۱۷ از طریق web APIها صورت خواهد گرفت. یکی از مراجع اصلی در حوزه انتشار APIها سایت Programmableweb می‌باشد که طبق آمار ارائه شده از طریق این سایت رشد انتشار API ها از سال ۲۰۱۰ به میزان چشمگیری افزایش یافته است. نمودار ارائه شده از طرف این سایت به شرح زیر می‌باشد:
تصویر بالا نرخ رشد APIرا در سایت Programmableweb نشان می دهد .
کاربرد API در سایر تکنولوژی‌ها
در حال حاضر یکی از مولفه‌های اصلی و ضروری در حیطه‌های نوظهور و آینده‌دار فناوری نظیر: اینترنت اشیا، رایانش ابری، داده‌های حجیم، سرویس‌ها و برنامه‌های کاربردی موبایل، APIها و پلتفرم‌های مدیریت API می‌باشند. پیش‌بینی می‌شود که در سال ۲۰۲۰ بیش از ۲۴ بیلیون وسیله اعم از اتومبیل‌ها، تلفن‌های هوشمند، تبلت‌ها، حسگرها و…. به اینترنت و به یکدیگر وصل خواهند شد. این ارتباط جز از طریق API و به طور خاص REST API امکان پذیر نخواهد بود. با توجه به حجم و مقیاس تجهیزات و وسایل از یک سو و گستردگی و تنوع تجهیزات از سوی دیگر، اهمیت زیرساخت مدیریت API به وضوح قابل توجه خواهد بود.
برای اتصال کسب‌وکارهای سطح بالا (در هر کدام از حیطه‌ها و فناوری‌های مطرح که باشند) و سرویس‌های پایه که از طریق APIها عرضه می‌شوند، نیاز به تکنولوژی‌های واسطی وجود دارد که بتوانند:
هماهنگی و مدیریت نقاط اتصال،
فرمت‌های پرس‌و‌جو،
اعمال سیاست‌های کلان در حیطه دسترسی و روش‌های ارائه
را انجام دهند. این تکنولوژی‌های واسط APIها، ارزش‌های فوق‌العاده گران‌بهایی جهت:
اتصال منابع داده به خدمات،
گردآوری و تحلیل داده‌های کلان
تضمین کیفیت سرویس به کاربران نهایی
ایجاد نمایند.
در حوزه سرویس‌های رایانش ابری و به طور خاص PaaS، یکی از کلیدی‌ترین مولفه‌ها API می‌باشد. در حال حاضر و در آینده نه چندان دور آن دسته از پلتفرم‌هایی موفق خواهند بود که استراتژی درستی در حیطه APIها و مدیریت آن اتخاذ کرده باشند. در هر پلتفرم مبتنی بر APIها می‌توان انتظار داشت که:
فرایند توسعه و دسترسی به کارکردهای سیستم‌ها تسهیل شود. یعنی به جای اینکه به ازای هر کاربرد، کارکردها و مولفه‌های سیستمی مورد نیاز از ابتدا نوشته شوند، می‌توان از API ها استفاده نمود.
دسترسی به پلتفرم برای کسانی که می‌خواهند سرویس ارزش افزوده تولید کنند، تسریع می‌گردد.
پلتفرم به میزان قابل توجهی توسعه پذیر شده و امکان افزایش قابلیت‌ها به شکلی کارا فراهم می‌شود.
یکپارچه سازی و تبادلات بین مولفه‌های سیستم به خوبی انجام می‌شود.
مدیریت امنیت پلتفرم تسهیل می‌گردد.
از آنجایی که یکی از مهمترین قابلیت‌های سرویس‌های ابری، توسعه پذیری بر حسب تقاضا می‌باشد؛ APIها اصلی‌‌ترین مولفه برای به انجام رساندن این مهم هستند.
در حال حاضر شرکت‌های بزرگی نظیر گوگل، آمازون، مایکروسافت، IBM، Oracle ، HUAWEI، AT&T و… هر یک زیرساخت مدیریت API خود را دارا می‌باشند. شرکت‌های فوق در حیطه کاری خود(گوگل در حیطه داده‌های حجیم یا آمازون در حیطه رایانش ابری) این مولفه را توسعه داده و استفاده می‌کنند. حتی در حال حاضر موقعیت‌های شغلی جدیدی نظیر API Engineer, API Business Development نیز تعریف گردیدده و به طور مثال شرکتی نظیر آمازون بیش از ۶۰۰ موقعیت شغلی در اکوسیستم API را دارا می‌باشد.
در کنار این دست از شرکت‌های بزرگ، برخی از شرکت‌ها به طور خاص API Management را به صورت سرویس بر روی ابر ارائه می‌کنند که در این حیطه می‌توان ۳Scale (شریک تجاری آمازون بوده)، Apigee، WSO2 و… را نام برد. البته برخی از شرکت‌ها نیز صرفاً بر روی پرتال تمرکز کرده و مخزنی از APIها را فراهم نموده‌اند که از این بین می‌توان ProgrammableWeb، Mashape، APIs را نام برد
انواع API
همان طور که پیش‌تر ذکر شد تعاریف مختلفی از APIها ارائه شده است و بر همین اساس انواع مختلفی از APIها وجود دارد. همچنین بر اساس سطح دسترسی، نوع کاربرد و روش استفاده، APIهای مختلفی قابل تعریف می‌باشد. در این بخش دسته‌بندی APIها از منظرهای مختلف شرح داده خواهد شد.
دسته‌بندی API بر اساس سطوح دسترسی کاربران
یکی از مهمترین روش‌های دسته‌بندی APIها از منظر سطح دسترسی می‌باشد. لازم است تمامی انواع مختلف APIها با معماری‌ها و پروتکل‌های مختلف از این منظر دسته بندی شوند. در اکثر APIها سطح دسترسی با استفاده از یک کلید مدیریت می‌شود. سطح تعریف شده برای APIها عبارتند از:
APIهای عمومی: همان طور که از نام این دسته مشخص است، دسترسی به این دسته از APIها برای همگان آزاد خواهد بود. عموماً برای استفاده از APIها، به یک کلید یا توکن نیاز است؛ که در این دست از APIها این کلید در اختیار هر فردی که درخواست نماید قرار داده خواهد شد.
APIهای خصوصی و داخلی: این دسته با هدف کارمندان داخل سازمان و افزایش بهره‌وری آنها و ارتباط هر بهتر و کاراتر سیستم‌های نرم‌افزاری در اختیار توسعه‌دهندگان داخل سازمان است.
APIهای محافظت‌شده: این نوع APIها در اختیار افراد مشخصی و از پیش تعیین شده‌ای قرار می‌گیرند که عموماً شرکای تجاری می‌باشند. هدف این کلاس می‌تواند مشتری نهایی یا کاربران تجاری بوده و با اهداف مختلفی بر پایه داده و نوع تجارت شرکت می‌تواند پیاده‌سازی شود. با توجه به به مخاطب خاص این دسته از APIها (شرکای تجاری) این دسته را به طور مجزا معرفی شده است و گرنه از منظر پیاده‌سازی و فنی، این دسته از APIها می‌تواند به عنوان زیردسته‌ای از APIهای خصوصی نیز قرار گیرد.
از بین انواع APIهای فوق، دو نوع حفاظت شده و خصوصی، دسته‌های رایج‌تری می‌باشند. فیس‌بوک و تویتر دو شرکت بزرگ جهان هستند که عموم افراد آنها را می‌شناسند و APIهای عمومی نیز در اختیار توسعه دهندگان قرار می‌دهند. نکته‌ای که شاید کمتر به نظر برسد این است که این دو شرکت بیشتر از آنچه که توسعه دهندگان خارجی از API عمومی آنها استفاده کنند، خود مصرف کننده‌ی آنها هستند. حجم زیادی از فراخوانی‌های API این دو شرکت به صورت داخلی است که در وبسایتها، برنامه‌های کاربردی موبایل و سایر محصولات آنها کاربرد دارد. در حقیقت APIهای عمومی همانند آن بخش از کوه‌های یخ هستند که دیدنی است و APIهای خصوصی و محافظت شده آن بخش از کوه یخ هستند که در زیرآب قرار دارد و حجم عظیمی از کوه یخ را تشکیل می‌دهند. هر چند ارائه APIها به صورت عمومی ارزش آفرین خواهد بود اما تاثیر APIهای خصوصی به میزان قابل توجهی چشمگیرتر از APIهای عمومی می‌باشد. برای مثال Netflix در ابتدا تعداد قابل توجهی از APIهای خود را باز نمود و آن را در اختیار تمامی توسعه دهندگان قرار داد اما بعد از چندین سال، متوجه شد که بیشترین تعداد درخواست و فراخوانی API توسط کارمندان و شرکای تجاری است و چیزی کمتر از ۰۳/۰ درصد از فراخوانی ها عمومی هستند( طبق تحلیل‌های ارائه شده مجموع فراخوانی های انجام شده به صورت عمومی در طول یازده سال معادل یک روز فراخوانی APIهای خصوصی و محافظت شده است). از همین رو در سال ۲۰۱۴ این شرکت دسترسی‌های عمومی به APIهای خود را به طور کامل از بین برد. لازم به ذکر است این مثال به معنای عدم استفاده از APIهای عمومی نمی‌باشد بلکه این نکته را خاطر نشان می‌نماید که هر چند APIهای عمومی لازم بوده و کاربرد دارند اما مخاطب اصلی APIها سازمان‌ها و شرکای همکار آنها می‌باشند و ضروری است APIها توسط خود سازمان‌ها به کار برده شود زیرا کارایی و بهره‌وری سیستم‌ها را به میزان قابل توجهی افزایش می‌دهد. همچنین همان طور که در ابتدای این فصل نیز ذکر گردید، شرکت‌هایی نظیر تویتر و فیس‌بوک در حال حاضر تعداد قابل توجهی از APIهای عمومی را به همگان ارائه می‌دهند. در نهایت انتخاب استراتژی عمومی یا خصوصی بر اساس رویکردهای تجاری- فنی شرکت خواهد بود و شرکت‌های می‌توانند بر حسب نیاز یکی از این دو رویکرد یا ترکیبی از هر دو را انتخاب نموده و بر اساس بازخورد و نیاز رویکردهای خود را تغییر دهند.
دسته‌بندی APIها بر اساس معماری
به‌طورکلی معماری، تعیین‌کننده یک ساختار از قبل تعریف‌شده در مقیاس بزرگ است. با تقسیم‌بندی APIها ازنظر معماری ساختن API از ابتدا بسیار سریع‌تر انجام می‌گیرد.
APIهای ارائه‌دهنده سرویس وب
یک سرویس وب قسمتی از نرم‌افزار یا یک سیستم است که دسترسی به سرویسش از طریق یک آدرس بر روی شبکه جهانی وب (اینترنت) امکان‌پذیر است. این آدرس به‌عنوان URI یا URL شناخته می‌شود. نکته مهم در اینجا آن است که سرویس‌های وب اطلاعاتشان را به شکلی ارائه دهند که برنامه‌ها بتوانند آن را متوجه شده و تجزیه و تحلیل کنند. انواع روزمره‌ای از APIها توسط سرویس‌های وب استفاده می‌شوند شامل موارد زیر است:
پروتکل RPC
پیام‌های RPC معمولا در سیستم‌های توزیع شده کاربرد دارند. این گونه پیام‌ها بگونه‌ای عمل می‌کنند که یک پروسه یا روتین را در یک فضای آدرس دیگر (ماشین و یا شبکه دیگر) اجرا می‌کنند. این پیام‌ها می‌توانند به دو صورت زیر باشد:
XML: در این نوع فراخوانی ساختار پیغام به صورت XML می باشد و برنامه سرویس دهنده با بررسی این ساختار عملیات مورد نظر را انجام می‌دهد.
JSON: در این نوع فراخوانی ساختار پیغام به صورت JSON می باشد و برنامه سرویس دهنده با بررسی این ساختار عملیات مورد نظر را انجام می دهد.
در این پروتکل هر نوع کار توسط خود درخواست دهنده تعیین می شود و محدودیتی در نوع انتخاب نیست.
پروتکل SOAP
این معماری از استایل و چگونگی نمایش داده‌ها در RPC استفاده می‌کند. این معماری به‌وسیله W3C استانداردسازی شده و به‌طور گسترده‌ای برای سرویس‌های وب استفاده می‌شود. SOAP بیشتر برای یکپارچگی ابزارها درون یک سازمان استفاده می‌شود. SOAPپروتکلی است که متد ارتباطات، ساختار پیام‌رسانی را تعریف می‌کند. داده‌های منتقل‌شده در این متد با فرمت XML هستند.
SOAP از پروتکل‌های مختلفی مانند HTTP، SMTP، TCP یا JMS پشتیبانی می‌کند و می‌تواند بر روی این پروتکل‌های داده‌ها را تخصیص دهد. یک پیام SOAP مانند نامه‌ای است که شامل ۳ قسمت است: Envelope یا پوشش که مشخص می کند پیغام از نوع SOAP است، header که دارای اطلاعات در مورد پیام و body که شامل درخواست می‌باشد و با فرمت XML ارائه می‌شود.
یک سرویس SOAP تعریف واسط سرویس است به‌صورتی که مستند بوده و قابل فهم برای ماشین است. این مستند با استفاده از زبان توصیف سرویس‌های وب (WSDL) نوشته می‌شود.
REST
REST یک معماری سرویس بر روی پروتکل HTTP است. ساختار REST اولین بار در رساله دکترای Roy Fielding که یکی از نویسندگان پروتکل HTTP می‌باشد مطرح شد. در حقیقت Fielding پیشنهادی برای ارتباط داخلی سیستم‌ها از طریق HTTP مطرح نمود و متعاقبا REST به عنوان یک معماری وب سرویس مبتنی بر HTTPمتولد گردید. Fielding با با بکارگیری بلاک‌ها و مولفه‌های سازنده HTTP، حوزه namespace (فضای نام) را به مجموعه‌ای از منابع مبتنی بر یک الگوی URI یکتا تقسیم نمود و با بکارگیری توابع استاندارد HTTP (GET, POST, PUT, DELETE) عملیات‌های متناظر با هر منبع را پیاده نمود.
در این روش با استفاده از header نوع فرایند API مشخص می‌شود و محتویات پیام را می‌توان با فرمت دلخواه همراه بسته ارسال نمود. همچنین می‌توان پارامترهای پیام را از طریق URI به عنوان یک منبع معرفی و ارسال کرد. در این معماری عملیات قابل تعریف به ۴ عمل create, update, read, delete CRUD)) محدود شده که هر یک به ترتیب به متدهای POST, PUT&PATCH, GET, DELETE در HTTP نگاشت می‌شوند.
در یک سرویس REST که به‌درستی تعریف شده باشد، هیچ اتصالی میان کلاینت استافده از API و معماری زمینه آن سرویس(سرور) وجود ندارد. این مورد به‌عنوان یکی از مزایای REST نسبت به RPC مطرح می‌شود. سرویس‌های سمت کلاینت سرویس‌هایی را فراخوانی می‌کنند که به نام متدها و ساختار داده سرویس‌های پشت REST (سمت سرور) وابسته نیستند و در واقع از این طریق کلاینت نیازی به شناسایی کامل سرویس اصلی که دریافت می‌کند ندارد و فقط از طریق واسط REST که منطق چگونگی استفاده از منابع و توابع در دسترس را مطرح می‌کند با سرویس در ارتباط خواهد بود. ساختار داده در پیام از ساختار داده سرویس مستقل است و پیام‌های دریافت و ارسال‌شده حاوی نمودی از داده هستند. همچنین تغییرات در سرویس پشت REST نباید برای کلاینت مشکلی ایجاد کند.
مقایسه پروتکل ها
در این بخش پروتکل‌های فوق از لحاظ کارایی، انعطاف پذیری و ماجولاریتی بررسی می‌شوند. از منظر کارایی، معماریREST از ۲ پروتکل RPC و SOAP کارایی بالاتری دارد زیرا در این معماری، نوع فرایند از طریقheader مشخص می‌شود و در اصل در این معماری، چارچوب طوری تعیین شده است که فرایند های پیچیده به فرایندهای کوچک تر شکسته شوند و در نتیجه کارایی افزایش می‌یابد.
از منظر انعطاف‌پذیری RPC وSOAP از REST بهتر می‌باشد زیرا هر نوع فرایندی را بدون محدودیت می‌توان پیاده نمود. در حقیقت موازنه‌ای مابین کارایی و انعطاف‌پذیری وجود دارد با افزایش هر چه بیشتر انعطاف پذیری و شخصی سازی متدها و پیاده‌سازی بر حسب تمایل کارایی کاهش خواهد یافت. بنابراین نیاز است تا ما بین کارایی و انعطاف پذیری موازنه‌ای برقرار گردد تا نتیجه مناسب به‌دست آید.
از منظر ماجولاریتی SOAP از ۲ پروتکل دیگر بهتر است زیرا قسمت های مختلف یک پیغام را از هم جدا و تفکیک کرده است.
APIهای بر پایه کتابخانه
به‌منظور استفاده از این نوع API یک برنامه به کتابخانه‌ای از کدها ارجاع داده‌شده و یا آن کتابخانه از توابع باینری به برنامه وارد می‌شود تا با استفاده از توابع و روتین‌های آن کتابخانه بتوان اعمال یا تبادل اطلاعات را انجام داد.
APIهای javascript مثال خوبی برای این دسته هستند. به‌عنوان‌مثال با استفاده از تگ <Script> می‌توان کتابخانه javascript را از آدرسی فراخوانی و هر جا به کتابخانه آن نیاز بود از آن استفاده نمود.
TWIN یک API و پروتکل ارتباطی برای اسکنرها و دوربین‌هاست. این API به‌منظور اتصال آسان برنامه‌ها به دستگاه‌هایی مانند اسکنرها، دوربین‌ها و پرینترها نوشته‌شده است.
APIهای بر پایه کلاس
این دسته که نوع خاصی از APIهای بر پایه کتابخانه هستند، در واقع کلاس‌های مرتب‌شده‌ای هستند که در زبان‌های شی‌ءگرا استفاده می‌شوند. زبان برنامه‌نویسی جاوا مثال خوبی از زبان شی‌ءگرایی که از APIهای بر پایه کلاس استفاده می‌کند، می‌باشد. APIجاوا مجموعه‌ای از کلاس‌هاست که به همراه محیط توسعه جاوا ارائه می‌شود که برای برنامه‌نویسی در جاوا ضروری هستند. زبان جاوا شامل دستورات و انواع داده ساده است. کلاس‌های جاوا بقیه موارد مورد نیاز برنامه‌نویسی مانند رشته‌ها، آرایه‌ها، اشیا شناخته‌شده و بسیاری از موارد دیگر را فراهم می‌سازد.
محیط برنامه‌نویسی اندروید و Google Studio مثال‌های دیگر این نوع از APIها در زبان جاوا هستند.
APIهای سنتی
انواع سنتی واسط برنامه‌های شامل واسطهای سیستم‌های عامل، APIهای سخت‌افزاری، پروتکل‌های ارتباطی، صف پیام ، پروتکل‌های دسترسی به اشیاء از راه دور و دیگر موارد هستند.
توابع یا روتین‌ها در یک سیستم‌عامل
دسترسی به سیستم فایل، پرینت کردن مستندات، نمایش محتویات یک فایل بر روی یک کنسول، پیام‌های خطا، دسترسی به واسط کاربر که توسط سیستم‌عامل فراهم می‌شوند. از جمله مواردی هستند که می‌تواند در این دسته قرار دارد.
APIهای سخت‌افزاری
این نوع APIها برای دسترسی به قسمت‌های سخت‌افزاری قابل آدرسی دهی بر روی یک دستگاه هستند مانند شتاب‌دهنده‌های ویدئویی، درایور دیسک ، باس‌های درگاه PCI.
APIهای دسترسی به اشیا از راه دور
این کلاس از APIها از پروتکل‌های دسترسی از راه دور مانند CORBA استفاده می‌کنند و همانند یک API عمل می‌کنند ولی با این تفاوت که یک پروکسی محلی برای دسترسی به اشیا و اتصال آنها به اشیا محلی تعریف می‌کند. یک مثال از این نوع .NET Remoting می‌باشد.
مقایسه و جمع‌بندی
امروزه معماری‌های بر پایه سرویس وب و برپایه کتابخانه بیشترین کاربرد و استفاده را دارند. این دو معماری به دلیل کاربرد بیشتر و سهولت در استفاده توسط توسعه‌دهندگان مورد استقبال بالاتری قرار گرفته‌اند. در میان سرویس‌های وب پروتکل HTTP پراستفاده‌ترین پروتکل برای سرویس‌های وب می‌باشد. این پروتکل به‌راحتی می‌تواند به پورتهای مختلف پروکسی شده و توسط اکثر دیوارهای آتش قبول است. دو پروتکل SOAP و REST نسبت به هم مزایا و معایب خود رادارند که در ادامه به شرح این موارد می‌پردازیم. مزایای پروتکل REST عبارتند از:
استفاده از استاندارهای HTTP
سادگی و راحتی کاربرد
مستندات ساده و قابل‌فهم
برقراری ارتباطات به‌صورت Stateless (یعنی تغییر حالت سرور تاثیری در پاسخگویی به کلاینت نخواهد داشت.)
امکان ذخیره سازی پاسخ متدها: در صورتی که داده‌ها در سمت سرویس وب تغییر داده نشوند و پویا نباشند، این ویژگی می‌تواند بر روی کارایی و سرعت پاسخ‌دهی تاثیر بسزایی داشته باشد.
سازگاری با وبسایتها و برنامه های کاربری مختلف: برای استفاده از سرویس‌های REST نیازی به کد نویسی از ابتدای برنامه نیست و فقط توابع مورد نظر اضافه خواهند شد.
در مقابل این مزایا، معایب REST عبارتند از:
این پروتکل و متدهای مرتبط با آن ممکن است برای انسان معمولی و قابل استنتاج باشد ولی برای ماشین براحتی قابل پردازش نیست و نیاز به تعریف متدهایی برای شناسایی لیستها، تواناییها و الگوهای هرسرویس وب به‌طور جداگانه است. که برای حل این مشکل تا حدودی از زبان‌های توصیف استفاده می‌شود.
نیاز به تعریف نقاط دسترسی و آدرسهای مختلف برای انجام متدهای مختلف
در مقابل پروتکل SOAP قرار دارد که نسبت به پروتکل REST با هدف ارائه منطق برنامه و نه داده برنامه به‌عنوان سرویس ارائه شده است. SOAP بر روی دسترسی به نام عملگرها از طریق واسطهای مختلف متمرکز شده است. به عنوان مثال متد
getUser(User);
یک عملگر REST است که از طریق آن منابع (داده) در دسترس خواهند بود و متد
switchCategory(User, OldCategory, NewCategory);
یک عملگر SOAP است که در آن عملیاتی (در اینجا تغییر نام دسته) صورت گرفته است.
در SOAP می‌توان به‌طور SateFull با سرور در ارتباط بود در صورتی که REST به‌صورت Stateless عمل می‌کند. SOAP بگونه‌ای طراحی شده است که مدیریت اتصالات بین سرور و کلاینت را خود انجام می‌دهد.
SOAP از متدهای امنیتی قوی تر از REST مانند WS-Addressing پشتیبانی می‌کند.
میزان محبوبیت دو پروتکل
در این قسمت در مورد تعریف APIها و کاربرد اصلی آنها و مفهومشان صحبت شد. ۳ کلاس مختلف که APIها می‌توانند تعریف شوند معرفی معماری‌های مختلفی که برای APIها می‌تواند متصور شد، معرفی شدند. معماری‌های مختلف از دسته‌های APIهای تحت وب، APIهلای کتابخانه‌ای، APIهای سنتی تشکیل می‌شوند که در مورد هرکدام صحبت شد. مشخص شد که بر بستر اینترنت APIهای تحت وب و کتابخانه ای پراستفاده‌ترین نوع بوده و به‌طور خاص APIهای REST و SOAP بیشترین کاربرد را در این دسته‌دارند.
مطالعه بیشتر