سرآغاز

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

شاید نام هایی مثل REST، SOAP، یا RPC را شنیده باشید، اما نمی‌ دانید تفاوتشان چیست یا کدامشان به درد پروژه‌ی شما می‌خورد.

در واقع، همه‌ی این‌ها «API» هستن، فقط در دوره‌ها و برای نیازهای مختلف ساخته شده اند.

در این مقاله، ما سیر تاریخی برجسته ترین سبک‌های طراحی API را بررسی می‌کنیم و چرایی به وجودآمدن هر سبک را توضیح خواهیم داد.

اگر در مورد API  کنجکاو هستید، پیشنهاد میکنم مقاله “API چیست؟” را بخوانید

انواع API  ها از دیدگاه سبک طراحی

۱. RPC (فراخوانی رویه از راه دور):

خط زمانی: دهه‌های ۱۹۸۰ و ۱۹۹۰ (سلف پروتکل‌های وب)

RPC (Remote Procedure Call) یکی از قدیمی‌ترین و بنیادی‌ترین مفاهیم در معماری نرم‌افزار توزیع‌شده است.

 چالشی که موجب پیدایش آن شد:

در ابتدا برنامه‌نویسان نیاز داشتند تا توابع(function) و رویه هایی (methods) را که روی یک کامپیوتر اجرا می‌شدند را، از کامپیوتر یا سیستم عامل دیگری نیز فراخوانی کنند. پس هدف، اجرای یک عمل (Action) از راه دور بود.

 شیوه کار و کاربرد:

در این سبک، تمرکز بر “انجام یک عمل” است، نه مدیریت منابع (Resource Management). به عنوان یک مثال ساده، شما به سرور می‌گویید:

get_user_balance(user_id) یا transfer_funds(from_id, to_id, amount)

اینها توابعی هستند که روی سرور تعریف شده اند(یعنی کد برنامه روی سرور ذخیره است).

البته جزئیات درخواست از آنچه در اینجا بیان شد بیشتر است اما برای آشنایی همینقدر کفایت می کند.

• کاربردها:
  • در سیستم‌های داخلی: برای ارتباط بین سرویس‌های داخلی یک سازمان بزرگ.
  • مدل‌های مدرن (gRPC): در معماری‌های میکروسرویس(Microservices)، RPC‌های مدرن مانند gRPC (توسعه‌یافته توسط گوگل در سال ۲۰۱۵) به دلیل سرعت و کارایی فوق‌العاده، برای ارتباطات داخلی بین سرویس‌ها بسیار محبوب‌اند.

جالب است بدانید گوگل از gRPC به صورت گسترده برای ارتباط سریع بین هزاران میکروسرویس خود در زیرساخت ابری استفاده می‌کند.

۲. SOAP (پروتکل ساده دسترسی به شیء): طلایه‌دار وب سرویس‌ها

خط زمانی: اواخر دهه ۱۹۹۰ و اوایل دهه ۲۰۰۰

SOAP (Simple Object Access Protocol) اولین استاندارد رسمی و جامع برای ساخت “وب سرویس‌ها” بود، زمانی که اینترنت جهانی در حال تبدیل شدن به یک بستر تجاری جدی بود.

چالشی که موجب پیدایش آن شد:

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

 شیوه کار و کاربرد:

SOAP از فرمت XML برای ساختاردهی پیام‌ها استفاده می‌کند و از پروتکل‌های مختلف (معمولاً HTTPS/HTTP) برای انتقال بهره می‌برد. به دلیل تکیه بر استانداردهای سخت‌گیرانه WSDL (برای توصیف سرویس) و WS-Security، بسیار سنگین (Verbose) است.

