کاربرد سبک معماری REST در طراحی سامانه‌های وب سازمانی

مقدمه

در واقع REST یک پروتکل مشخص نیست،‌ بلکه یک سبک معماری است که کاربرد آن در معماری وب باعث شهرت اخیر آن شده است. این سبک در سال ۲۰۰۰ توسط Roy Feilding در پایان‌نامه‌ی دکترایش معرفی شد، اما تا سال‌ها استفاده از رواج نداشت. وب‌سرویس‌هایی که مطابق با این سبک معماری طراحی می‌شوند اصطلاحاً RESTful نامیده می‌شوند.

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

1. سرور و کلاینت

یک رابط[۱] یکپارچه میان کلاینت‌‌ها و سرور وجود دارد. این جدایی باعث می‌شود که مثلاً کلاینت‌ها دغدغه‌ی نگه‌داری داده‌ها را نداشته باشند و این مسئله کاملاً در حوزه‌ی سرور باقی می‌ماند. از طرف دیگر سرور هم هیچ دغدغه‌ی در مورد حالت[۲] کلاینت نباید داشته باشد. بدین ترتیب هم کلاینت‌ها ترابرپذیرتر[۳] می‌شوند و هم سرورها ساده‌تر و مقیاس‌پذیر تر می‌شوند. سرورها و کلاینت‌ها می‌توانند بازنویسی شوند و یا به صورت مستقل توسعه داده شوند به شرط اینکه رابط میان آن‌ها تغییری نکند (.

2. بدون حالت

سرورهای REST باید بدون حالت[۴] باشند، به عبارت دیگر با هر بار فراخوانی سرویس، تمام اطلاعات لازم برای اجرای آن سرویس باید فرستاده شود و ایجاد رویه‌های فراخوانی چندمرحله‌ای (که با نگه‌داری حالت کلاینت همراه هستند) مجاز نیست. البته این امکان وجود دارد که حالت کلاینت توسط سرویس نگه‌داری نشود و به مولفه‌ای پایا همچون پایگاه داده منتقل شود.

3. رابط یکپارچه

یکپارچه بودن رابط‌ها یکی از قواعد اساسی هر سرویس طراحی شده با سبک REST است. یکپارچه بودن سادگی و Decoupling در معماری ایجاد می‌کند. این قاعده شامل موارد زیر است:

1. شناسایی منابع: منابع به صورت مستقل قابل آدرس‌دهی باشند. منابع می‌توانند نمایش‌های مختلفی داشته باشند که از طریق سرویس قابل دسترسی هستند.
2. امکان تغییر منابع: کلاینتی که آدرس یک منبع و یک نمایش از آن را دارد، سرویس‌هایی برای تغییر یا پاک کردن آن منبع را دارد. البته ممکن است دسترسی لازم را نداشته باشد.
3. خود توصیف‌گری پاسخ‌ها: پاسخ سرویس‌ها باید اطلاعات کافی جهت پردازش پاسخ را دارا باشد، مثلاً قالب پاسخ که می‌تواند چیزی شبیه MIME type باشد و مشخصات Caching پاسخ.
4. تعیین وضعیت کلاینت با Hypermedia‌[۵]: کلاینت‌ها باید وضعیت خود را توسط Hyperlink های موجود در پاسخ‌های فعلی تغییر دهند. کلاینت نمی‌تواند فرض کند که Hyperlink ای به جز آن‌چه در پاسخ‌های دیگر از سرور گرفته مجاز هستند. طبعیتاً نقطه‌ی ورود نرم‌افزار از این قاعده مستثنا هستند.

4. قابل Cache بودن

مانند شبکه جهانی وب، کلاینت‌ها می‌توانند بدون نگرانی، پاسخ سرور را با توجه به مشخصات پاسخ، Cache کنند. بنابراین پاسخ سرویس‌ها باید به صورت صریح یا ضمنی ذاتاً قابل Cache بودن یا نبودن پاسخ و زمان آخرین تغییر آن را بیان کند و مکانیزمی برای بررسی تازه بودن پاسخ‌ها ارائه کند. مناسب بودن روش Cache می‌تواند بعضی تعاملات کلاینت و سرور را کاهش دهد و مقیاس‌پذیری و کارایی را بهبود بدهد.

5. لایه‌ای بودن

یک کلاینت نمی‌تواند در حالت عادی تشخیص دهد که به صورت مستقیم به سرور نهایی متصل است یا به سرورهای میانی متصل شده است. سرورهای میانی می‌تواند با استفاده از Load-balancing و مکانیزم‌های Caching مقیاس‌پذیری را بهبود دهند. همچنین می‌توانند رویه‌های امنیت روی دسترسی‌ها اعمال کنند.

6. ارسال کد به کلاینت

سرورها می‌توانند با ارسال کد اجرایی سمت کلاینت به آن‌ها ویژگی‌ها و قابلیت‌های آن را افزایش بدهند. به عنوان نمونه سرور می‌تواند کد جاوا اسکریپت برای کلاینت بفرستد که در مرورگر اجرا می‌شود. البته این مورد اجباری نیست و در بعضی کاربردها هم اصلا وجود ندارد.

کاربرد REST در طراحی وب‌سرویس‌ها

مهم‌ترین کاربرد سبک معماری REST در طراحی وب‌سرویس‌های مبتنی بر HTTP بوده است. این کابرد خود الگوی رایج مشخصی دارد که در ادامه شرح می‌دهیم.

• در این الگو آدرس همه‌ی وب سرویس‌ها با URL پایه‌ای همچون http://viratech.ir/resources/ شروع می‌شود.
• قالب انتقال می‌تواند یکی از قالب‌های استاندارد Internet media type باشد، که معمولاً JSON است اما انواع دیگری همچون XML، Atom و YAML نیز می‌تواند باشد.
• از توابع استاندارد HTTP شامل POST، GET، DELETE، PUT و الگوی مشخص در URL برای طراحی سرویس‌ها به صورت یکپارچه استفاده می‌شود.
• Hypertext برای تغییر وضعیت و اشاره به منابع مرتبط استفاده می‌شود.
• هر وب‌سرویس راه دسترسی یا تغییر یک «منبع» است.

سرویس‌های REST مستقل از کلاینت می‌توانند عمل کنند. حتی کلاینت می‌تواند سرورهای دیگری باشند که قصد تعامل با سرویس‌دهنده را دارند (شکل ۱).

شکل ۱: سرویس‌های REST مستقل از کلاینت طراحی می‌شوند. کلاینت‌ها می‌توانند کلاینت‌های وب، موبایل یا سرویس‌دهنده‌های دیگر باشند

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