دسته بندی وب سرویس بر اساس معماری
در مطلب قبلی در مورد دسته بندی وب سرویس بر اساس سطوح دسترسی توضیح داده شد در این مطلب در مورد دسته‌بندی 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 از ۲ پروتکل دیگر بهتر است زیرا قسمت های مختلف یک پیغام را از هم جدا و تفکیک کرده است.