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 ها و UI ها این است که با انواع مختلفی از کلاینت ها ارتباط برقرار می کنند.

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

API مرورگر

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

به عنوان مثال، اگر همین الان F12 را تایپ کنید و یک کنسول جاوا اسکریپت را باز کنید، می‌توانید یک برنامه کوچک جاوا اسکریپت را برای تعامل با API مرورگر خود تایپ کنید. اگر کد موجود در فهرست ۱ را در کنسول وارد کنید، خروجی را مشاهده خواهید کرد.

window.onmousemove = function(e){console.log("mouse cursor:", e.clientX, e.clientY)}

توجه داشته باشید که پس از شروع به دیدن خروجی کنسول، می‌توانید این تنظیم را با وارد کردن:

لغو تنظیم کنید.

window.onmousemove = null

نکته این مثال این است که شی پنجره بخشی از API مرورگر است. همچنین، تابع (یا روش) onmousemove عضوی از شی پنجره است. به نوبه خود، بخشی از API شی پنجره است. بنابراین، هنگامی که در کد قرار گرفتید، می توانید ببینید که API ها همه جا هستند. اگر می‌خواهید از عملکرد یک مؤلفه استفاده کنید، می‌توانید از طریق API مؤلفه به آن دسترسی داشته باشید.

APIهای تودرتو

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

بیایید کمی بیشتر در مورد نحوه انجام کار مرورگر فکر کنیم. این به ما کمک می‌کند چند نوع API دیگر را درک کنیم. برای یک چیز، مرورگر چگونه موقعیت ماوس را می داند؟ از طریق یک API در سیستم عامل ثبت می شود. سپس سیستم عامل یک درایور ماوس را بارگیری می کند که یک API استاندارد شده برای ارائه اطلاعات جریانی در مورد آنچه ماوس انجام می دهد ارائه می دهد. (خود درایور، اگر به حفاری ادامه دهید، در نهایت به رابط‌های سخت‌افزاری و نرم‌افزاری سطح پایین متکی است – نوع سوم رابط همراه با UI و API.)

APIها در کتابخانه‌ها، بسته‌ها و ماژول‌ها

کنسول مرورگر یک زمینه تخصصی است که تمام کتابخانه ها توسط محیط زمان اجرا از قبل بارگذاری می شوند. بارگذاری صریح کتابخانه ها توسط برنامه نویس رایج تر است. نحوه بارگذاری بسته به زبان برنامه نویسی متفاوت است، اما هر زمان که import، include یا require را در خروجی خود مشاهده کردید، به این معنی است که برنامه فعلی کشیدن API یک برنامه دیگر.

همه برنامه‌ها به جز بی‌اهمیت‌ترین برنامه‌ها از عبارات و ساختارهای سطح زبان (مانند ifها، حلقه‌ها و عملگرها) تشکیل شده‌اند که در ارتباط با فراخوانی‌های APIهای موجود در بسته‌های دیگر استفاده می‌شوند. به نوبه خود، هر برنامه همچنین یک جزء است که به طور بالقوه می تواند توسط برنامه های دیگر گنجانده شده و مورد استفاده قرار گیرد.

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

APIها در برنامه نویسی شی گرا و تابعی

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

API های راه دور و میکروسرویس ها

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

به طور کلی، می‌توان گفت که APIهای راه دور (که به عنوان سرویس نیز شناخته می‌شوند) به شدت جدا شده‌اند و یک پروتکل استاندارد (HTTP/S روی TCP) ارائه می‌دهند که بدون توجه به کار می‌کند. پشته پیاده سازی پشت آنها.

بیایید یک تعامل سریع با یک API راه دور تنظیم کنیم. دوباره در کنسول جاوا اسکریپت خود، کد را در لیست ۲ وارد کنید.

const fetchData = async () => {
  const rawQuotes = await  fetch('https://the-one-api.dev/v2/quote', {
  headers: {
    'Accept': 'application/json',
    'Authorization': 'Bearer xvi06TocPJvBmrQC4yZv'
  }
})

  const quotes = await rawQuotes.json();
  const quote = quotes.docs[Math.floor(Math.random() *  quotes?.docs?.length)];

  const rawCharacters = await   fetch('https://the-one-api.dev/v2/character?_id=' + quote.character, { headers: headers })
  const characters = await rawCharacters.json();
  const character = characters.docs[0];
  console.log(character.name + " said: " + quote.dialog);
};

fetchData();

اگر این کد را اجرا کنید، یک گزارش کنسول دریافت خواهید کرد، چیزی شبیه به: “Gollum گفت: آنها جوان هستند. آنها مناقصه هستند. آنها خوب هستند. بله، آنها هستند. آن ها را بخور. آن ها را بخور!” اتفاقی که افتاده این است که شما یک برنامه جاوا اسکریپت ایجاد کردید که از API مرورگر (به طور خاص، API واکشی) استفاده می کرد تا یک تماس HTTP علیه سروری که در https://the-one-api.dev. این یک REST API است، به این معنی که از قراردادهای معماری خاصی پیروی می کند.

