همانگونه که انسانها با یکدگیر ارتباط برقرار میکنند، نرم افزارها هم برای انتقال اطلاعات و انجام محاسبات، باید با یکدیگر اطلاعات رد و بدل کنند. به رابط بین دو سیستم نرم افزاری که امکان ارتباط آنها از طریق اینترنت را فراهم میسازد، وب سرویس یا وب API میگویند. معماریهای مختلفی برای ساخت وب سرویسها وجود دارد که در این مقاله قصد داریم درخصوص یکی از معروفترین آنها یعنی وب سرویس رست صحبت کنیم.
به صورت خیلی ساده، وب سرویس رست (REST) که مخفف عبارت Representational State Transfer است، به ساختاری در معماری نرم افزار گفته میشود که در آن، اطلاعات تحت یک قالب مشخص (به عنوان مثالJSON) و در یکی از پروتکلهای اینترنتی (به عنوان مثال HTTP) بین سرور و کلاینت جا به جا میشوند. وب سرویس رست به توسعه دهندگان کمک میکند تا برای برقراری تعامل میان سیستمهای نرم افزاری، نیازی به استفاده از کتابخانهها یا نرم افزاریهای مجزا نداشته باشند.
ایده اولیه معماری رست در مقاله دکترای شخصی به نام روی فیلدینگ (Roy Fielding) و در سال ۲۰۰۰ مطرح گردید. این مقاله از نیاز یک پروتکل ساده برای رد و بدل کردن اطلاعات میان سرور و کلاینت صحبت میکرد. قابلیت ویژه این معماری، ساختار لایه لایهای بود که در آن کلاینت برای برقراری ارتباط، نیازی به شناخت کامل سرور نهایی نداشت. همین امر سبب میشد تا سیستمها بتوانند با راحتی بیشتری به یکدیگر وصل شوند. از آنجایی که در وب سرویس رست، دیتا هیچ گونه وابستگی به متد انتقال و مرجع ندارد، درخواستهای (Calls) تمام کلاینتها به سادگی پردازش شده و پاسخها در قالبی که کلاینت و سرور هر دو آن را درک میکنند، منتشر میشود. همین آزادی عمل در وب سرویس رست، سبب شده تا برنامه نویسانی با طرز فکر مختلف آن را به خوبی درک کرده و APIهای نرم افزار خود را به این صورت توسعه دهند.
برای اینکه برنامهای که طراحی میکنید در قالب معماری رست قرار بگیرد، شما باید یک سری پیش نیازها و محدودیتهایی را اعمال کنید. محدودیتهای معماری رست سبب میشود تا توسعه دهندگان زمان کمتری برای یادگیری و درک ایپیآی شما صرف کنند. یک وب سرویس مبتنی بر معماری رست باید ۶ محدودیت کلیدی داشته باشد:
یک رابط یکپارچه در معماری رست، نقش کلاینت و سرور را از یکدیگر جدا میکند. این جدایی سبب میشود تا به عنوان مثال، کلاینت در زمان ارتباط با سرور، هیچ نگرانی در خصوص تغییر ناخواسته اطلاعات ذخیره شده بر روی پایگاه داده داخلی سرور نداشته باشد. همچنین سرور نیز دیگر نگران تغییر وضعیت ناگهانی یک کلاینت نخواهد بود و توسعه دهندگان میتوانند در هر زمان و مکانی، اصلاحات مورد نظرشان برای بهبود عملکرد برنامه را اعمال کنند.
کلاینتها میتوانند هر چند بار که بخواهد به سرور درخواست ارسال کنند. اما هر درخواستی باید با قبلی متفاوت باشد و هر کدام از آنها، باید اطلاعات مخصوص خود را داشته باشند. از این طریق سرور میتواند هر یک از آنها را به صورت جدا دریافت و عملیات مورد نیاز را انجام دهند. در این وضعیت، سرور نمیتواند هیچ اطلاعاتی از وضعیت کلاینت داشته باشد. هر داده در داخل خود اطلاعات بسیار مهمی از قبیل کلید ایپیآی (API KEY) توکن دسترسی (access token) و ایدی کاربر (User ID) دارد. پس در نتیجه در معماری رست، تمام اطلاعات مربوط به وضعیت سیستم، تنها در اختیار کلاینت خواهد بود. اگر سرور نیازی به اطلاعات حالتهای قبل داشته باشید، باید آن را در قالب یک درخواست مستقل از کلاینت دریافت کند.
از آنجایی که کلاینتهای زیادی به یک سرور مشابه دسترسی داشته و معمولا اطلاعات یکسانی را از سرور درخواست میکنند، سرور میتواند این درخواستها را در حافظه خود کش کند. این کار جلو پردازشهای اضافی برای به دست آوردن اطلاعاتی که پیشتر بر روی سرور قرار گرفتهاند را گرفته و باعث بهبود عملکرد سیستم میشود.
یک کلاینت نمیتواند کاملا مستقیم به یک سرور متصل شود. در مسیر اتصال کلاینت به سرورهای دست بالا، سرورهای میانی قرار گرفتهاند که میتوانند با اعمال سیاستهایی مانند تنظیم میزان ورودی و خروجی (Load-balancing) و اضافه کردن حافظه کش، مقیاس پذیری و گسترش پذیری سیستم را افزایش دهند. علاوه بر این سرورهای میانی میتوانند سبب افزایش امنیت سیستم هم شوند.
این محدودیت اختیاریست و به کلاینت این امکان را میدهد تا با دریافت فایل اجرایی (Applet) یا یک اسکریپت از سرور، دسترسیهای سفارشی سازی شده داشته باشد. اینگونه سرور میتواند اطلاعات گستردهتری در خصوص کلاینتهای خود به دست آورد. از این طریق حتی اگر دو کلاینت یک سرویس یکسان را از سرور دریافت کنند، میتوانند رفتار کاملا متفاوتی داشته باشند. از آنجایی که استفاده از این محدودیت همچنان در بین برنامه نویسان جا نیوفتاده، از آن به عنوان یک محدودیت اختیاری نام برده میشود.
در وب سرویس رست میان کلاینت و سرور همواره یک رابط یکسان وجود دارد. به همین دلیل است که معماری کلی به بخشهای مختلفی تقسیم میشود و هر بخش به صورت جداگانه به فعالیت خود ادامه میدهد. بخشهای مختلف وب سرویس رست به سه بخش تقسیم بندی میگردد.
برای رعایت کردن این محدودیت، باید این چهار بخش را در نظر بگیریم:
با استفاده از این محدودیت، حتی اگر کلاینتها از روشهای مختلفی اقدام به ارسال درخواست به سرور بکنند (مرورگرهای متفاوت مانند کروم، فایرفاکس یا هر اپلیکیشن اندرویدی) باز هم درخواستهای ارسالی به یک شکل به نظر خواهند رسید. لذا این روش میتواند تاثیر مثبتی بر میزان انعطاف پذیری سیستم داشته باشد.