Rayan
/ دسته ها: فناوری اطلاعات

API - قسمت دوم

معماری REST

معماری REST با وضع کردن محدودیت برای تراکنش های کامپوننت به جای تعیین پیش فرض توپولوژی مشخص برای کامپوننت ها شکل می یابد. این کار جزییات کاربردی و syntax های پروتکل را ندیده میگیرد و موارد زیر را میسر میسازد:

-          مقیاس پذیری تراکنش های کامپوننتها

-          فعالیت مستقل کامپوننتها

-          اجازه به کامپوننتهای میانی در راستای کاهش تاخیر ارتباطی

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

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

هدف اصلی REST این است که با کاهش تاخیر شبکه و استفاده از کش و کاهش بار سرور با حذف کردن state های دوره ایی به توسعه hypermedia در مقیاس اینترنت کمک کند. بنابر این یک user agent باید ابتدا state خود را ذخیره کند تا امکان تغییر مستقیم در آنرا داشته باشد.

وب سرویس rest در حال حاضر دارای پروتکل های استاندارد شده است و برای استفاده از آن لازم است تنها ساختار داده و URI سرویسهای درگیر دانسته شود.

ما می توانیم از هر زبان اسکریپت با ساپورتی مناسب از http برای دستیابی به آن استفاده کنیم. حتی پردازش کننده های مدرن XSL می توانند برای ترکیب وب سرویس های موجود مورد استفاده قرار گیرند.

 

Soap در برابر Rest

از آنجایی که soap و rest کاملا در روشهای خود تفاوت دارند برای مقایسه rest و simple object access protocol (soap) بهتر است تا روش های متفاوت برای تعریف پروتوکل های جدید را آزمایش کنیم.

 

 انواع روشهای پروتوکل ها:

روش پروتوکلهای تنظیم شونده این روش شامل راهنمایی است که از نظر دامنه مشکلات مورد مطالعه یک تیم قرار می گیرد و یک پروتوکل را درون برخی پروتوکل های موجود توسعه میدهد. به عنوان مثال میتوان ازhttp  یا smtp که بر tcp بنا شده اند نام برد. اگر پروتوکل استاندارد شده نباشد این استراتژی اجازه استفاده مجدد بین پروتکل های متفاوت را نخواهد داد بلکه تنها داده های بسته بندی شده حائز این مجوز خواهند بود. روش  تنظیم شونده برای انجام پذیری صحیح بسیار دشوار و پیچیده است و بنابراین تنها مناسب برای متخصصین است.

روشهای فریم ورک:

روش فریم ورک بر اساس این ایده است که ما دائما نیاز داریم تا پروتکل های جدید ایجاد کنیم پس بهتر به نظر می رسد که یک فریم ورک برای انجام این کاری ایجاد کنیم. Soap به همراه web-service description language (WSDL) یک چنین فریم ورکی را تولید می کنند. این به ما اجازه دستیابی به موارد ذیل را خواهد داد.

-          Type-system عمومی

-          Service description language عمومی

-          Addressing model عمومی

-          Security عمومی

روش فریم ورک به پروتکل های قابل تنظیم مزایای بسیاری دارد چرا که:

-          نیاز به دانش کمتری دارد.

-          امکان توسعه زیرساخت های عمومی در آن وجود دارد.

-          بار ورود اطلاعات کمتری برای تولید کنندگان انتفاعی دارد.

-          امکان پشتیبانی از ابزارها در آن وجود دارد.

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

SOAP/WSDL معمول ترین فریم ورک است. در 1998 و توسط مایکروسافت این تکنولوژی شروع به کار کرد و یک مجموعه از انواع ابتدایی و ساختارهایی که میتوانستند از طریق وب تونل گذاری شوند را معرفی نمود. اهداف SOAP این بود که DCOM را در گستره وب فعال کنند بدون این که درگیر فایروال ها شوند به عبارت دیگر SOAP طراحی شده بود تا یک میان افزار RPC باشد و بتواند از پروتکل های وب استفاده کند. IBM با ایجاد SOAP 1.1 در این تلاش ها وارد شد که در W3C مورد پذیرش واقع گردید. مشخصات آن تا آن تاریخ کمتر سازماندهی شده بود و هیچ امکان اضافه جدیدی به آن اضافه نشده بود. اما W3C ، SOAP را در اختیار گرفت و SOAP 1.2 را در اواسط 2003 انتشار داد.

