انتقال بازنمودی حالت
انتقال بازنمودی حالت (به انگلیسی: Representational state transfer (REST)) یک سبک معماری نرم‌افزاری است که مجموعه ای از محدودیت‌ها را برای استفاده در ایجاد خدمات وب تعریف می‌کند. سرویس‌های وب که مطابق با سبک معماری REST، به نام خدمات وب "RESTful هستند"، قابلیت همکاری بین سیستم‌های رایانه ای در اینترنت را فراهم می‌کنند. یک وب سرویس RESTful به سیستم‌های متقاضی اجازه می‌دهد تا با استفاده از یک مجموعه یکسان و از پیش تعریف شده از عملیات بدون حالت، به بازنمایی‌های متنی از منابع وب دسترسی پیدا نموده و آنها را دستکاری کنند. انواع دیگر خدمات وب، مانند سرویسهای وب SOAP، مجموعه عملیات دلخواه خود را در معرض نمایش قرار می‌دهند.
«منابع وب» برای اولین بار در شبکه جهانی وب به عنوان اسناد یا پرونده‌هایی که توسط URLهای آنها مشخص شده بود تعریف شد. با این حال، امروز آنها تعریف بسیار ژرف‌تر و انتزاعی تری دارند که شامل هر چیز یا موجودیتی است که می‌تواند شناسایی، نام گذاری و آدرس دهی شده یا به هر روشی در وب شناسایی شود. در یک وب سرویس RESTful، درخواست‌های ارسال شده به URI منبع، پاسخی را به صورت یک بسته داده در قالب HTML، XML , JSON یا سایر قالب‌ها ایجاد می‌کنند. پاسخ می‌تواند تأیید کند که آیا تغییراتی در منابع ذخیره شده ایجاد شده‌است، و نیز می‌تواند پیوندهای ابر متن به سایر منابع مرتبط یا مجموعه منابع را فراهم کند. هنگامی که از HTTP استفاده می‌شود، به عنوان متداولترین روش، عملیات (متدهای HTTP) موجود عبارتند از: GET , HEAD , POST , PUT , PATCH , DELETE , CONNECT , OPTIONS و Trace.
با بهره‌وری از یک پروتکل بدون حالت و عملیات استاندارد، سیستم‌های RESTful می‌توانند از کامپاننتهایی که بدون تأثیرگذاری کلی روی سیستم، حتی در حالی که سیستم در حال اجراست، قابلیت مدیریت و بروز شدن دارند، استفاده مجدد نمایند. این ویژگی به این سیستمها اجازه می‌دهد که عملکرد سریع، قابلیت اطمینان و توانایی رشد را داشته باشند.
اصطلاح "انتقال بازنمودی حالت" در سال ۲۰۰۰ توسط روی فیلدینگ در رساله دکتری وی معرفی و تعریف شد. پایان‌نامه فیلدینگ، اصول REST را که از آغاز سال ۱۹۹۴ به عنوان "مدل شی HTTP" شناخته می‌شد، توضیح داد و در طراحی استانداردهای HTTP 1.1 و شناسه‌های یکسان منابع (URI) مورد استفاده قرار گرفت. اصطلاح " "انتقال بازنمودی حالت ""قصد دارد تصویری از چگونگی رفتار یک برنامه خوش طراحی شده وب ارائه کند: چنین برنامه ای شبکه ای از منابع وب (یک ماشین حالت مجازی) است که کاربر با انتخاب شناسه‌های منبع مانند http://www.example.com/articles/21 و عملیات منبع مانند GET یا POST (انتقال حالت برنامه) می‌تواند در این برنامه پیمایش کند که در نتیجه این عملیات، نمایشی از منابع بعدی آماده شده و برای استفاده به کاربر منتقل می‌شود (تهیه وارائه این نمایش در واقع یک حالت جدید بوده و حالت بعدی برنامه تعیین می‌کند).
روی فیلدینگ REST را در پایان‌نامه دکترای خود در سال ۲۰۰۰ با عنوان «سبکهای معماری و طراحی معماریهای نرم‌افزاری مبتنی بر شبکه» در دانشگاه ارواین کالیفرنیا تعریف کرد. وی سبک معماری REST را به موازات HTTP 1.1 از ۱۹۹۶–۱۹۹۹، بر اساس طراحی موجود HTTP 1.0 از ۱۹۹۶، توسعه داد.
فیلدینگ در نگاهی گذشته نگر به توسعه REST، گفت: محدودیت‌های سبک معماری REST بر خصوصیات معماری زیر تأثیر می‌گذارد:
شش محدودیت راهنما یک سیستم RESTful را تعریف می‌کند. این محدودیتها روشهای پردازش و پاسخ دادن سرورها به درخواستهای مشتری را محدود می‌کند به گونه ای که با عمل درحیطه این محدودیتها، سیستم از خواص غیر عملیاتی مطلوب مانند عملکرد، مقیاس پذیری، سادگی، اصلاح پذیری، دید، قابلیت حمل و قابلیت اطمینان برخوردار می‌شود. اگر یک سیستم هر یک از محدودیت‌های مورد نیاز را نقض کند، نمی‌توان آن را RESTful در نظر گرفت.
محدودیت‌های رسمی REST به شرح زیر است:
اصل وجود محدودیت‌های کلاینت-سرور، تفکیک نگرانی‌ها است. جدا کردن نگرانی‌های رابط کاربری از نگرانی‌های مربوط به ذخیره‌سازی داده، قابلیت حمل رابط‌های کاربر را در طول بسترهای چندگانه بهبود می‌بخشد. همچنین با ساده‌تر کردن کامپاننتهای سرور قابلیت مقیاس پذیری را بهبود می‌بخشد. شاید بیشترین اهمیت برای وب این باشد که جدایی اجازه می‌دهد تا کامپاننتها بطور مستقل تکامل یابند، بنابراین از نیازهای در مقیاس اینترنتی حوزه‌های چندگانه سازمانی و در مقیاس اینترنت پشتیبانی کنند.
ارتباط کلاینت-سرور محدود است و در بین درخواستها هیچ محتوایی از کلاینت روی سرور ذخیره نمی‌شود. هر درخواست از هر مشتری شامل کلیه اطلاعات لازم برای سرویس دهی به درخواست است و حالت جلسه در کلاینت نگهداری می‌شود. حالت جلسه می‌تواند توسط سرور به سرویس دیگری مانند بانک اطلاعاتی منتقل شود تا حالت پایدار را برای مدت زمانی حفظ نموده وامکان احراز هویت را فراهم کند. هنگامی که امکان انتقال به یک حالت جدید فراهم شد، کلاینت ارسال درخواست را آغاز می‌کند. در حالی که یک یا چند درخواست مشخص شده‌اند، کلاینت "در حالت گذر است". بازنمایی هر حالت برنامه شامل پیوندهایی است که می‌تواند دفعه بعد که کلاینت برای شروع یک انتقال حالت جدید تصمیم می‌گیرد، مورد استفاده قرار گیرد.
طبق طبیعت شبکه جهانی وب، کلاینتهاها و واسطه‌ها می‌توانند پاسخ‌ها را کش کنند. پاسخ‌ها باید به‌طور ضمنی یا صریح، خود را به عنوان قابل کش کردن یا غیرقابل کش کردن معرفی کنند تا از ارائه اطلاعات قدیمی یا نامناسب به کلاینتها در پاسخ به درخواست‌های بیشتر جلوگیری کنند. کش نمودن خوب مدیریت شده، برخی از تعامل‌های کلاینت و سرور را به‌طور جزئی یا کامل حذف می‌کند و باعث بهبود بیشتر مقیاس پذیری و عملکرد می‌شود.
یک کلاینت معمولاً نمی‌تواند بگوید که آیا مستقیماً به سرور انتهایی وصل شده‌است یا یک واسطه در طول مسیر. اگر یک پروکسی یا متعادل کننده بار بین مشتری و سرور قرار داده شود، در ارتباطات آنها تأثیر نمی‌گذارد و نیازی به بروزرسانی کد مشتری یا سرور نخواهد بود. سرورهای واسطه می‌توانند با فعال کردن تعادل بار و فراهم کردن کش مشترک، مقیاس پذیری سیستم را بهبود بخشند. همچنین، می‌توان امنیت را به عنوان یک لایه در بالای سرویس‌های وب اضافه کرد و سپس منطق تجاری را از منطق امنیتی به‌طور واضح جدا کرد. افزودن امنیت به عنوان یک لایه جداگانه سیاست‌های امنیتی را اعمال می‌کند. سرانجام همچنین این بدان معنی است که یک سرور می‌تواند با چندین سرور دیگر تماس بگیرد تا پاسخی را برای کلاینت ایجاد کند.
سرورها می‌توانند با انتقال کد اجرایی، عملکرد مشتری را بطور موقت توسعه دهندیا سفارشی سازی کنند: به عنوان مثال، کامپاننتهای کامپایل شده مانند اپلت‌های جاوا یا اسکریپت‌های سمت کلاینت مانند JavaScript.
محدودیت رابط یکسان برای طراحی هر سیستم RESTful اساسی است. این کار معماری را ساده‌تر و جدا می‌کند، به طوری که هر قسمت را قادر می‌سازد به‌طور مستقل تکامل یابد. چهار محدودیت برای این رابط یکنواخت عبارتند از:APIوب سرویس های که به محدودیت‌های معماری REST پایبند هستند، APIهای RESTful گفته می‌شوند. APIهای RESTful مبتنی بر HTTP با جنبه‌های زیر تعریف شده‌است:
جدول زیر نحوه استفاده از روشهای HTTP در API RESTful را نشان می‌دهد.
روش GET بی خطر است، به این معنی که استفاده از آن در یک منبع منجر به تغییر حالت منبع نمی‌شود (فقط خواندنی). کنید،GET و PUT و DELETE متدهای تکرارشونده هستند، به این معنی که استفاده چندباره از آنها را روی یک منابع، همان تغییرحالت بار اول را در پی خواهد داشت اگر چه پاسخ هر بار می‌تواند متفاوت باشد.
بر خلاف سرویس‌های وب مبتنی بر SOAP، هیچ استاندارد «رسمی» برای APIهای وب RESTful وجود ندارد. دلیل آن این است که REST یک سبک معماری است، در حالی که SOAP یک پروتکل است. REST به خودی خود استاندارد نیست، اما پیاده‌سازی‌های RESTful از استانداردهایی مانند HTTP، URI , JSON و XML استفاده می‌کند. بسیاری از توسعه دهندگان همچنین APIهای خود را RESTful توصیف می‌کنند، حتی اگر این APIها واقعاً همه محدودیت‌های معماری را که در بالا گفته شد (به خصوص محدودیت رابط یکنواخت) را برآورده نمی‌کنند.