Microservices و API gateways

یک معماری میکروسرویس اساساً از API های راه دور برای فعالیت هایی استفاده می کند که به طور سنتی توسط API محلی انجام می شد. معماری میکروسرویس یک برنامه کاربردی را به اجزایی که از راه دور در دسترس هستند تجزیه می کند.

مفهوم دروازه API مختص معماری میکروسرویس است. در یک دروازه API، یک نقطه تماس واحد در شبکه برای هماهنگ کردن مسیرها به خدمات خاص تعریف شده است. این امکان مزایای خاصی (مانند احراز هویت و محدود کردن نرخ در بین سرویس‌ها) را فراهم می‌کند و به عنوان نوعی رابط رابط عمل می‌کند.

API های راه دور همه جا هستند

اینترنت اساساً جهانی از APIهای راه دور تعاملی است. هر چیزی که روی یک دستگاه اجرا می شود یک API محلی است. سرورها مجموعه ای از API های محلی هستند که برای ارائه یک API راه دور توطئه می کنند. کلاینت ها مجموعه ای از API های محلی هستند که با هم کار می کنند تا API های راه دور را مصرف کنند. Middleware مجموعه ای از API های محلی است که هم برای ارائه یک API راه دور توطئه می کنند و هم برای مصرف سایر API های راه دور با هم کار می کنند.

API ها و طراحی نرم افزار خوب

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

ایده این است که اجزای نرم افزاری را بنویسیم که همه کارهای مورد نیاز آنها را با کوچکترین نقطه تماس ممکن انجام دهد. به‌عنوان توسعه‌دهنده، ما می‌خواهیم فقط ضروری‌ترین اطلاعات را درباره عملکرد داخلی یک جزء ارائه کنیم. این مفهوم برای همه چیز از یک عملکرد کوچک – که امضای آن یک API کوچک نوشته شده است – تا سرویس های قدرتمند از راه دور اعمال می شود.

جداسازی نگرانی ها

گاهی گفته می شود که یک جزء خوب “جعبه سیاه” است، به این معنی که کامپوننت کار خود را انجام می دهد بدون اینکه نشان دهد چگونه کار انجام شده است. جعبه سیاه نشان دهنده ایده آل جداسازی نگرانی ها است. در مقابل جعبه سفید قرار دارد، جایی که مشتریان برای استفاده از آن باید بدانند در داخل کامپوننت چه اتفاقی می افتد. در سناریوی جعبه سفید، هم دانش و هم پیچیدگی پخش می‌شوند یا به بیرون درز می‌کنند. در حقیقت، همه اجزا جعبه های خاکستری هستند. به عنوان توسعه دهندگان نرم افزار، ما سعی می کنیم تا حد امکان آنها را خاکستری تیره کنیم.

APIهای خوب برعکس کد اسپاگتی هستند. در کد اسپاگتی، دنبال کردن جریان اجرا و وابستگی بسیار سخت است، که حفظ و اشکال زدایی کد را سخت می کند. (به این دلیل است که چرا GOTO مضر تلقی می شود.)

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

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

تمرکز پیچیدگی در مؤلفه‌ها و ساده کردن رابط‌ها و پروتکل‌های آنها تا حد امکان مدیریت سیستم‌های نرم‌افزاری ما را بسیار آسان‌تر می‌کند.

API ها و رابط های صریح

زبان‌های برنامه‌نویسی مانند Java، Python و C++ دارای ساختار واسط واضح هستند که زبان را ارائه می‌کند. پشتیبانی سطح از API ها رابط یک API را بدون هیچ جزئیات پیاده سازی تعریف می کند، سپس یک یا چند کلاس مشخص را می توان پیاده سازی کرد. همه پیاده‌کننده‌ها باید رابط را رعایت کنند، اما می‌توانند در نحوه دستیابی به عملکرد متفاوت باشند.

APIهای خوب نرم افزارهای خوبی را می سازند

APIها برای طراحی خوب نرم‌افزار ضروری هستند و طیفی از تجسم‌ها را در لایه‌های مختلف نرم‌افزار ما فرض می‌کنند. هنگامی که در حال نوشتن نرم افزار هستید، بسیار ارزشمند است که به کدی که می نویسید به عنوان یک جزء فکر کنید که به طور بالقوه قابل استفاده مجدد در سیستم های دیگر است. ویژگی های API جزء خود را در نظر بگیرید. اگر این کار را انجام دهید، احتمالاً روی مجموعه‌ای از عملکردهای محدود تمرکز خواهید کرد و به نحوه تعامل سطح API با سایر مؤلفه‌ها فکر خواهید کرد. به تفکیک نگرانی‌ها فکر کنید و سعی کنید فقط به اندازه‌ای که به شدت مورد نیاز است، اطلاعات مربوط به مؤلفه خود را در معرض دید قرار دهید.

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