برنامه نویسی 27515 بازدید

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

API ازنظر فنی اختصاری برای عبارت «رابط برنامه‌نویسی اپلیکیشن» (Application Programming Interface) محسوب می‌شود. در برخی موارد شرکت‌های بسیار بزرگ API-هایی برای مشتریان خود و یا کاربردهای داخلی‌شان ساخته‌اند. اما اگر بخواهیم API را به زبان کاملاً ساده توضیح دهیم، معنی بسیار گسترده‌تری از آن چه در حوزه‌های نرم‌افزار یا کسب‌وکار استفاده می‌شود، خواهد داشت. ابتدا کمی به عقب‌تر باز می‌گردیم و به بررسی عملکرد خود وب می‌پردازیم.

WWW و سرورهای ریموت

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

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

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

API -ها روشی برای عرضه خدمات به مشتریان هستند

شاید شنیده باشید که برخی شرکت‌ها API-هایشان را به صورت محصول بسته‌بندی می‌کنند. برای نمونه Weather Underground دسترسی به API داده‌های آب‌وهوا را به فروش می‌رساند.

سناریوی نمونه

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

کاربرد API

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

به طور جایگزین مرورگر شما می‌تواند یک درخواست API را به صورت مستقیم به سرور گوگل ارسال کند و بدین ترتیب سرور شما را دور بزند.

API تقویم گوگل چه تفاوتی با API هر سرور ریموت دیگری دارد؟

از لحاظ فنی تنها تفاوت در قالب درخواست و پاسخ است. مرورگر شما برای رندر کردن یک صفحه انتظار دارد پاسخی که دریافت می‌کند به زبان HTML باشد که شامل کدهای زیادی است؛ در حالی که فراخوانی API تقویم گوگل تنها داده بازمی‌گرداند که احتمالاً در قالب JSON است.

  • اگر سرور وب‌سایت شما درخواست API را صورت داده باشد، در این صورت سرور وب‌سایت شما کلاینت است.
  • از منظر کاربر وب‌سایت، API-ها امکان تکمیل کارها بدون نیاز به ترک وب‌سایت را می‌دهند.
  • اغلب وب‌سایت‌های مدرن دست‌کم مصرف‌کننده برخی API ها شخص ثالث هستند.

برای بسیاری از مشکلات راه‌حل‌های مبتنی بر API آماده‌ای وجود دارد که به شکل یک کتابخانه یا سرویس هستند. بدین ترتیب در اغلب موارد استفاده از چنین API های آماده‌ای بسیار پایدارتر است.

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

برای این که این بحث را جمع‌بندی بکنیم، باید اشاره کنیم که وقتی یک شرکت API خود را به مشتریان ارائه می‌کند، بدان معنی است که آن‌ها مجموعه‌ای از URL-های اختصاصی ساخته‌اند که پاسخ‌های داده‌ای خاصی را بازگشت می‌دهند، یعنی پاسخ‌هایی که شامل هیچ نوع «سربار ارائه‌ای» (Presentational Overhead) نیستند و مانند یک وب‌سایت منتظر یک رابط گرافیکی نیستیم.

در اکثر موارد می‌توان این درخواست‌ها را با مرورگر ارائه کرد، چون انتقال واقعی HTTP به صورت متنی انجام می‌گیرد و مرورگر در این موارد برای نمایش پاسخ بسیار مناسب است.

برای نمونه می‌توانید به طور مستقیم و بدون نیاز به هیچ توکن دسترسی به API گیت‌هاب دسترسی داشته باشید. کد زیر پاسخ JSON است که هنگام بازدید از مسیر API کاربر گیت‌هاب (+) در مرورگر دریافت می‌کنید:

{
  "login": "petrgazarov",
  "id": 5581195,
  "avatar_url": "https://avatars.githubusercontent.com/u/5581195?v=3",
  "gravatar_id": "",
  "url": "https://api.github.com/users/petrgazarov",
  "html_url": "https://github.com/petrgazarov",
  "followers_url": "https://api.github.com/users/petrgazarov/followers",
  "following_url": "https://api.github.com/users/petrgazarov/following{/other_user}",
  "gists_url": "https://api.github.com/users/petrgazarov/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/petrgazarov/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/petrgazarov/subscriptions",
  "organizations_url": "https://api.github.com/users/petrgazarov/orgs",
  "repos_url": "https://api.github.com/users/petrgazarov/repos",
  "events_url": "https://api.github.com/users/petrgazarov/events{/privacy}",
  "received_events_url": "https://api.github.com/users/petrgazarov/received_events",
  "type": "User",
  "site_admin": false,
  "name": "Petr Gazarov",
  "company": "PolicyGenius",
  "blog": "http://petrgazarov.com/",
  "location": "NYC",
  "email": "petrgazarov@gmail.com",
  "hireable": null,
  "bio": null,
  "public_repos": 23,
  "public_gists": 0,
  "followers": 7,
  "following": 14,
  "created_at": "2013-10-01T00:33:23Z",
  "updated_at": "2016-08-02T05:44:01Z"
}

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

A اختصاری برای Application است

در انتها برخی نمونه‌های مختلف از API ها را بررسی می‌کنیم. گفتنی است که Application می‌تواند به معانی مختلف باشد. برخی از این مفاهیم در چارچوب API در ادامه معرفی شده‌اند:

  1. یک قطعه از نرم‌افزار با کارکرد متمایز
  2. کل سرور، کل اپلیکیشن، یا تنها بخش کوچکی از یک اپلیکیشن

اساساً هر بخش از نرم‌افزار که بتوان از محیطش جدا کرد را می‌توان یک «A» برای API تصور کرد و در اغلب موارد نیز نوعی API دارند.

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

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

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

بر اساس رای 47 نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.

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

3 نظر در “API چیست؟ — به زبان ساده

  • سلام
    یک شرکت که ظاهرا یک افزونه تجاری رو داره و میفروشه از من خواسته که یک سری کد رو به اونها بفروشم.
    البته کدهای من رو در قالب یه افزونه میخوان و قطعا بعد دریافت اون رو باز و فقط کدها رو برداشت نی کنن.
    سوال من اینه که در این مواقع چه مبلغی رو باید دریافت کرد چون صرف فروش یه افزونه سیصد تمن بی انصافیه.
    متشکر از سایت خوبتون.

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *