سلام! امروز با موضوعی آشنا خواهیم شد که بسیار جالب است و از همه مهمتر تقاضای زیادی در بازار کار دارد: REST. ما نمای کلی خود از REST را به سه بخش تقسیم می کنیم:
در قسمت اول به تاریخچه REST می پردازیم و اصولی که REST بر اساس آن ها بنا شده است را شرح می دهیم.
در مرحله دوم، نحوه ارتباط بین مشتری و سرور از طریق پروتکل HTTP را در نظر خواهیم گرفت.
در مورد سوم، یک برنامه کوچک RESTful می نویسیم که با استفاده از برنامه ای به نام Postman آن را آزمایش می کنیم.
این مقاله برای خوانندگانی است که با اصطلاحات زیر آشنا هستند:
HTTP
URL و URI
JSON و (به میزان کمتر) XML
تزریق وابستگی
قسمت 1. REST چیست؟
REST، مانند موارد دیگر در دنیای فناوری اطلاعات، مخفف است. این از "انتقال دولت نمایندگی" مشتق شده است . این یک سبک معماری برای تعامل بین اجزای یک سیستم توزیع شده در یک شبکه کامپیوتری است. به زبان ساده، REST سبک تعامل (تبادل داده ها) بین اجزای مختلف سیستم را تعیین می کند که هر کدام می توانند به صورت فیزیکی در مکان های مختلفی قرار گیرند. این سبک معماری مجموعه ای ثابت از محدودیت هایی است که هنگام طراحی یک سیستم توزیع شده رعایت می شود. این محدودیت ها گاهی اوقات اصول راهنمای REST نامیده می شوند. تعداد زیادی نیست، فقط 6. کمی بعد در مورد آنها صحبت خواهیم کرد.
برنامه هایی که با اصول REST ساخته شده اند، یعنی آنهایی که محدودیت های REST را نقض نمی کنند، "RESTful" نامیده می شوند.
تاریخچه REST
اصطلاح REST توسط روی فیلدینگ، یکی از سازندگان پروتکل HTTP، در دوره دکتری خود معرفی شد. پایان نامه با عنوان "سبک های معماری و طراحی معماری های نرم افزاری مبتنی بر شبکه" در سال 2000. اگرچه اصطلاح REST را هنوز می توان جوان نامید، مفهومی که آن را نشان می دهد در هسته اصلی وب جهانی نهفته است. ما عمیقاً به تاریخچه این اصطلاح نمی پردازیم. اگر می خواهید در منابع اولیه غوطه ور شوید، به پایان نامه
فیلدینگ نگاهی بیندازید .
محدودیت ها و اصول REST
همانطور که در بالا گفته شد، REST تعریف می کند که چگونه اجزای یک سیستم توزیع شده باید با یکدیگر تعامل داشته باشند. به طور کلی، این از طریق یک فرآیند درخواست-پاسخ رخ می دهد. مؤلفه ای که درخواست را ارسال می کند کلاینت و مؤلفه ای که درخواست را پردازش می کند و پاسخی را برای مشتری ارسال می کند سرور نامیده می شود . درخواست ها و پاسخ ها اغلب از طریق پروتکل HTTP ارسال می شوند. HTTP مخفف HyperText Transfer Protocol است. به طور معمول، یک سرور برخی از برنامه های کاربردی وب است. مشتری تقریباً هر چیزی می تواند باشد. به عنوان مثال، یک برنامه تلفن همراه که اطلاعات را از یک سرور درخواست می کند. یا مرورگری که درخواست ها را از یک صفحه وب به سرور برای دانلود داده ارسال می کند. برنامه A ممکن است داده ها را از برنامه B درخواست کند. در این مورد، A یک کلاینت با توجه به B است و B یک سرور نسبت به A است. در عین حال، A می تواند درخواست های B، C، D و غیره را پردازش کند. در این حالت برنامه A هم سرور و هم مشتری است. همه چیز به زمینه بستگی دارد. یک چیز مسلم است: مؤلفه ای که درخواست را ارسال می کند مشتری است. مؤلفه ای که یک درخواست را دریافت، پردازش و به آن پاسخ می دهد سرور است. با این حال، هر سیستمی که اجزای آن از طریق یک فرآیند درخواست-پاسخ با هم ارتباط برقرار می کنند، یک سیستم RESTful نیستند. برای اینکه یک سیستم RESTful در نظر گرفته شود، باید با شش محدودیت REST مطابقت داشته باشد:
1. معماری سرویس گیرنده-سرور
این محدودیت در مورد تفکیک نگرانی ها است. لازم است الزامات رابط مشتری از الزامات سروری که داده ها را ذخیره می کند جدا شود. این محدودیت باعث می‌شود کد مشتری برای سایر پلتفرم‌ها قابل حمل‌تر باشد و ساده‌سازی سمت سرور، مقیاس‌پذیری سیستم را بهبود می‌بخشد. ایجاد تمایز بین "مشتری" و "سرور" به آنها اجازه می دهد تا مستقل از یکدیگر توسعه یابند.
2. بی تابعیت
یک معماری RESTful مستلزم رعایت شرایط زیر است. در فاصله زمانی بین درخواست ها، سرور نباید اطلاعاتی در مورد وضعیت مشتری و بالعکس ذخیره کند. تمام درخواست های مشتری باید به گونه ای تنظیم شوند که تمام اطلاعات لازم برای تکمیل درخواست را در اختیار سرور قرار دهد. بنابراین، هم سرور و هم مشتری می توانند هر پیام دریافتی را بدون اتکا به پیام های قبلی "درک" کنند.
3. Cacheable
کلاینت ها می توانند پاسخ های سرور را ذخیره کنند. اینها، به نوبه خود، باید به‌طور صریح یا ضمنی به‌عنوان ذخیره‌شده یا غیرکش‌شده تعیین شوند، به‌طوری‌که مشتریان داده‌های قدیمی یا نادرست را در پاسخ به درخواست‌های بعدی دریافت نکنند. ذخیره سازی صحیح به حذف کامل یا جزئی برخی از تعاملات مشتری و سرور کمک می کند و عملکرد و مقیاس پذیری سیستم را بیشتر می کند.
4. رابط یکنواخت
الزامات اساسی یک معماری RESTful شامل یک رابط یکپارچه و یکنواخت است. کلاینت باید همیشه فرمت و آدرس هایی را که باید هنگام ارسال درخواست استفاده کند، درک کند و سرور نیز به نوبه خود باید فرمتی را که باید هنگام پاسخ به درخواست های مشتری استفاده کند، درک کند. این تعامل سازگار مشتری و سرور که توصیف می کند چه چیزی، کجا، به چه شکل و چگونه داده ارسال شود، یک رابط یکپارچه است.
5. لایه ها
منظور ما از لایه ها، ساختار سلسله مراتبی شبکه است. گاهی اوقات یک کلاینت می تواند مستقیماً با سرور ارتباط برقرار کند و گاهی اوقات فقط با یک گره میانی ارتباط برقرار می کند. استفاده از سرورهای میانی می تواند مقیاس پذیری را به لطف تعادل بار و ذخیره کش توزیع شده افزایش دهد. بیایید یک مثال ارائه دهیم. یک اپلیکیشن موبایلی را تصور کنید که در سرتاسر جهان محبوب است. بخشی جدایی ناپذیر از برنامه شامل بارگذاری تصاویر است. تعداد کاربران آن به میلیون ها نفر می رسد، بنابراین یک سرور نمی تواند چنین بار سنگینی را تحمل کند. جداسازی سیستم به لایه ها این مشکل را حل می کند. اگر مشتری یک تصویر از یک گره میانی درخواست کند، آنگاه گره میانی تصویری را از سروری درخواست می کند که در حال حاضر کمترین بارگذاری را دارد و تصویر را به مشتری برمی گرداند. اگر حافظه پنهان در هر سطح از سلسله مراتب به درستی اعمال شود، می توان به مقیاس پذیری سیستم خوبی دست یافت.
6. کد درخواستی (اختیاری)
این محدودیت نشان می دهد که مشتری می تواند عملکرد خود را با دانلود کد از سرور به شکل اپلت یا اسکریپت گسترش دهد.
مزایای معماری RESTful
برنامه هایی که با تمام محدودیت های ذکر شده مطابقت دارند دارای مزایای زیر هستند: قابلیت اطمینان (بدون نیاز به ذخیره وضعیت مشتری، که ممکن است از بین برود)
ما نمای کلی خود از REST را به سه بخش تقسیم می کنیم:
GO TO FULL VERSION