REST که مخفف عبارت Representational State Transfer است، معماری است که از شبکه جهانی وب الهام گرفته است. اگرچه REST شامل اصول و محدودیت‌های متعددی است، اما ما روی مواردی تمرکز خواهیم کرد که در حل مشکلات یکپارچه‌سازی در زمینه میکروسرویس‌ها و زمانی که به دنبال یک سبک رابط جایگزین برای RPC برای سرویس‌هایمان هستند، بیشتر مفید هستند.
حیاتی ترین جنبه REST مفهوم منابع است که می تواند به عنوان موجودیت هایی در نظر گرفته شود که سرویس از آنها آگاه است، مانند مشتری. سرور در صورت درخواست، نمایش‌های مختلفی از این مشتری تولید می‌کند و نحوه ظاهر شدن یک منبع به صورت خارجی کاملاً از نحوه ذخیره‌سازی داخلی آن جدا است. به عنوان مثال، یک کلاینت ممکن است یک نمایش JSON از یک مشتری درخواست کند، حتی اگر در قالبی کاملاً مجزا ذخیره شده باشد. هنگامی که یک مشتری نمایندگی این مشتری را به دست آورد، ممکن است درخواست هایی برای اصلاح آن صادر کند و سرور ممکن است آنها را برآورده کند یا نکند.
استراحت و HTTP
سبک REST به خوبی با قابلیت های مفید تعریف شده در HTTP ادغام می شود. به عنوان مثال، افعال HTTP مانند GET، POST و PUT از قبل دارای معانی تعریف شده در مشخصات HTTP در رابطه با نحوه تعامل آنها با منابع هستند. با توجه به معماری REST، متدها باید در همه منابع به طور مداوم رفتار کنند، و خوشبختانه، HTTP طیف وسیعی از روش‌ها را ارائه می‌کند که می‌توانیم از آنها استفاده کنیم. به طور خاص، GET یک منبع را بدون قدرت بازیابی می کند و POST یک منبع جدید ایجاد می کند. با استفاده از این روش‌های HTTP، می‌توانیم نیاز به روش‌های متعدد createCustomer یا editCustomer را از بین ببریم. در عوض، ما می‌توانیم به سادگی یک درخواست POST با یک نمایندگی مشتری ارسال کنیم تا از سرور درخواست ایجاد یک منبع جدید کنیم و از یک درخواست GET برای به دست آوردن نمایشی از یک منبع موجود استفاده کنیم. در این سناریوها، ما یک نقطه پایانی در قالب یک منبع مشتری داریم و عملیات موجود در پروتکل HTTP ادغام می شود.
HTTP طیف گسترده ای از ابزارها و فناوری های پشتیبانی را ارائه می دهد، مانند پروکسی های ذخیره HTTP مانند Varnish و متعادل کننده های بار مانند mod_proxy. علاوه بر این، بسیاری از ابزارهای نظارتی مجهز به پشتیبانی از پیش ساخته شده برای HTTP هستند. این بلوک‌های ساختمانی ما را قادر می‌سازند تا حجم قابل توجهی از ترافیک HTTP را مدیریت کرده و آنها را به صورت شفاف هدایت کنیم. با HTTP، ما همچنین می‌توانیم از تمام کنترل‌های امنیتی موجود برای ایمن کردن ارتباطات خود، از احراز هویت اولیه تا گواهی‌های مشتری، استفاده کنیم. با این حال، استفاده موثر از HTTP برای به دست آوردن این مزایا بسیار مهم است. اگر ضعیف استفاده شود، می‌تواند به اندازه هر فناوری دیگری ناامن و دشوار باشد. اما در صورت استفاده صحیح، HTTP کمک زیادی برای تسهیل کار ما ارائه می دهد.
Hypermedia به عنوان موتور حالت برنامه (HATEOAS)
یکی دیگر از اصول معرفی شده در REST که می تواند به ما کمک کند از جفت شدن بین کلاینت و سرور جلوگیری کنیم، مفهوم hypermedia به عنوان موتور حالت برنامه است. این عبارت نسبتاً متراکم و یک مفهوم نسبتاً جالب است، بنابراین اجازه دهید کمی آن را تجزیه کنیم.
مفهوم هایپر مدیا شامل پیوندهایی به قطعات مختلف محتوا در قالب های مختلف مانند متن، تصاویر و صداها در یک قطعه محتوای خاص است. این مفهوم احتمالاً برای شما آشنا است، زیرا نحوه عملکرد یک صفحه وب معمولی را منعکس می کند: با دنبال کردن پیوندها، که نوعی کنترل های ابررسانه ای هستند، برای مشاهده محتوای مرتبط. HATEOAS این ایده را با پیشنهاد این که کلاینت‌ها باید با سرور (که ممکن است باعث انتقال حالت شود) از طریق پیوندهایی به منابع دیگر در تعامل باشند، بیشتر میبرد. به جای اینکه بداند مشتریان دقیقاً در کجای سرور قرار دارند و چه URI را باید هدف قرار دهد، مشتری باید برای یافتن اطلاعات لازم پیوندها را جستجو کرده و پیمایش کند.
به سایت خرید Amazon.com فکر کنید. مکان سبد خرید در طول زمان تغییر کرده است. گرافیک تغییر کرده است. لینک تغییر کرده است. اما ما به عنوان انسان به اندازه کافی باهوش هستیم که هنوز یک سبد خرید را ببینیم، بدانیم چیست و با آن تعامل داشته باشیم. ما درک درستی از معنای سبد خرید داریم، حتی اگر شکل دقیق و کنترل اساسی مورد استفاده برای نشان دادن آن تغییر کرده باشد. می دانیم که اگر بخواهیم سبد خرید را مشاهده کنیم، این کنترلی است که می خواهیم با آن تعامل داشته باشیم. به همین دلیل است که صفحات وب می توانند در طول زمان به تدریج تغییر کنند. تا زمانی که این قراردادهای ضمنی بین مشتری و وب‌سایت هنوز رعایت می‌شوند، تغییرات نیازی به تغییرات قطعی ندارند.
1.<link rel = “/products” href=”products/item1” />
2.<link rel=”/instantpurchase” href=”instantPurchase/1234” />
در این سند دو کنترل هایپر مدیا داریم. مشتری که چنین سندی را می‌خواند باید بداند که کنترل با رابطه محصولات جایی است که برای دریافت اطلاعات در مورد اقلام محصول باید پیمایش کند و خرید فوری بخشی از پروتکل مورد استفاده برای خرید آلبوم است. مشتری باید معنای API را دقیقاً به همان روشی که یک انسان نیاز دارد درک کند که در یک وب سایت خرید، سبد خرید جایی است که اقلامی که باید خریداری شوند، درک کند.
من به عنوان یک مشتری، برای خرید آلبوم نیازی به دانش طرح URI خاص ندارم. تنها کاری که باید انجام دهم این است که به منبع دسترسی داشته باشم، کنترل خرید را پیدا کنم و به آن ادامه دهم. مکان کنترل خرید ممکن است تغییر کند، URI ممکن است دستخوش اصلاح شود، یا سایت ممکن است من را به یک سرویس کاملاً متفاوت هدایت کند، اما به عنوان یک مشتری، لازم نیست نگران این جزئیات باشم. این تنظیمات سطح قابل توجهی از جداسازی بین مشتری و سرور را فراهم می کند.
فرمت های داده: JSON یا XML
استفاده از قالب‌های متنی استاندارد، انعطاف‌پذیری گسترده‌ای را در هنگام مصرف منابع به مشتریان ارائه می‌دهد و REST روی HTTP ما را قادر می‌سازد از طیف متنوعی از قالب‌ها استفاده کنیم. اگرچه نمونه‌هایی که من تا به حال نشان داده‌ام از XML استفاده می‌کردند، در حال حاضر JSON به نوع محتوای رایج‌تری برای سرویس‌هایی تبدیل شده است که از طریق HTTP کار می‌کنند.
این واقعیت که JSON فرمت بسیار ساده‌تری است به این معنی است که مصرف نیز آسان‌تر است. برخی از طرفداران همچنین فشردگی نسبی آن را در مقایسه با XML به عنوان یکی دیگر از عوامل برنده ذکر می‌کنند، اگرچه این اغلب یک مشکل دنیای واقعی نیست.
با وجود محبوبیت، JSON دارای چند اشکال است. در حالی که XML کنترل پیوند را به عنوان یک کنترل ابر رسانه ای تعریف می کند، هیچ استانداردی معادل در JSON وجود ندارد. بنابراین، سبک های سفارشی داخلی اغلب برای ترکیب این مفهوم استفاده می شود. برای پرداختن به این مشکل، زبان برنامه کاربردی فرامتن (HAL) برای ایجاد مجموعه‌ای از استانداردهای مشترک برای ابرپیوند در JSON (و XML، اگرچه مسلماً برای XML کمتر ضروری است) ایجاد شده است. رعایت استاندارد HAL امکان استفاده از ابزارهایی مانند مرورگر HAL مبتنی بر وب را برای کاوش کنترل‌های ابررسانه‌ای فراهم می‌کند و فرآیند ایجاد یک کلاینت را ساده می‌کند.
معایب REST بیش از HTTP
یکی از نکات منفی بالقوه استفاده از REST بر روی HTTP عملکرد است که ممکن است برای سرویس‌هایی با نیازهای تاخیر کم نگران کننده باشد. در حالی که REST از فرمت‌های جایگزین مانند JSON یا باینری پشتیبانی می‌کند، HTTP همچنان سربار را برای هر درخواست معرفی می‌کند. علاوه بر این، بارهای REST ممکن است به اندازه پروتکل های باینری مانند Thrift ناب نباشند.
اگرچه HTTP برای مدیریت حجم زیادی از ترافیک مناسب است، اما در مقایسه با پروتکل های دیگر ساخته شده بر روی پروتکل کنترل انتقال (TCP) یا سایر فناوری های شبکه، ممکن است بهترین گزینه برای ارتباطات کم تاخیر نباشد. یکی از این نمونه ها WebSockets است که علیرغم نامش، لزوماً به وب وابسته نیست. هنگامی که دست دادن اولیه HTTP کامل شد، WebSockets صرفاً به عنوان یک اتصال TCP بین مشتری و سرور عمل می‌کند و آن را به روشی بسیار کارآمدتر برای انتقال داده‌ها به مرورگر تبدیل می‌کند. با این حال، توجه به این نکته مهم است که استفاده از WebSocket ها شامل HTTP یا REST زیادی نمی شود.
برای ارتباطات سرور به سرور، اگر تأخیر بسیار کم یا اندازه پیام کوچک مهم است، ارتباطات HTTP به طور کلی ممکن است ایده خوبی نباشد. ممکن است لازم باشد پروتکل های زیربنایی مختلفی مانند پروتکل User Datagram (UDP) را برای دستیابی به عملکرد مورد نظر خود انتخاب کنید و بسیاری از چارچوب های RPC با خوشحالی روی پروتکل های شبکه ای غیر از TCP اجرا می شوند.
برای اطلاعات بیشتر در خبرنامه مشترک شوید:
https://architechinsider.substack.com/
