Stateless به چه معنی است و مزایای آن چیست!

[eshpilen]

به بیان کلی، stateless (بی وضعیت) به معنای آنست که سرور اطلاعات وضعیت بر هر کلاینت را نگهداری نمیکند. برای یک مثال ساده، به یک سرویس خواندن فایل توجه کنید. یک API ممکن به شکلی است که در بیشتر زبانهای برنامه نویسی متداول است، با توابعی همچون FileOpen و FileRead که میتواند مثل این استفاده شود:



File f = FileOpen("myfile.dat");
byte[] firstK = FileRead(f, 1024);
byte[] secondK = FileRead(f, 1024);

در این شبه کد، firstK شامل نخستین 1024 بایت خواهد بود، و دومین secondK شامل 1024 بایت بعدی خواهد بود. اما توجه کنید که چطور هر دو بوسیلهء فراخوانی تابع دقیقا یکسانی ایجاد شدند، که دقیقا لیست آرگومان های یکسانی دارند! این رخ میدهد چراکه سیستم برای هر فایل باز، به خاطر میسپارد که مکان اشاره گر خواندن در کجا قرار دارد. این در این مورد، وضعیت (state) است.

در مقایسه، یک API بدون وضعیت میتواند برای دستیابی به نتایج یکسانی همچون مثال زیر استفاده شود:


firstK = FileRead("myfile.dat", 0, 1024);
secondK = FileRead("myfile.dat", 1024, 1024);

در اینجا، تابع FileRead پارامترهای نام فایل، شروع از کجا، و چقدر برای خواندن را میپذیرد؛ هیچ وضعیتی وابسته شده به فایل وجود ندارد، و فراخوانی دوبارهء یک فرمان یکسان نتیجهء یکسانی را موجب میشود (البته با فرض اینکه خود فایل تغییر نکرده باشد).

واضح است که API بدون وضعیت برای توابع محلی خواندن فایل معنای چندانی ندارد؛ اما آنها در یک API بر اساس وب بسیار بامعنا هستند. سه مزیت کلیدی:

1) جان به در بردن از یک ریستارت سرور. اگر سرور مجبور بود وضعیت بر هر کلاینت را بخاطر بسپارد، یک ریستارت به معنای آن میبود که همهء دیتای مربوط به وضعیت از دست میرفت. اما با یک سرور بدون وضعیت، برای کلاینت ها مهم نیست که سرور ریستارت شده باشد.

2) عدم بستگی کلاینت به سرور؛ پاسخها میتوانند توسط یک دسته (cluster) از سرورها هندل شوند، و هر درخواست میتواند توسط یک ماشین متفاوت در cluster هندل شود. در یک API دارای وضعیت، یا دقیقا ماشین یکسانی مجبور است تمام درخواستها بوسیلهء کلاینت یکسان را هندل کند، و یا وضعیت تمام کلاینت ها باید در بین تمامی سرورها نسخه برداری شود.

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

======================

منبع: http://rest.elkstein.org/
البته در بخش کامنت هاش.

[MMSHFE]

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

[eshpilen]

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

ما بیشتر در یک مقیاس کوچک و بازهء زمانی کوتاه مدت (کمتر از 10 سال) فکر میکنیم چون شرایط و نیازمون رو اینطور میبینیم.
اما وب در مقیاس بزرگ و در زمان طولانی بر اصول طراحی درستی استوار بوده که تونسته ظرفیت این همه گسترش و تغییرات و پدیده های پیشبینی نشده رو داشته باشه.

[eshpilen]

ممنون، ولی خداییش ترجمه باحالی بود! مثل Babylon بود.
منظورتون از مثل بابیلون رو متوجه نشدم.

[MMSHFE]

منظورم این بود که مثل ترجمه های ماشینی شده بود. از اون قبیل ترجمه ها که با نرم افزارهایی مثل Babylon تحویل میگیریم. ولی خداییش منظورم این نبود که با این نرم افزارها ترجمه شده و مطمئنم یک ترجمه انسانی بوده. صرفاً منظورم نوع ساختار جملات در ترجمه بود. موفق باشید.