• مزیت اصلی: امنیت و قابلیت اطمینان بالا، همراه با امکانات داخلی برای مدیریت تراکنش‌ها.
• کاربردها (امروزه اغلب میراثی):
  • امور مالی و بانکی: سیستم‌های که نیاز به سطح بالای امنیتی و یکپارچگی داده (ACID compliance) دارند بنابراین اکثرا از SOAP استفاده می‌کنند و  قابلیت‌های تراکنش و رمزنگاری داخلی آن بهره ببرند.
  • در سیستم‌های دولتی و سلامت: سازمان‌هایی با قوانین سخت‌گیرانه در مورد تبادل داده.

۳. REST : قهرمان دنیای مدرن

خط زمانی: سال ۲۰۰۰ (معرفی) و پس از ۲۰۰۵ (محبوبیت گسترده)

REST (Representational State Transfer) که توسط روی فیلدینگ معرفی شد، انقلابی در طراحی API‌ها ایجاد کرد.

امروزه، RESTful API بدون شک محبوب‌ترین و پراستفاده‌ترین سبک برای ساخت API‌های عمومی وب است.

چالشی که موجب پیدایش آن شد:

نیاز به یک معماری سبُک، مقیاس‌پذیر و آسان برای استفاده که بر اساس ستون فقرات خود اینترنت، یعنی پروتکل HTTP/HTTPS، باشد. SOAP برای اینترنت نوپا و برنامه‌های ساده‌تر بیش از حد دست و پا گیر و کند بود.

 شیوه کار و کاربرد:

REST برخلاف RPC که بر عمل (Action) تمرکز دارد، بر منابع (Resources) تمرکز می‌کند.

هر منبع (مانند یک کاربر، یک محصول یا یک سفارش) یک آدرس منحصر به فرد (URL) دارد و عملیات با استفاده از متدهای استاندارد HTTP انجام می‌شود برای مثال فرمت به این شکل است :

• مزیت اصلی: سادگی، استفاده از زیرساخت موجود HTTP، قابلیت Cache شدن و مقیاس‌پذیری بالا.
• کاربردها (رایج‌ترین انتخاب از بین سبک های API است):
  • سایت‌ها و اپلیکیشن‌های عمومی موبایل: از شبکه‌های اجتماعی گرفته تا سایت‌های تجارت الکترونیک.
  • و هر وب سرویسی که نیاز به تبادل داده بین کلاینت و سرور دارد.

برای مثال : API برنامهX  (توییتر) برای دسترسی به توییت‌ها، API گوگل مپس(google maps) برای اطلاعات موقعیت مکانی و تقریباً تمام APIهای عمومی آمازون (AWS) و مایکروسافت (Azure) از اصول REST پیروی می‌کنند

۴. GraphQL (زبان کوئری گرافی): فراتر از محدودیت‌های REST

خط زمانی: ۲۰۱۲ توسط فیسبوک ایجاد شد و درسال  ۲۰۱۵ انتشار عمومی یافت

GraphQL یک زبان کوئری برای APIها است که به سرعت به یکی از محبوب‌ترین سبک‌های مدرن تبدیل شده است، به‌ویژه در توسعه موبایل و Frontend پیچیده.

چالشی که موجب پیدایش آن شد:

با رشد برنامه‌های موبایل و Single Page Applications (SPA)، REST دارای دو مشکل عمده شد:

1. Over-fetching (دریافت بیش از حد): کلاینت برای یک نیاز کوچک، تمام داده‌های یک منبع را دریافت می‌کرد (مثلاً فقط نام کاربر را می‌خواست اما سرور کل پروفایل را می‌فرستاد).
2. Under-fetching (دریافت ناکافی): برای واکشی داده‌های مرتبط (مثلاً یک محصول و تمام نظرات آن)، کلاینت مجبور بود چندین درخواست (Round-trip) به چندین Endpoint مختلف REST ارسال کند.

شیوه کار و کاربرد:

در GraphQL، کلاینت دقیقاً مشخص می‌کند که چه داده‌هایی را نیاز دارد. سرور فقط آن داده‌های مشخص‌شده را در قالب یک پاسخ واحد (One Trip) برمی‌گرداند.

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

