تعریف REST
برای توضیح مزایا ومعایب REST ابتدا باید با REST آشنا شویم .تکنولوژی REST (REpresentational State Transfer)، یک سبک معماری برای توسعهی وب سرویسها است. معماری REST به دلیل سادگی و استواری بر پایه سیستمهای موجود و ویژگیهای HTTP به منظور دستیابی به اهداف آن، بر خلاف ایجاد استانداردها، چارچوبها و فناوریهای جدید، محبوب است.
مزایای معماری REST
یکی از مزیتهای اصلی استفاده از این معماری، هم از جنبهی سرویس گیرنده و هم از جنبهی سرور، تعاملات مبتنی بر REST است که برای هر فردی که با پروتکل HTTP آشنایی دارد، بسیار ساده است. برای مثال، تعاملات مبتنی بر REST وضعیت خود را با استفاده از کدهای وضعیت HTTP استاندارد اعلام میکنند. بنابراین، 404 به معنای «منبع درخواست شده یافت نشد»، کد 401 به معنای «درخواست مجاز نیست»، کد 200 به این معنی است که «همه چیز خوب است» و کد 500 بدان معنی است که «یک خطای نرم افزار غیر قابل برگشت در سرور وجود دارد».
به طور مشابه اعمالی مانند رمزنگاری و یکپارچگی انتقال داده بدون اضافه کردن چارچوب یا تکنولوژی خاصی و صرفا با رمز نگاری SSL و TLS پیاده سازی میشوند. معماری REST همچنین یک معماری مستقل از زبان است. برنامههای مبتنی بر REST میتوانند به کمک هر زبانی از جمله Java، Kotlin، AngularJS و یا JavaScript نوشته شوند. تا زمانی که یک زبان برنامه نویسی میتواند درخواستهای مبتنی بر وب را با استفاده از HTTP انجام دهد، این زبان قادر خواهد بود که برای فراخوانی RESTful API یا وب سرویس استفاده شود. به طور مشابه، وب سرویسهای RESTful میتوانند با استفاده از هر زبانی نوشته شوند، بنابراین توسعه دهندگان با اجرای آنها میتوانند تکنولوژیهایی را انتخاب کنند که بهترین کارایی را در شرایط موجود داشته باشند.
مزیت دیگر استفاده از این معماری، فراگیر بودن آن است. در سمت سرور، انواع چارچوبهای مبتنی بر REST از جمله RESTlet و Apache CXF وجود دارد که به توسعه دهندگان برای ایجاد وب سرویسهای RESTful کمک میکنند. در سمت سرویس گیرنده، تمام چارچوبهای جدید جاوا اسکریپت، مانند JQuery، Node.js، Angular و EmberJS، همهی کتابخانههای استاندارد در API های خود ساخته شدهاند که وب سرویسهای RESTful را فراخوانی کرده و از دادههای XML یا JSON استفاده میکنند.
معایب معماری REST
مزایای استفاده از REST با استفاده از ساختارهای HTTP همچنین محدودیتهایی را ایجاد میکند. بسیاری از محدودیتهای HTTP نیز به نقص سبک معماری REST تبدیل میشوند. به عنوان مثال، HTTP اطلاعات مبتنی بر وضعیت را بین چرخههای درخواست – پاسخ ذخیره نمیکند، که بدین معنی است که برنامههای مبتنی بر REST باید بیثمر باشند و تمام وظایف مدیریت وضعیت باید توسط خود سرویس گیرنده انجام شوند.
به طور مشابه، از آن جا که HTTP هیچ مکانیزمی برای ارسال اعلانها از سرور به سرویس گیرنده ندارد، پیاده سازی هر نوع سرویسی که سرور، کلاینت را بدون رای گیری از جانب آن (client-side polling) و یا انواع مختلف قلاب وب (web hook) به روز رسانی کند سخت است. از دیدگاه پیاده سازی، یک مشکل رایج با REST این واقعیت است که توسعه دهندگان با معنای دقیق REST-based مخالفت میکنند. برخی از توسعه دهندگان نرم افزار به اشتباه هر چیزی را که مبتنی بر SOAP نیست، RESTful در نظر میگیرند. چیزی که سبب این تصور غلط رایج میشود این واقعیت است که REST یک سبک معماری است، بنابراین هیچ پیاده سازی مرجع یا استاندارد قطعی وجود ندارد که تأیید کند آیا یک طراحی خاص، RESTful است یا خیر. در نتیجه، بر سر اینکه آیا یک API داده شده مطابق با اصول مبتنی بر REST است یا خیر بحث وجود دارد.
جایگزینهایی برای REST
فناوریهای جایگزین برای ایجاد سیستمهای مبتنی بر SOA (معماری مبتنی بر سرویس، Service-oriented architecture) و یا ایجاد API برای فراخوانی سرویسهای میکرو از راه دور شامل XML روی HTTP (معروف به XML-RPC)، همچنین CORBA و پروتکل SOAP (پروتکل دسترسی ساده به object) است.
هر تکنولوژی مجموعهای از مزایا و معایب خود را دارد، اما ویژگی مهیج REST که آن را شاخص میکند، این است که به جای اینکه از یک توسعه دهنده بخواهد با مجموعهای از پروتکلهای سفارشی کار کند یا یک فرمت دادهی خاص برای تبادل پیام بین یک سرویس دهنده و یک سرور داشته باشد، REST باور دارد که بهترین راه برای پیاده سازی یک سرویس وب مبتنی بر شبکه این است که به راحتی از ساختار اصلی پروتکل شبکهی خود استفاده کند که در مورد اینترنت، HTTP است. این یک نکته مهم است، زیرا REST فقط برای اعمال به اینترنت در نظر گرفته نشده است؛ بلکه هدف آن است که اصول آن به تمام پروتکلها از جمله WEBDAV، FTP و غیره اعمال شود.
REST در مقابل SOAP
دو سبک رقیب برای اجرای خدمات وب REST و SOAP است. تفاوت اساسی بین این دو، رویکرد فلسفی است که باید به فراخوانی از راه دور بپردازند.
REST یک رویکرد مبتنی بر منابع را برای تعاملات مبتنی بر وب اتخاذ میکند. با REST، شما یک منبع را بر روی سرور قرار میدهید و انتخاب میکنید که این منبع را به روزرسانی کنید، پاک کنید یا اطلاعاتی را در مورد آن دریافت کنید.
در SOAP، کلاینت تصمیم نمیگیرد به طور مستقیم با یک منبع ارتباط برقرار کند، بلکه به جای آن یک سرویس را فراخوانی میکند و این سرویس دسترسی به اشیا و منابع مختلف پشت صحنه را کاهش میدهد. SOAP همچنین تعداد زیادی از چارچوبها و APIها را در بالای لایهی پروتکل HTTP را ایجاد کرده است، از جمله زبان توصیف سرویس وب (Web Services Description Language, WSDL)، که ساختار دادههایی را که بین کلاینت و سرور رد و بدل میشوند، تعریف میکند.
گاهی بهترین نتیجه با تعریف دقیق فرمت پیام حاصل میشود و یا میتوان از APIهای مرتبط با SOAP مانند WS-Eventing، WS-Notification و WS-Security بهره برد. در بعضی مواقع شرایطی پیش میآید که HTTP نمیتواند سطح کارایی را که یک برنامه ممکن است نیاز داشته باشد، فراهم کند. در این موارد، استفاده از SOAP ترجیح داده میشود.
REST URIها و URLها
اکثر مردم با شیوهی عملکرد URLها (Uniform Resource Locator) و URIها (Uniform Resource Identifier) در وب آشنا هستند. رویکرد RESTful برای برنامههای کاربردی ادعا میکند که درخواست اطلاعات در مورد یک منبع باید به اندازهی فراخوانی URL آن ساده باشد.
به عنوان مثال، اگر یک کلاینت بخواهد یک سرویس وب را که تمام آزمونها را در TechTarget در دسترس قرار داده است، به URL مراجعه کند. URLای که به سرویس وب خواهد رسید بدین ترتیب است:
www.techtarget.com/restfulapi/quizzes
هنگام فراخوانی، سرویس وب ممکن است با رشته JSON زیر، لیست تمام آزمونهای موجود را پاسخ دهد که یکی از آنها دربارهی DevOps است:
{ “quizzes” : [ “Java”, “DevOps”, “IoT”] }
برای دریافت آزمون DevOps، سرویس وب ممکن است با استفاده از URL زیر فراخوانی شود:
www.techtarget.com/restfulapi/quizzes/DevOps
با فراخوانی این URL یک رشتهی JSON که لیستی از سوالات در آزمون DevOps را فهرست کرده است، بازگردانده میشود. برای دریافت یک سوال مشخص از آزمون، شمارهی سوال به URL اضافه خواهد شد. بنابراین، برای دریافت سوال سوم در آزمون، URL RESTful زیر استفاده میشود:
www.techtarget.com/restfulapi/quizzes/DevOps/3
فراخوانی این URL ممکن است یک رشتهی JSON مانند زیر را برگرداند:
{ “Question” : {“query”:”What is your DevOps role?”, “optionA”:”Dev”, “optionB”:”Ops”} }
همان طور که میبینید، URLهای REST در این مثال به گونهای منطقی و معنی دار هستند که منابع دقیق درخواست شده را مشخص میکنند.
فرمتهای دادهی JSON و XML REST
مثال بالا نشان میدهد JSON به عنوان فرمت تبادل اطلاعات برای تعامل RESTful استفاده میشود. رایج ترین فرمت تبادل دادهها JSON و XML هستند و بسیاری از خدمات وب RESTful میتوانند تا زمانی که کلاینت بتواند تعامل را در XML یا JSON انجام دهد، از هر دو فرمت به طور متناوب استفاده کنند. توجه داشته باشید با وجود اینکه JSON و XML فرمتهای رایج تبادل داده هستند، خود REST هیچگونه محدودیتی در مورد آنچه که فرمت باید باشد قرار نمیدهد. در واقع، برخی از خدمات وب RESTful به منظور بهره وری، دادههای باینری را مبادله میکنند. این یکی دیگر از مزایای کار با خدمات وب مبتنی بر REST است، زیرا معمار نرم افزار از نظر نحوهی اجرای بهترین خدمات، از آزادی زیادی برخوردار است.
REST و رویههای HTTP
مثال بالا فقط دسترسی به دادهها را بررسی میکند. عملیات پیش فرض HTTP، رویهی GET است که در هنگام دریافت دادهها از سرور مورد استفاده قرار میگیرد. با این حال، HTTP تعدادی از رویههای دیگر از جمله PUT، POST و DELETE را تعریف میکند.REST ادعا میکند که برای حذف دادهای در سرور، به سادگی از URL برای دسترسی به منبع استفاده کنید و روش DELETE از HTTP را اعمال کنید. برای ذخیرهی دادهها در سرور، یک URL و رویهی PUT استفاده میشود. همچنین برای عملیاتی که فراتر از ذخیره سازی، خواندن و یا حذف اطلاعات هستند، می توان از روش POST استفاده کرد.
تاریخچهی REST
REST برای اولین بار توسط دانشمند علم کامپیوتر Roy Fielding در طول انجام پایان نامهی تحصیلات دورهی دکترای وی در دانشگاه کالیفرنیا با عنوان «سبکهای معماری و طراحی معماری نرم افزار مبتنی بر شبکه» ابداع شد. فصل 5 پایان نامه ادعاهای Fielding در مورد چگونگی بهینه سازی معماری سیستمهای توزیعی hypermedia را توصیف میکند. وی تعدادی از شرایط مرزی را توصیف میکند که سیستمهای مبتنی بر REST باید چگونه رفتار کنند. این شرایط به عنوان محدودیتهای REST یاد میشوند. چهار مورد از محدودیتهای کلیدی در زیر شرح داده شده اند:
استفاده از رابط کاربری یکنواخت (Uniform Interface, UI): همانطور که قبلا ذکر شد، منابع در سیستمهای مبتنی بر REST باید از طریق یک URL قابل شناسایی باشند و تنها با استفاده از روشهایی مانند DELETE، PUT و GET در HTTP با منبع در تعامل باشند.
سیستمهای مبتنی بر رابطهی کلاینت، سروری: در سیستمهای مبتنی بر REST، باید تعریف مشخصی از کلاینت و سرور داشته باشیم. UI و نگرانیهای حاصل از درخواستها، در حوزهی کلاینت هستند. در همین حال، دسترسی به دادهها، مدیریت بار کاری و امنیت، در دامنهی سرور است. این جداسازیها اتصال بین کلاینت و سرور را برقرار میکند و هر کدام میتوانند مستقل از دیگری توسعه یابند.
عملیات مجزا (Stateless operations): تمام عملیات بین کلاینت و سرور باید مجزا و مستقل از هم باشند و هر مدیریت حالتی (State) که مورد نیاز است نه بر روی سرور، بلکه باید بر روی کلاینت پیاده سازی شود.
کَش کردن منابع RESTful: توانایی کَش کردن منابع بین فراخوانیهای انجام شده توسط کلاینت نسبت به کاهش تاخیر و بهبود عملکرد اولویت بالاتری دارد. علاوه بر این تمامی منابع باید اجازه ی کَش کردن را داشته باشند، مگر اینکه یک نشانهی صریح برای عدم امکان انجام این عمل یافت شود.
توسعهی APIهای REST در جاوا
در راستای محبوبیت رو به رشد سیستمهای مبتنی بر REST، تعدادی از چارچوبها برای کمک به توسعه دهندگان در ایجاد خدمات وب RESTful به وجود آمده اند. برخی از چارچوبهای منبع باز محبوب برای ایجاد سرویسهای وب مبتنی بر جاوا عبارتند از Apache CXF، Jersey، Restlet، Apache Wink، Spring Data و JBoss’ RESTeasy.
رویکرد کلی هر یک از این چارچوبها این است که به توسعه دهندگان کمک کنند تا خدمات وب RESTful خود را با استفاده از الگوهای معنایی جاوا که با آن آشنا هستند، از جمله Java Platform (نسخه سازمانی)، Servlet API بسازند، در عین حال که کلاسهای از پیش آماده و روشهایی به آنها ارائه میشوند تا با شروط اساسی REST بیشترین مطابقت را داشته باشند.مطالعه بیشتر