Layer of Abstraction
(منظور از 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 قابل‌پیش‌بینی است: در واقع، درخواست‌هایی که برای نرم‌افزار «الف» ارسال می‌شوند باید در یک چارچوب خاصی باشند و از همین روی پاسخ به چنین درخواست‌هایی همواره مشخص و قابل‌پیش‌بینی خواهند بود.مطالعه بیشتر