انتقال وضعیت

[kako]

در حال حاضر استفاده از سرویس های وب، یکی از مرسوم ترین روش ها برای نوشتن برنامه های وب است. البته کاربرد آن با یک web application تفاوت دارد. بگذارید با یک مثال موضوع را روشن کنیم؛ شما قرار است یک سیستم هواشناسی طراحی کرده و توسعه دهید.
اگر پیاده سازی خود را به عنوان یک web application بگذارید، خروجی ای که می گیرید برای خودتان کاملا درست و قابل استفاده است؛ اما فرض کنید قرار است یک برنامه دیگر نیز از اینسیستمی که شما طراحی کرده و توسعه داده اید، استفاده کند. حالا این برنامه می تواند روی وب باشد، برنامه ویندوزی باشد یا برنامه موبایل، نوع آن خیلی مهم نیست؛ مهم این است که این برنامه بتواند از اطلاعاتی که شما به عنوان یک برنامه web application توسعه داده اید استفاده کند. اگر معماری شما همان یک برنامه تحت وب باشد، تعامل برنامه که به آن می گوییم client (خدمت گیرنده) از شما server (خدمت دهنده) تا حدودی مشکل و مدیریت خطا در آن نیز بسختی امکان پذیر می شود.
اینجاست که استفاده از سرویس های وب کار را راحت تر می کند؛ یعنی شما یک سری api ارائه می کنید که قرار است به بقیه خدمت گیرنده ها اطلاعات لازم را در مورد وضع آب و هوا ارائه کند و برنامه شما که یک برنامه تحت وب بود از آن سرویس ها استفاده کند، برنامه های دیگر نیز برای نمایش وضعیت آب و هوا آن را مورد استفاده قرار دهند.
یکی از پروتکل های وب سرویس soap است؛ معماری قدیمی وب سرویس ها که بر پایه xml استوار بود؛ یکی از معماری های جدیدی که استفاده از آن مرسوم شده سرویس های rest است. همان طور که از اسم آن برمی آید به وضعیت وابسته و برای انتقال اطلاعات در یک سیستم توزیع شده استفاده می شود و بر مبنای پروتکل http استوار است. استفاده از آن خیلی راحت تر از معماری های پیچیده مانند rpc ، corba و soap است.
عملیاتی را که قرار است یک سرویس بر مبنای rest انجام دهد، وضعیت یک درخواست http مشخص می کند. اگر داده های شما با متد post در یک بستر http ارسال شوند، به معنای این است که شما قصد دارید داده ای را ایجاد یا به روزرسانی کنید، اگر متد get را مورد استفاده قرار دهید، یعنی درخواست گرفتن اطلاعات را دارید، اگر با delete این کار را انجام دهید داده های مورد نظر شما حذف خواهد شد، در نتیجه شما با استفاده از وضعیت http عملیات مرسوم crud (ایجاد ، خواندن ، به روزرسانی و حذف) را انجام می دهید.
rest یک استاندارد نیست، بلکه راه جایگزین soap و rpc است. از شباهت های آن با وب سرویس های قدیمی می توان به موارد زیر اشاره کرد:
1 به محیط یا سیستم عامل وابسته نیست و روی هر محیطی می توان از آنها استفاده کرد.
2 به زبان یا محیط توسعه وابستگی ندارد و شما با استفاده از هر زبانی که بتواند درخواست های http رامدیریت کند، می توانید از آنها استفاده کنید.
3 به دلیل این که روی http اجرا می شود یک راه استاندارد برای توسعه وب سرویس هاست.
داده های خروجی در سرویس rest که به آن restful web service گفته می شود، می تواند بر مبنای xml که rss یکی از مثال های عمومی آن است باشد یا هر فرمت دیگری مانند json. این که خروجی براساس چه نوع داده ای باشد به عهده طراح است.
می خواهید اطلاعات کاربری با شماره کاربری 12345 را دریافت کنید. برای این منظور در soap درخواست زیر لحاظ می شود:
«?xml version="1.0"?»
soap:envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"»
«soap:body pb="http://www.acme.com/phonebook"»
«pb:getuserdetails»
«pb:userid»12345«/pb:userid»
«/pb:getuserdetails»
«/soap:body»
«/soap:envelope»
اما در یک سرویس rest به صورت زیر بیان می شود
http: / / www.acme.com / phonebook / userdetails / 12345
همان گونه که مشاهده می کنید استفاده از rest به مراتب ساده تر از soap است.
اهداف توسعه rest:
1 مقیاس پذیر بودن اجزای سیستم
2 ایجاد یک رابط عمومی برای ارتباط با سیستم
3 وابسته نبودن به اجزای توسعه سیستم
4 استفاده از اجزای واسط برای کاهش زمان بندی انتقال اطلاعات، اجباری کردن امنیت، و پنهان سازی و کپسوله سازی قوانین موجود در سیستم.
در rest دو چیز مهم است؛ یکی resource که url و کل درخواست http که از سمت یک خدمت گیرنده صادر می شود و دیگری state یعنی وضعیت آن درخواست که همان طور که در بالا توضیح داده شد متد های http وضعیت یک درخواست را مشخص می کند.
در حال حاضر خیلی از سایت های بزرگ برای ارائه خدمات خود از rest api استفاده می کنند، مانند توییتر، فیس بوک، google و....

منابع:
1 http://rest.elkstein.org/
2 http://en.wikipedia.org/wiki/representational_state_transfer