نمای کلی REST. بخش 1: REST چیست

سلام، امروز یک موضوع بسیار جالب و مهمتر از همه پرتقاضا در بازار کار را مطالعه خواهیم کرد - REST. ما نمای کلی REST را به سه بخش تقسیم می کنیم:

1. در قسمت اول به تاریخچه REST می پردازیم و اصولی که REST بر اساس آن ها استوار است را شرح می دهیم.

2. در مرحله دوم، نحوه برقراری ارتباط بین مشتری و سرور از طریق پروتکل HTTP را بررسی خواهیم کرد.

3. در مرحله سوم، یک برنامه کوچک RESTful می نویسیم که با استفاده از برنامه Postman آن را تست می کنیم.

این مقاله برای خوانندگانی است که با اصطلاحات زیر آشنا هستند:

• HTTP؛
• URL و URI؛
• JSON و تا حدی XML.
• تزریق وابستگی

قسمت 1. REST چیست

REST، مانند بسیاری از چیزها در دنیای فناوری اطلاعات، مخفف عبارت Representational State Transfer است . این یک سبک معماری از تعامل بین اجزای سیستم توزیع شده در یک شبکه کامپیوتری است. به زبان ساده، REST یک سبک تعامل (تبادل داده) بین اجزای مختلف یک سیستم را تعریف می کند، که هر یک ممکن است به صورت فیزیکی در مکان های مختلف قرار داشته باشند. این سبک معماری مجموعه ای ثابت از محدودیت ها را نشان می دهد که هنگام طراحی یک سیستم توزیع شده در نظر گرفته می شوند. این محدودیت ها گاهی اوقات اصول REST نامیده می شوند. تعداد آنها زیاد نیست، فقط 6 قطعه است. کمی بعد در مورد آنها صحبت خواهیم کرد.

تاریخچه REST

اصطلاح REST توسط روی فیلدینگ، یکی از خالقان پروتکل HTTP، در پایان نامه دکترای خود با عنوان «سبک های معماری و طراحی معماری های نرم افزاری مبتنی بر شبکه» در سال 2000 ابداع شد. می‌توان گفت که اصطلاح REST هنوز جوان است، اگرچه مفهوم آن در اساس شبکه جهانی وب قرار دارد. ما به عمق تاریخچه پیدایش این اصطلاح نخواهیم پرداخت. اگر می خواهید در منابع اصلی غوطه ور شوید، به پایان نامه فیلدینگ نگاهی بیندازید .

محدودیت ها و اصول REST

همانطور که در بالا گفته شد، REST نحوه تعامل اجزای یک سیستم توزیع شده را با یکدیگر تعریف می کند. به طور کلی، این از طریق درخواست-پاسخ رخ می دهد. مؤلفه ای که درخواست را ارسال می کند مشتری نامیده می شود . مؤلفه ای که درخواست را پردازش می کند و پاسخی را برای مشتری ارسال می کند سرور نامیده می شود . درخواست ها و پاسخ ها اغلب از طریق HTTP (پروتکل انتقال ابرمتن) ارسال می شوند. به طور معمول، سرور نوعی برنامه وب است. مشتری می تواند نه فقط هر چیزی، بلکه بسیار زیاد باشد. به عنوان مثال، یک برنامه تلفن همراه که اطلاعات را از سرور درخواست می کند. یا مرورگری که درخواست هایی را از یک صفحه وب به سرور برای دانلود داده ارسال می کند. برنامه A می تواند داده ها را از برنامه B درخواست کند سپس A یک کلاینت در رابطه با B است و B یک سرور در رابطه با A است. در عین حال A می تواند درخواست های C, D, D و غیره را پردازش کند. در این حالت برنامه A هم سرور و هم مشتری است. این همه به زمینه بستگی دارد. یک چیز واضح است: مؤلفه ای که درخواست را ارسال می کند مشتری است. مؤلفه ای که درخواست را دریافت، پردازش و به آن پاسخ می دهد سرور است. با این حال، هر سیستمی که اجزای آن از طریق درخواست-پاسخ با هم ارتباط برقرار می کنند، سیستم REST (یا RESTful) نیستند. برای اینکه یک سیستم RESTful در نظر گرفته شود، باید با شش محدودیت REST مطابقت داشته باشد:

1. آوردن معماری به مدل مشتری-سرور

اساس این محدودیت، تمایز نیازها است. لازم است نیازهای رابط مشتری را از نیازهای سروری که داده ها را ذخیره می کند جدا کنید. این محدودیت قابلیت حمل کد کلاینت را به پلتفرم های دیگر افزایش می دهد و ساده سازی قسمت سرور، مقیاس پذیری سیستم را بهبود می بخشد. تمایز بین "مشتری" و "سرور" به آنها اجازه می دهد تا مستقل از یکدیگر توسعه یابند.

2. نداشتن شرط

معماری REST نیازمند رعایت شرایط زیر است. بین درخواست‌ها، سرور نیازی به ذخیره اطلاعات مربوط به وضعیت مشتری و بالعکس ندارد. تمام درخواست های مشتری باید به گونه ای طراحی شوند که سرور تمام اطلاعات لازم برای تکمیل درخواست را دریافت کند. به این ترتیب، هم سرور و هم مشتری می توانند هر پیام دریافتی را بدون اتکا به پیام های قبلی "درک" کنند.

3. ذخیره سازی

کلاینت ها می توانند پاسخ های سرور را ذخیره کنند. اینها، به نوبه خود، باید به طور صریح یا ضمنی به‌عنوان ذخیره‌سازی یا غیرقابل ذخیره‌سازی تعیین شوند، به طوری که مشتریان داده‌های قدیمی یا نادرست را در پاسخ به درخواست‌های بعدی دریافت نکنند. استفاده مناسب از کش کمک می کند تا برخی از تعاملات کلاینت-سرور، به طور کامل یا جزئی از بین برود و عملکرد و توسعه پذیری سیستم را بیشتر افزایش دهد.

4. یکنواختی رابط

الزامات اساسی معماری REST شامل یک رابط یکپارچه و یکنواخت است. کلاینت همیشه باید بفهمد که در چه قالبی و به کدام آدرس ها باید درخواست ارسال کند و سرور نیز به نوبه خود باید بفهمد که در چه قالبی باید به درخواست های مشتری پاسخ دهد. این یک قالب یکپارچه برای تعامل مشتری و سرور است که توضیح می دهد چه چیزی، کجا، به چه شکل و چگونه ارسال شود و یک رابط یکپارچه است.

5. لایه ها

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

6. کد درخواستی (محدودیت اختیاری)

این محدودیت حاکی از آن است که کلاینت می تواند عملکرد خود را با دانلود کد از سرور در قالب اپلت ها یا اسکریپت ها گسترش دهد.

مزایای REST

برنامه هایی که با تمام محدودیت های فوق مطابقت دارند دارای مزایای زیر هستند: قابلیت اطمینان (عدم نیاز به ذخیره اطلاعات وضعیت مشتری، که ممکن است از بین برود).

• عملکرد (به دلیل استفاده از کش)؛
• مقیاس پذیری؛
• شفافیت سیستم تعامل؛
• سادگی رابط ها؛
• قابلیت حمل قطعات؛
• سهولت ایجاد تغییرات؛
• توانایی تکامل، انطباق با نیازهای جدید.

قسمت 2: ارتباط بین مشتری و سرور قسمت 3: ایجاد یک سرویس RESTful در Spring Boot