طراخی فروشگاه اینترنتی

سازوکار یک RESTful API چگونه است؟
 

RESTful مخفف کلمات Representational State Transfer می‌باشد که یکی از انواع معماری‌های طراحی API است که امروزه در اکثر شرکت‌های نرم‌افزاری به کار گرفته می‌شود تا سایر دولوپرها را قادر سازند با سرویس‌هایی که عرضه می‌کنند به تعامل بپردازند.

این نوع معماری توسعهٔ وب سرویس در سال 2000 توسط Roy Fielding که یک دانشمند علوم کامپیوتری آمریکایی است در رسالهٔ دکترایش مطرح شد (وی در سال ۱۹۹۹ توسط  MIT Technology Review به عنوان یکی از یکصد مخترع زیر ۳۵ سال دنیا لقب گرفت. همچنین وی هم‌بنیان‌گذار پروژهٔ وب سرور Apache است.)

به طور خلاصه، می‌توان گفت که معماری RESTful مجموعه‌ای از یکسری گایدلاین (راهنما) است که با پیروی از آن‌ها می‌توان وب سرویس‌هایی ساخت که سریع، قابل‌اعتماد و قابل‌توسعه باشند. به عبارت دیگر، RESTful چیزی نیست که در زبان‌های برنامه‌نویسی یا فریمورک‌ها گنجانده شده باشد بلکه صرفاً یکسری قوانین توسعهٔ نرم‌افزار است که چنانچه در توسعهٔ ای‌پی‌آیِ خود از آن‌‌ها تبعیت کنیم، به سادگی برچسب RESTful روی سرویس‌مان خواهد خورد.

در معماری RESTful حروف RE برگرفته از کلمهٔ Representational می‌باشند که این اصطلاح به مسئلهٔ فرمت دیتای بازگشتی از سمت سرور اشاره دارد به طوری که این فرمت می‌تواند اچ‌تی‌ام‌ال، جیسون، اکس‌ام‌ال و یا ده‌ها فرمت دیگر باشد. به طور مثال، در ریکوئست زیر از سرور خواسته‌ایم تا داده‌های مد نظرمان را در قالب فرمت جسیون در اختیارمان قرار دهد:

برای درک بهتر این موضوع، فرض کنیم مقداری آب داریم که می‌توانیم آن را هم در پارچ و هم در  یک لیوان عرضه کنیم مضاف بر اینکه بسته به نیاز خود، حتی می‌توانیم آن را منجمد کرده و در قالب یک تکه یخ عرضه کنیم. به عبارتی، آب که در این مثال یک ریسورس است می‌تواند از یکسری Represention یا «ظاهر» مختلف برخوردار باشد. به همین منوال، یک ریسورس در سمت سرور، مثلاً دیتای مرتبط با یک کاربر خاص، می‌تواند در قالب‌های مختلفی همچون اچ‌تی‌ام‌ال، جیسون، اکس‌ام‌ال و یا دیگر فرمت‌ها عرضه گردد و همین می‌شود که از صفت Representational در نام‌گذاری این معماری استفاده شده است.

در معماری REST کلمات State Transfer بدین موضوع اشاره دارند که به جای ذخیره‌سازی وضعیت کلاینت در سمت سرور، کلیهٔ داده‌ها در سمتِ خود کلاینت ذخیره می‌شوند و در هر درخواستی نیز برای سرور ارسال می‌شوند و همین می‌شود که این معماری اصطلاحاً Stateless نامیده می‌شود به طوری که ماهیت Stateless این معماری باعث می‌شود تا بتوانیم سیستم‌های توزیع‌شده‌ای توسعه‌ دهیم که در آن‌ها میلیون‌ها کاربر به صورت هم‌زمان می‌توانند با سرور ارتباط برقرار ساخته و داده‌های مد نظر خود را درخواست کنند.

آشنایی با قوانین شش‌گانهٔ معماری RESTful
 

به طور کلی، شش قانون در توسعهٔ یک وب سرویس با استفاده از معماری RESTful در نظر گرفته می‌شوند که در ادامه با تک‌تک آن‌ها آشنا خواهیم شد:

- Client-Server: زمانی که نحوهٔ توسعهٔ‌ کلاینت ساید با سرور ساید از یکدیگر کاملاً مجزا باشد، همین مسئله باعث می‌گردد تا به سادگی بتوانیم از دیتای سمت سرور در کلاینت‌های مختلفی از جمله یک وب‌سایت یا اپ موبایل استفاده نماییم و با توجه به اینکه در این نوع معماری حداقل وابستگی بین رابط کاربری و سرور وجود دارد، با سهولت هرچه تمام می‌توانیم اقدام به توسعهٔ کامپوننت‌ها کنیم بدون آنکه بخواهیم دغدغهٔ تداخل‌شان با یکدیگر را داشته باشیم. چنین ارتباطی بر اساس اصلِ Uniform Interface برقرار می‌شود به طوری که این اصل به دولوپرهای فرانت‌اند و بک‌اند اجازه می‌دهد تا بدون هیچ‌گونه وابستگی به یکدیگر، اقدام به توسعهٔ فیچرهای مد نظر خود کنند.