SOAP به تنهایی عملگری در سطح اپلیکیشن ارائه نمی کند مگر آنکه دو طرف پذیرفته باشند که چه گونه از SOAP  استفاده خواهند کرد. یک تعریف این است که SOAP به ما اجاز می دهد خودمان عمل ها (افعال) را روی اشیا (اسمها) تعیین کنیم.

روش پروتکل های افقی

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

روش افقی در عصر کامپیوتر بسیار عمومی است. پروتکل های افقی اغلب عملگر ها را به عنوان یک CRUD (Create, Retrieve, Update and Delete) تعیین می کنند. فایل سیستم های SQL و HTTP به الگوهای CRUD واکنش نشان میدهند. SQL با INSERT, SELECT, UPDATE,DELETE و HTTP با PUT,GET,POST,DELETE که عملگرهای عمومی روی سرویسهای قابل ترجمه هستند.

استاندارد کردن

پروتکلهای در سطح اپلیکیشن می توانند به سادگی سه مفهوم را استاندارد کنند:

-          Addressing

-          Methods

-          Message

 

Addressing

وب سرویس REST از URI به عنوان تعیین کننده منابع عمومی استفاده می کند و این کار اجازه تغییرات کلی را به سیستم می دهد.

در مقابل SOAP شمای آدرس عمومی ندارد، استفاده از URI در آن امکان پذیر است، اما نیاز به این دارد که تولید کننده از آن پشتیبانی کند. برای پشتیبانی از آدرس دهی URI یک مرحله اضافه تر لازم است که همان کانورت ENDPOINT ها به URI است. برای این کار لازم است تا تولید کنندگان سرور به صورت dynamic مجوز فعالیت یک endpoint با یک URI را داده باشند.

به بیان ساده تر جعبه ابزار SOAP آدرس دهی پیچیده از یک سرویس لازم را ارائه می دهد.

Methods

وب سرویسهای REST از HTTP استفاده میکنند و مجموعه استاندارد خود از متد ها مانند (PUT, GET, POST.DELETE) دارند. هر کامپوننت قادر به HTTP میتواند با وب سرویس های  REST ارتباط برقرار کند و پس از آن نیاز به برقراری توافق دیگری نمیباشد.

SOAP به زبان جداگانه (WSDL) نیاز دارد تا متدهایی که خدمات پیش نهاد می دهند را شرح دهد.

 

Messages

نه REST نه SOAP  پیغام های خود را استاندارد نمی کنند. این ممکن است کاری بی هدف باشد چراکه نیازها دائما تغییر می کنند. پس بهترین کاری که میتوانیم انجام دهیم این است که پیغام ها را به ساده ترین شکلی که میتوان با آن کنار آمد تبدیل کنیم آنهم با تغییر دادن Payload ها. XML و استانداردهای همکار آن وظیفه تعریف Payload ها را ساده میکنند.

 

REST وظیفه استاندارد سازی addressing و method ها را به خوبی انجام می دهد تا تولید کنندگان بتوانند روی payload پیغام ها تمرکز کنند. Soap در مقابل نیاز دارد که ما برای آن آدرس دهی کنیم و متد تعریف کنیم آنهم بسیار قبل از اینکه بتوانیم به payload پیغام ها فکر کنیم.

 

 

مطلب قبلی API - قسمت اول
مطلب بعدی مزایای نرم‌افزارهای ماژولار - بخش نخست
Print
952

نام شما
ایمیل شما
عنوان
پیام خود را وارد کنید ...
x
دی ان ان