رست (REST) به زبان ساده برای مبتدیان

REST مخفف Representational State Transfer می‌باشد. سیستم رست تنها یک سری از دستور العمل‌ها و سبک‌های معماری وب سرویس ها ست که برای انتقال داده‌ها استفاده می‌شوند.

بوسیله سامان فراز به روز رسانی شده در فروردین 22, 1399

آموزش مفهوم رست (REST) به زبان ساده و کاربردی

قبل از آنکه بخواهیم درباره رست (REST) مطالبی بیاموزیم، حتما باید با مبحث وب سرویس ها و یا همان ای پی آی ها آشنایی داشته باشیم. سریال «آموزش وب سرویس» در کنار دیگر مقالات منتشر شده در سایت «اپی اکو» می‌توانند کمک شایانی برای کسب اطلاعات جامع در مورد وب سرویس ها باشند.

در مورد پیدایش رست با بگوییم که آقای دکتر روی فیلدینگ (Roy Fielding)، اولین کسی بود که به عنوان پایان نامه دکتری خود معماری رست (REST) را در سال ۲۰۰۰ میلادی به دنیا عرضه نمود.

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

کلاینت‌ها (مصرف کنندگان):

کلاینت یا به بیان دیگر مصرف کننده، شخص یا نرم افزاری است که از وب سرویس (api) استفاده می کند. برای مثال شما می‌توانید توسعه دهنده‌ای باشید که از وب سرویس توئیتر (Twitter API) به منظور خواندن پست‌ها از توییتر، نوشتن اطلاعات در توییتر، حتی ساخت حساب کاربری جدید توییتری و یا هر اقدام دیگری در این سایت، برای اپلیکیشن خود استفاده نمایید. در این حالت برنامه شما یک وب سرویس متعلق به توییتر خواهد بود. کلاینت نیز در این مثال می‌تواند یک مرورگر وب و یا مرورگر اینترنتی (Web Browser) محسوب شود. هنگامی که شما وارد سایت توییتر می‌شوید، مرورگر شما کلاینتی خواهد بود که وب سرویس توییتر را فرا می‌خواند و از داده‌های برگشتی برای رندر اطلاعات و نمایش آنها استفاده می‌کند.

منبع (Resource):

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

طراحی و معماری رست

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

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

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

رست (REST) به چه معناست؟

واژه REST مخفف عبارت (REpresentational State Transfer) به معنای «انتقال بازنمودی حالت» است. این یعنی سرور بخشی از منبعی که درخواست شده است را برای کلاینت منتقل خواهد کرد.

به عبارت ساده تر REST به معنای روشی برای ایجاد، خواندن، آپدیت نمودن و یا حذف اطلاعات بر روی سرور مورد نظر کلاینت است.

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

درخواست‌های ارسالی از کلاینت می‌‌تواند در فرمت JSON باشد. شاید بتوان گفت که در بیشتر وب سرویس ها نیز از همین فرمت استفاده می‌شود. البته به جای JSON می‌‌توان از فرمت‌های XML و یا HTML نیز استفاده نمود.

موارد مورد نیاز سرور

زمانی که شما به عنوان کلاینت از یک وب سرویس استفاده می‌کنید، کاری که سرور برای شما انجام می‌دهد به دو عامل که توسعه دهنده برای سرور تهیه می‌کند بستگی دارد:

۱. شناسه URL

انتخاب یک شناسه برای منبع دلخواه کلاینت وظیفه توسعه دهنده است. این شناسه یک URL برای منبع است که به عنوان یک endpoint نیز شناخته می شود. در حقیقت URL مخفف واژه Uniform Resource Locator به معنای آدرسی است که محل فایل یا برنامه ای را در فضای اینترنت مشخص می کند.

۲. دستورات HTTP

در معماری REST، عملی که شما از سرور خواسته اید تا را روی منبع مورد نظرتان انجام دهد، به صورت یک دستور HTTP در سرور اجرا می‌شود. در کل از چهار دستور برای دسترسی به RESTful API استفاده می شود:

GET برای گرفتن یک شی
POST برای ایجاد یک شی
PUT برای ویرایش یا بازنویسی یک شی
DELETE برای حذف یک شی