- Cacheable: به طور کلی، پاسخ به درخواست‌های کلاینت می‌تواند در سمت سرور کَش شود که این سیاست به منظور بهبود پرفورمنس می‌تواند اتخاذ گردد.

- Stateless: در اصطلاح RESTful، حرف S برگرفته از واژهٔ‌ State به معنی «وضعیت» است اما در عین حال یکی از خصیصه‌های این معماری، برخورداری از قابلیتی است تحت عنوان Stateless به معنی «بدونِ وضعیت» که همین تناقض درک این موضوع را دشوار می‌سازد که در ادامه سعی می‌کنیم این موضوع را به زبان ساده تشریح نماییم.

زمانی که مابین کلاینت و سرور یک ارتباط از جنسِ اچ‌تی‌تی‌پی برقرار می‌گردد، در سمتِ سرور هرگز وضعیت یا بهتر بگوییم اطلاعاتی از کلاینت ذخیره نخواهد شد بلکه روش کار بدین صورت است که کلاینت یک ریکوئست حاوی کلیهٔ جزئیاتی که سرور برای اجرای تَسک مذکور نیاز دارد برای سرور ارسال می‌کند و سرور هم بدون آنکه دغدغهٔ این را داشته باشد که کلاینت چیست و کجا است، ریسپانس مرتبط را در اختیارش می‌گذارد و در نهایت هم این ارتباط به پایان می‌رسد.

به طور خلاصه، Stateless حاکی از آن است که هر درخواست از سمت کلاینت مستقل از دیگر درخواست‌ها است و زمانی که کلاینت درخواستی از جنس اچ‌تی‌تی‌پی ایجاد می‌کند، چنین درخواستی حاوی کلیهٔ جزئیات و اطلاعات مورد نیاز سرور برای هندل کردن تَسک مربوطه است و سرور هرگز به داده‌های قبلی برای این کار اتکا نمی‌کند. به طور مثال، اگر داده‌ای مهم باشد و در سرور برای درست هندل کردن درخواست به آن نیاز داشته باشد، کلاینت می‌باید هر دفعه آن داده را در کنار داده‌های دیگر ارسال کند. به طور مثال، چنانچه به منظور استفاده از سرویسی نیاز به لاگین کردن داشته باشیم، توکنی که نشان می‌دهد ما کاربر معتبری هستیم (Authentication) در هر بار ارسال درخواست می‌باید برای سرور ارسال گردد.

برای درک بهتر این موضوع، می‌توان یکی از شبکه‌های اجتماعی همچون توییتر را مثال زد. در این اپلیکیشن، همچون سایر شبکه‌های اجتماعی، وقتی که به اصطلاح Scroll Down می‌کنیم توییت‌های جدیدی در معرض دیدمان قرار می‌گیرد اما این در حالی است که اگر اپ را ببندیم و مجدد آن را باز نماییم، مجدد به ابتدای تایم‌لاین باز می‌گردیم و سرور هرگز نسبت به اینکه آخرین باری که اپ را مورد استفاده قرار دادیم در کجای تایم‌لاین قرار داشتیم اطلاعی ندارد و این همان مفهوم Stateless است. به عبارت دیگر، سرور هرگز نسبت به وضعیت درخواست‌های قبلی کلاینت (در این مثال اپلیکیشن توییتر) اطلاعی ندارد.

اساساً می‌توان گفت که یکی از مزیت‌های کلیدی Stateless آن است که تغییرات صورت‌گرفته روی سرور هرگز کلاینت را با مشکل مواجه نمی‌کنند. به طور مثال، اگر در همان لحظه‌ای که کلاینت در حال برقراری ارتباط با سرور است به هر دلیلی سرور از دسترس خارج شده و سرور جایگزینی برایش در نظر گرفته شود، کلاینت بدون هیچ مشکلی می‌تواند دیتای مد نظر خود را دریافت کند.

- Uniform Interface: یکپارچکی در توسعهٔ یک ای‌پی‌آی از جنس RESTful یک باید است مضاف بر اینکه به منظور حفظ یکپارچگی، هر ریسورس باید از اصول ثابتی تبعیت کند که از آن جمله می‌توان به نحوهٔ نام‌گذاری، فرمت دیتا و ... اشاره کرد. وقتی توسعه‌دهندگان با بخشی از ای‌پی‌آی آشنا شدند، باید بتوانند با رویکرد یکسانی از سایر بخش‌های ای‌پی‌آی مذکور استفاده نمایند. گرچه اصل Uniform Interface در ظاهر پیچیده و گیج‌کننده به نظر می‌رسد، اما در عمل مفهوم بسیار ساده‌ای است بدین صورت که در توسعهٔ یک ای‌پی‌آی از جنس رِست می‌باید از متدهای پروتکل اچ‌تی‌تی‌پی استفاده کرد (البته محدود به استفاده از این پروتکل نیستیم.)، برای دستیابی به ریسورس‌های مختلف می‌باید از یک یوآر‌ال منحصر‌به‌فرد استفاده کرد به علاوه اینکه در ریسپانس می‌باید با استفاده از کدهای وضعیت، اطلاعات شفافی در اختیار کلاینت قرار دهیم. این اصل خود شامل یکسری اصول دیگر است که عبارتند از:

