وب سرویس رست (REST)| معماری رست و ۶ محدودیت ساختاری آن

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

تعریف وب سرویس رست

به صورت خیلی ساده، وب سرویس رست (REST) که مخفف عبارت Representational State Transfer است، به ساختاری در معماری نرم افزار گفته می‌شود که در آن،‌ اطلاعات تحت یک قالب مشخص (به عنوان مثالJSON) و در یکی از پروتکل‌های اینترنتی (به عنوان مثال HTTP) بین سرور و کلاینت جا به جا می‌شوند. وب سرویس رست به توسعه دهندگان کمک می‌کند تا برای برقراری تعامل میان سیستم‌های نرم افزاری، نیازی به استفاده از کتابخانه‌ها یا نرم افزاری‌های مجزا نداشته باشند.

تاریخچه وب سرویس رست 

ایده اولیه معماری رست در مقاله دکترای شخصی به نام روی فیلدینگ (Roy Fielding) و در سال ۲۰۰۰ مطرح گردید. این مقاله از نیاز یک پروتکل ساده برای رد و بدل کردن اطلاعات میان سرور و کلاینت صحبت می‌کرد. قابلیت ویژه این معماری، ساختار لایه لایه‌ای بود که در آن کلاینت برای برقراری ارتباط، نیازی به شناخت کامل سرور نهایی نداشت. همین امر سبب می‌شد تا سیستم‌ها بتوانند با راحتی بیشتری به یکدیگر وصل شوند. از آنجایی که در وب سرویس رست، دیتا هیچ گونه وابستگی به متد انتقال و مرجع ندارد، درخواست‌های (Calls) تمام کلاینت‌ها به سادگی پردازش شده و پاسخ‌ها در قالبی که کلاینت و سرور هر دو آن را درک می‌کنند، منتشر می‌شود. همین آزادی عمل در وب سرویس رست، سبب شده تا برنامه نویسانی با طرز فکر مختلف آن را به خوبی درک کرده و APIهای نرم افزار خود را به این صورت توسعه دهند.

درک معماری وب سرویس رست و محدودیت‌های آن

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

جدا بودن کلاینت و سرور

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

بدون وضعیت بودن

کلاینت‌ها می‌توانند هر چند بار که بخواهد به سرور درخواست ارسال کنند. اما هر درخواستی باید با قبلی متفاوت باشد و هر کدام از آن‌ها، باید اطلاعات مخصوص خود را داشته باشند. از این طریق سرور می‌تواند هر یک از آن‌ها را به صورت جدا دریافت و عملیات مورد نیاز را انجام دهند. در این وضعیت، سرور نمی‌تواند هیچ اطلاعاتی از وضعیت کلاینت داشته باشد. هر داده در داخل خود اطلاعات بسیار مهمی از قبیل کلید ای‌پی‌آی (API KEY) توکن دسترسی (access token) و ایدی کاربر (User ID)  دارد. پس در نتیجه در معماری رست، تمام اطلاعات مربوط به وضعیت سیستم، تنها در اختیار کلاینت خواهد بود. اگر سرور نیازی به اطلاعات حالت‌های قبل داشته باشید، باید آن را در قالب یک درخواست مستقل از کلاینت دریافت کند.

قابلیت کش کردن

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

سیستم لایه بندی شده

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

کد تقاضا

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

واسط کاربری یکنواخت

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

• استفاده از متدهای خاص HTTP مانند GET، POST ، DELETE 
• URL‌ها (نام منبع)
• پاسخ HTTP (وضعیت و بدنه پیام)

برای رعایت کردن این محدودیت، باید این چهار بخش را در نظر بگیریم:

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

• نمایش منبع
  برگشت درخواست به کلاینت باید تحت قالب خاصی صورت بگیرد. به عنوان مثال سرور می‌تواند پاسخ درخواست کلاینت را به صورت HTML، JSON، XML، TXT و …. بدهد.

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

• استفاده از هایپر مدیا (HATEOAS)
  در معماری رست، ‌از هایپرمدیا به عنوان موتور اعلان وضعیت یک اپلیکیشن (Hypermedia as the Engine of Application State) استفاده می‌شود. کلاینت برای اعلام وضعیت موجود به سرور از محتوای بدنه درخواست (Body Content)، پارامتر‌های متنی صف (Query string parameters)، هدر درخواست (Request headers) و همچنین URL مرجع استفاده می‌کند. از طرفی دیگر سرویس‌ها با استفاده از محتوای بدنه پاسخ (Body Content)، کد پاسخ (Response code) و همچنین هدر پاسخ (Response header) کلاینت را از تغییر وضعیت مطلع می‌سازد. در این بخش تمام اطلاعات مورد نیاز کلاینت برای دسترسی به منابع مدنظر و تغییر در وضعیت کاربر برای او ارسال می‌گردد. 

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