موضوع مقاله: رست | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # رست | مقدمه: سرویس‌های وب که مطابق با سبک معماری REST، به نام خدمات وب RESTful هستند، قابلیت همکاری بین سیستم‌های رایانه ای در اینترنت را فراهم می‌کنند. | ## بخش 1: رست | انواع دیگر خدمات وب، مانند سرویسهای وب SOAP، مجموعه عملیات دلخواه خود را در معرض نمایش قرار می‌دهند. با این حال، امروز آنها تعریف بسیار ژرف‌تر و انتزاعی تری دارند که شامل هر چیز یا موجودیتی است که می‌تواند شناسایی، نام گذاری و آدرس دهی شده یا به هر روشی در وب شناسایی شود. با بهره‌وری از یک پروتکل بدون حالت و عملیات استاندارد، سیستم‌های RESTful می‌توانند از کامپاننتهایی که بدون تأثیرگذاری کلی روی سیستم، حتی در حالی که سیستم در حال اجراست، قابلیت مدیریت و بروز شدن دارند، استفاده مجدد نمایند. این ویژگی به این سیستمها اجازه می‌دهد که عملکرد سریع، قابلیت اطمینان و توانایی رشد را داشته باشند. اصطلاح انتقال بازنمودی حالت در سال ۲۰۰۰ توسط روی فیلدینگ در رساله دکتری وی معرفی و تعریف شد. روی فیلدینگ REST را در پایان‌نامه دکترای خود در سال ۲۰۰۰ با عنوان «سبکهای معماری و طراحی معماریهای نرم‌افزاری مبتنی بر شبکه» در دانشگاه ارواین کالیفرنیا تعریف کرد. فیلدینگ در نگاهی گذشته نگر به توسعه REST، گفت: خصوصیات معماری محدودیت‌های سبک معماری REST بر خصوصیات معماری زیر تأثیر می‌گذارد: عملکرد در تعامل کامپاننت، که می‌تواند عامل اصلی در عملکرد درک شده توسط کاربر و بهره‌وری شبکه باشد. روی فیلدینگ تأثیر REST در مقیاس پذیری را به شرح زیر توصیف می‌کند: سادگی یک رابط یکسان. قابلیت اصلاح کامپاننتها برای رفع نیازهای متغیر (حتی در حالی که برنامه در حال اجراست)؛ قابلی مشاهده بودن ارتباط بین کامپاننتها توسط ایجنتهای خدمات. قابلیت حمل کامپاننتها با انتقال کد برنامه به همراه داده ها؛ قابلیت اطمینان به صورت مقاومت در برابر خطای سطح سیستم شامل خرابی در کامپاننتها، کانکتورها یا داده‌ها. این محدودیتها روشهای پردازش و پاسخ دادن سرورها به درخواستهای مشتری را محدود می‌کند به گونه ای که با عمل درحیطه این محدودیتها، سیستم از خواص غیر عملیاتی مطلوب مانند عملکرد، مقیاس پذیری، سادگی، اصلاح پذیری، دید، قابلیت حمل و قابلیت اطمینان برخوردار می‌شود. اگر یک سیستم هر یک از محدودیت‌های مورد نیاز را نقض کند، نمی‌توان آن را RESTful در نظر گرفت. محدودیت‌های رسمی REST به شرح زیر است: معماری کلاینت سرور اصل وجود محدودیت‌های کلاینت-سرور، تفکیک نگرانی‌ها است. | ## بخش 2: رست | جدا کردن نگرانی‌های رابط کاربری از نگرانی‌های مربوط به ذخیره‌سازی داده، قابلیت حمل رابط‌های کاربر را در طول بسترهای چندگانه بهبود می‌بخشد. شاید بیشترین اهمیت برای وب این باشد که جدایی اجازه می‌دهد تا کامپاننتها بطور مستقل تکامل یابند، بنابراین از نیازهای در مقیاس اینترنتی حوزه‌های چندگانه سازمانی و در مقیاس اینترنت پشتیبانی کنند. بی حالت بودن ارتباط کلاینت-سرور محدود است و در بین درخواستها هیچ محتوایی از کلاینت روی سرور ذخیره نمی‌شود. هر درخواست از هر مشتری شامل کلیه اطلاعات لازم برای سرویس دهی به درخواست است و حالت جلسه در کلاینت نگهداری می‌شود. حالت جلسه می‌تواند توسط سرور به سرویس دیگری مانند بانک اطلاعاتی منتقل شود تا حالت پایدار را برای مدت زمانی حفظ نموده وامکان احراز هویت را فراهم کند. هنگامی که امکان انتقال به یک حالت جدید فراهم شد، کلاینت ارسال درخواست را آغاز می‌کند. بازنمایی هر حالت برنامه شامل پیوندهایی است که می‌تواند دفعه بعد که کلاینت برای شروع یک انتقال حالت جدید تصمیم می‌گیرد، مورد استفاده قرار گیرد. قابلیت ذخیره طبق طبیعت شبکه جهانی وب، کلاینتهاها و واسطه‌ها می‌توانند پاسخ‌ها را کش کنند. پاسخ‌ها باید به‌طور ضمنی یا صریح، خود را به عنوان قابل کش کردن یا غیرقابل کش کردن معرفی کنند تا از ارائه اطلاعات قدیمی یا نامناسب به کلاینتها در پاسخ به درخواست‌های بیشتر جلوگیری کنند. کش نمودن خوب مدیریت شده، برخی از تعامل‌های کلاینت و سرور را به‌طور جزئی یا کامل حذف می‌کند و باعث بهبود بیشتر مقیاس پذیری و عملکرد می‌شود. سیستم لایه ای یک کلاینت معمولاً نمی‌تواند بگوید که آیا مستقیماً به سرور انتهایی وصل شده‌است یا یک واسطه در طول مسیر. اگر یک پروکسی یا متعادل کننده بار بین مشتری و سرور قرار داده شود، در ارتباطات آنها تأثیر نمی‌گذارد و نیازی به بروزرسانی کد مشتری یا سرور نخواهد بود. سرورهای واسطه می‌توانند با فعال کردن تعادل بار و فراهم کردن کش مشترک، مقیاس پذیری سیستم را بهبود بخشند. | ## بخش 3: رست | همچنین، می‌توان امنیت را به عنوان یک لایه در بالای سرویس‌های وب اضافه کرد و سپس منطق تجاری را از منطق امنیتی به‌طور واضح جدا کرد. سرانجام همچنین این بدان معنی است که یک سرور می‌تواند با چندین سرور دیگر تماس بگیرد تا پاسخی را برای کلاینت ایجاد کند. کد در صورت تقاضا (اختیاری) سرورها می‌توانند با انتقال کد اجرایی، عملکرد مشتری را بطور موقت توسعه دهندیا سفارشی سازی کنند: به عنوان مثال، کامپاننتهای کامپایل شده مانند اپلت‌های جاوا یا اسکریپت‌های سمت کلاینت مانند جاوا اسکریپت. این کار معماری را ساده‌تر و جدا می‌کند، به طوری که هر قسمت را قادر می‌سازد به‌طور مستقل تکامل یابد. به عنوان مثال، سرور می‌تواند داده‌ها را از پایگاه داده خود به صورت اچ‌تی‌ام‌ال ، اکس‌ام‌الیا JSON ارسال کند - که هیچ‌کدام بازنمایش داخلی سرور نیستند. به عنوان مثال، کدام توسط یک نوع رسانه می‌تواند مشخص شود که کدام پارسر برای پردازش فراخوانی شود. هر چه دسترسی پیشتر برود، سرور توسط متنی پاسخ می‌دهد که شامل ابرپیوندهایی به سایر حالتهای موجوددر برنامه، می‌باشد. نیازی نیست کلاینت با کدهای سخت برنامه که شامل اطلاعات مربوط به ساختار یا پویایی برنامه می‌شوند، درگیر شود. URI از منبع عضو ایجاد شده به طور خودکار در قسمت هدر پاسخ موقعیت مکانی اختصاص داده می شود. با استفاده از دستورالعمل موجود در بدنه درخواست، یک منبع عضو را در منبع عضو ایجاد کنید. روش GET بی خطر است، به این معنی که استفاده از آن در یک منبع منجر به تغییر حالت منبع نمی‌شود (فقط خواندنی). | ## جمع‌بندی | بسیاری از توسعه دهندگان همچنین APIهای خود را RESTful توصیف می‌کنند، حتی اگر این APIها واقعاً همه محدودیت‌های معماری را که در بالا گفته شد (به خصوص محدودیت رابط یکنواخت) را برآورده نمی‌کنند.