-- Resource-Based: تک‌تک ریسورس‌ها در معماری رِست از طریق یکسری URI خاص مشخص می‌شوند و خودِ این ریسورس‌ها نیز از آنچه در سمت فرانت‌اند در اختیار کاربران قرار می‌گیرند مجزا هستند. برای مثال، سرور بسته به نیازی که اپلیکیشن دارا است ریسورس درخواستی را در قالب جیسون، اکس‌ام‌ال و یا اچ‌تی‌ام‌ال در اختیار بخش فرانت‌اند قرار می‌دهد.

-- Manipulation of Resources Through Representations: زمانی که در سمت فرانت‌اندِ اپلیکیشن یک ریسورس دریافت می‌شود،‌ از آن پس اپلیکیشن از دیتای کافی به منظور اِعمالِ یکسری تغییرات و یا حذف آن ریسورس برخوردار است (البته این در حالی است که پرمیشن لازم را داشته باشد.)

-- Self-descriptive Messages: در معماری رِست هر پیامی دربرگیرندهٔ دیتای کافی و گویا به منظور تشریح چگونگی پردازش‌اش را دارا است. برای مثال، پیام‌های اچ‌تی‌تی‌پی به خوبی می‌توانند مشخص کنند که مثلاً‌ توسط چه پارسری پردازش شوند.

-- HATEOAS : این سرواژه که برگرفته از واژگان Hypermedia As The Engine Of Application State است به این نکته اشاره دارد که کلاینت‌ها State یا «وضعیت» کنونی را از طریق پارامترهای مختلف،‌ هِدِرهای اچ‌تی‌تی‌پی و ... در اختیار سرور می‌گذارند و سرو نیز از طریق کدهای وضعیت و هِدِرهای اچ‌تی‌تی‌پی پاسخی به درخواست‌ها عرضه می‌کند که از بُعد فنی چنین چیزی Hypermedia یا Hyperlinks نام‌گذاری می‌شود. با در نظر گرفتن این توضیحات، HATEOAS همچنین بدان معنا است که در صورت نیاز لینک‌هایی را می‌توان در بدنهٔ هِدِرها قرار داد تا لینکی به ریسورس‌های مرتبط در اختیار کلاینت قرار گیرد. 

- Layered System : این معماری امکانی را در اختیارمان می‌گذارد تا به طور مثال بتوان اصطلاحاً Business Logic سرویس خود را روی سرور «الف»، داده‌ها را روی سروی «ب» و همچنین تصدیق اطلاعات کاربر (Authentication) را روی سرور «پ» انجام داد. این نوع معماری که مبتنی بر لایه‌های انتزاعی مختلفی است امکانی را در اختیار سیستم می‌گذارد تا هر کامپوننت صرفاً لایه‌ای که در حال تبادل داده با آن است را دیده و درگیر کامپوننت‌های دیگر نگردد.

همچنین این اصل حاکی از آن است که سرورهایی که به عنوان لایه‌های میانی در نظر گرفته می‌شوند (همچون Load-balancing) منجر به بهبود توسعه‌پذیری سیستم می‌شوند مضاف بر اینکه در همین لایه‌های میانی می‌توان یکسری سیاست‌های امنیتی نیز به منظور بهبود امنیت دیتای کاربران اِعمال کرد.

- Code on Demand : این اصل که اختیاری می‌باشد حاکی از آن است که به منظور اجرای یک درخواست مبتنی بر این معماری، کلاینت می‌تواند کدی را در قالب اِپلِت جاوا یا اسکریپتی خاص در دیگر زبان‌ها دانلود و اجرا کند. به عبارت دیگر، پیش از این گفتیم که ریسورس‌ها می‌توانند از یکسری Represention یا «ظاهر» مختلف برخوردار باشند که با این توضیحات، این اصل حاکی از آن است که یکی از فرمت‌هایی که می‌توان برای یک ریسورس در نظر گرفت، کد یا اسکریپتی است که باید در سمت کلاینت اجرا شده و تَسک خاصی را عملی سازد.

چنانچه سرویسی پنج اصل ابتدایی + اصل ششم (Code on Demand) که اختیاری است را داشته باشد، می‌توان برچسب RESTful روی آن زد اما در عین حال توجه داشته باشیم که بسته به نوع نرم‌افزار و نیازهایی که داریم، گاهی می‌توانیم برخی از این اصول را نقض کنیم که در چنین شرایطی باز هم معماری ما RESTful خواهد بود.