مثال : همانطور که راجع به ایجاد کننده این سبک طراحی گفته شد،  فیسبوک و اینستاگرام از GraphQL برای تأمین داده‌های فید کاربران، به دلیل انعطاف‌پذیری و جلوگیری از Over-fetching، استفاده می‌کنند. همچنین شرکت‌هایی مانند Airbnb و  GitHub،  API‌های اصلی خود را با این سبک ارائه داده‌اند.

“لازم است به این تفاوت مهم توجه کنیم: سبک‌های معماری API (نحوه طراحی ساختار) را نباید با روش‌های ارتباطی Real-Time (نحوه انتقال داده) اشتباه گرفت.”

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

سبک‌های معماری API (Architectural Styles) در مقابل روش‌های ارتباطی(Communication Methods):

لازم است تاکید کنیم که مفاهیمی مانند WebSocket و Webhook در دسته‌بندی سبک‌های معماری که تاکنون بررسی کردیم (مانند REST یا GraphQL) قرار نمی‌گیرند. این تمایز از نظر فنی بسیار حیاتی است.

1. سبک‌های معماری API (Architectural Styles): این‌ها (مانند REST، SOAP، GraphQL و RPC) فلسفه‌ها و قوانین طراحی هستند که تعیین می‌کنند چگونه داده‌ها و عملکردها در طول یک شبکه ساختاردهی و سازماندهی شوند. الگوی اصلی آن‌ها معمولاً مبتنی بر درخواست-پاسخ (Request-Response) است؛ یعنی کلاینت باید برای دریافت داده، درخواست خود را آغاز کند.

2. روش‌های ارتباطی Real-Time: این‌ها (مانند WebSocket و Webhook) مکانیسم‌های فنی و پروتکل‌های مکمل هستند که برای غلبه بر محدودیت‌های الگوهای درخواست-پاسخ و فعال کردن ارتباطات لحظه‌ای (Real-Time) و رویدادمحور به کار می‌روند.

به بیان ساده، WebSocket یک پروتکل ارتباطی برای باز نگه داشتن یک کانال دوطرفه است. Webhook نیز یک الگوی رویدادمحور است که سرور با یک تماس معکوس، کلاینت را از رویدادی مطلع می‌کند. این روش‌ها، ابزارهایی مکمل برای پیاده‌سازی نیازهای Real-Time در کنار سبک‌های معماری اصلی هستند.

 جمع بندی

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

راهنمای انتخاب نهایی شما بر اساس حوزه کاری

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

1. اگر برای اولین بار در حال ساخت یک API عمومی یا یک وب‌سایت ساده هستید:
   • REST. سادگی، استفاده آسان و پشتیبانی گسترده آن را به امن‌ترین گزینه تبدیل می‌کند.
2. اگر برای یک اپلیکیشن موبایل یا Frontend پیچیده که با حجم زیادی از داده کار می‌کند، API می‌سازید:
   • GraphQL. بهینه‌سازی پهنای باند و سرعت بارگذاری داده‌ها، تجربه کاربری بهتری ارائه می‌دهد.
3. اگر در حال کار بر روی معماری میکروسرویس‌ها یا سیستم‌هایی با نیاز به سرعت بسیار بالا هستید:
   •  gRPC. ارتباطات داخلی بین سرویس‌های شما را بهینه‌تر و سریع‌تر می‌کند.

امیدوارم با خوندن این مقاله به پاسخ پرسش هایتان رسیده باشید.

در مقالات آینده به دلایل اهمیت انتخاب سبک طراحی مناسب و امنیت در API خواهیم پرداخت.

[1] : در این مقاله منظور از رویداد شخص ثالث، رویدادی است از طرف منبعی که مشتری یا مخاطب اصلی شما نیستند، ایجاد می‌شود و شما کنترل مستقیم بر آن ندارید. مانند API درگاه بانکی برای فروشگاه دیجی کالا. در این مثال دیجی کالا فروشنده اصلی است و فرد خریدار، مشتری است و درگاه بانکی که عملیات تراکنش را انجام می‌دهد شخص ثالث است.