با هر بار فراخوانی API، یکی از این متدها باید به سرور پاس داده شود تا سرور بداند چطور باید رفتار کند.

برای مثال، برای فراخوانی یک کاربر توییتر با استفاده از وب سرویس رست فول توییتر (Twitter’s RESTful API)، شما به یک آدرس URL برای مشخص کردن شناسه کاربر مورد نظر خود، و نیز به دستور GET از کدهای HTTP نیاز خواهید داشت.

به یاد داشته باشیم که هر نام کاربری در حساب‌های کاربری توییتر حکم یک URL واحد را داشته و در حقیقت هیچ نام کاربری واحدی، برای دو کاربر در توییتر وجود ندارد.

شرایط طراحی RESTful

برای آنکه یک وب سرویس بر پایه معماری RESTful طراحی شود، نیاز دارد تا تابع ۶ محدودیت (constraints) باشد:

رابط یکنواخت (Uniform interface) داشته باشد
کلاینت از سرور جدا باشد
بدون حالت و بی تفاوت (Stateless) باشد
سیستم لایه ای داشته باشد
قابلیت CASH داشته باشد
دارای قابلیت کد تقاضا باشد

رابط یکنواخت Uniform interface

این محدودیت شامل چهار بخش است:

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

اگر یک کلاینت درباره کاربر خاصی درخواستی ارسال کند، سرور علاوه بر پاسخ به این درخواست خاص، می‌تواند اطلاعاتی درباره نحوه تغییر در وضعیت کاربر را نیز ارسال کند. برای مثال می‌تواند اطلاعات مربوط به نحوه تغییر نام کاربری و یا نحوه حذف کاربر را برای کلاینت ارسال نماید. اگر می‌خواهید درک بهتری از این روش پیدا کنید، تنها کافی است نحوه پاسخ یک سرور با فرمت HTML به یک مرورگر یا BROWSER (که در اینجا نقش کلاینت را دارد) را برای خود مرور کنید. HTML شامل تگ‌های لینک شده‌ای (که در اینجا نقش هایپر مدیاها را دارد) می‌باشد که در آنجا کاربر می‌تواند برنامه را بروزرسانی کند (برای مثال لینکی که به صفحه «تنظیمات پروفایل» می رسد). اما برای قرار دادن همه این موارد در دید کاربران، اغلب صفحات اینترنتی از هایپرمدیا‌ها، به عنوان موتور وضعیت اپلیکیشن استفاده می‌کنند. اما در عین حال بیشتر وب سرویس های رایج نیز به این محدودیت پایبند نیستند.

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

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

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

بی تفاوت (Stateless) بودن سرور

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

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

سیستم لایه‌ای

در فاصله بین کلاینت (یعنی کسی که اطلاعاتی را از سرور درخواست کرده است) و سرور نهایی (بخشی که مسئول پاسخگویی به این درخواست می‌باشد) ممکن است تعداد متعددی سرور دیگر وجود داشته باشد.

این سرورها باید بتوانند لایه‌های امنیتی، لایه‌های کش (ذخیره)، لایه‌های load-balancing و یا لایه‌های دیگری با ویژگی‌های مشابه را تامین نمایند. اما در عوض این لایه‌ها نباید تاثیری بر درخواست‌ها (request) و یا پاسخ‌ها (response) داشته باشند. به بیان دیگر کلاینت از وجود تعداد لایه‌های میان خود و سرور نهایی (که در نهایت پاسخگوی درخواست وی است) بی اطلاع خواهد بود.

قابلیت کش پذیری (ذخیره اطلاعات)

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

کد تقاضا

این محدودیت کاملا اختیاری است. به این معنی که یک وب سرویس حتی بدون ارائه کد در صورت تقاضا می‌تواند RESTful باشد.

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

در این مقاله سعی کردیم تا توضیحاتی را به زبانی بسیار ساده در مورد نحوه طراحی رست و کلا معماری RESTful برای شما بیان نماییم. اگر مایل به یادگیری بیشتر در این مورد هستید، حتما مطالب منتشر شده در سایت «اپی اکو» را دنبال نمایید.

منبع medium