Hypermedia Systems

۱. ابررسانه: معماری قدرتمند و کمتر شناخته‌شده

کنترل‌های ابررسانه همان چیزی است که ابررسانه را از سایر انواع رسانه متمایز می‌کند.

فراتر از اسناد. ابررسانه صرفاً به اسناد پیوندی مانند صفحات HTML محدود نمی‌شود. این یک معماری سیستمی است که رسانه‌ها شامل کنترل‌هایی مانند لینک‌ها و فرم‌ها هستند و امکان تعامل و ناوبری غیرخطی را فراهم می‌آورند. این فراتر از مصرف منفعل است و سیستم‌های پویا را ممکن می‌سازد.

اجزای سیستم. یک سیستم ابررسانه کامل شامل چندین بخش است که با هم کار می‌کنند:

• قالب ابررسانه (HTML، HXML)
• پروتکل شبکه (HTTP)
• سروری که API ابررسانه ارائه می‌دهد
• کلاینتی که ابررسانه را تفسیر می‌کند (مرورگر وب، کلاینت Hyperview)
  قدرت این سیستم در یکپارچگی این اجزا نهفته است، نه فقط در قالب آن.

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

۲. REST به معنای ابررسانه است، نه فقط JSON

اگر موتور وضعیت برنامه (و در نتیجه API) توسط ابرمتن هدایت نشود، نمی‌تواند RESTful باشد و API REST محسوب نمی‌شود. همین.

تعریف فیلدینگ. روی فیلدینگ، که اصطلاح REST را ابداع کرد، معماری وب اواخر دهه ۱۹۹۰ را توصیف کرد که توسط HTML و HTTP هدایت می‌شد. یکی از محدودیت‌های اصلی REST، «رابط یکنواخت» است که شامل «ابررسانه به عنوان موتور وضعیت برنامه» (HATEOAS) می‌شود.

توضیح HATEOAS. این بدان معناست که پاسخ ابررسانه‌ای (مانند HTML) باید تمام اطلاعات لازم برای درک اقدامات و انتقال‌های ممکن توسط کلاینت را در خود داشته باشد.

• لینک‌های HTML (<a>) و فرم‌ها (<form>) کنترل‌های ابررسانه‌ای هستند.
• آن‌ها وضعیت‌های بعدی ممکن (آدرس‌ها و متدها) را مستقیماً رمزگذاری می‌کنند.
• کلاینت (مرورگر) نیازی به دانش قبلی از ساختار API ندارد.

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

۳. برنامه‌های وب ۱.۰ از پیش مبتنی بر ابررسانه بودند

حتی امروز، در دنیای توسعه وب که فریم‌ورک‌های بزرگ جاوااسکریپت محور غالب شده‌اند، بسیاری ترجیح می‌دهند از HTML ساده برای رسیدن به اهداف برنامه خود استفاده کنند و معمولاً از نتایج راضی‌اند.

ساده و قدرتمند. برنامه‌های وب اولیه، که به «وب ۱.۰» یا «برنامه‌های چندصفحه‌ای» (MPA) معروف‌اند، عمدتاً با لینک‌ها و فرم‌های HTML ساخته شده بودند. این دو کنترل ابررسانه‌ای همراه با HTTP، امکانات دینامیکی گسترده‌ای فراهم می‌کردند.

مکانیک اصلی:

• لینک‌ها (<a>) درخواست‌های HTTP GET را برای ناوبری فعال می‌کنند.
• فرم‌ها (<form>) درخواست‌های HTTP GET یا POST را برای ارسال داده و تغییر وضعیت فعال می‌کنند.
• سرور با HTML جدید پاسخ می‌دهد و کل صفحه را جایگزین می‌کند.

طبیعتاً RESTful. این برنامه‌ها به طور طبیعی اصول REST را رعایت می‌کردند. مرورگر به عنوان کلاینت ابررسانه، کنترل‌های HTML را تفسیر می‌کرد تا با سرور تعامل داشته باشد. این رویکرد ساده، مقاوم و بسیار انعطاف‌پذیر نسبت به تغییرات سمت سرور بود.

۴. SPAها و APIهای JSON: مسیری متفاوت و اغلب پیچیده‌تر

برنامه‌هایی که به این سبک ساخته می‌شوند، مبتنی بر ابررسانه نیستند و از سیستم ابررسانه‌ای وب بهره نمی‌برند.

ظهور SPAها. نیاز به تجربه‌های کاربری تعاملی‌تر باعث محبوبیت برنامه‌های تک‌صفحه‌ای (SPA) شد. SPAها با استفاده از جاوااسکریپت، رابط کاربری را در یک صفحه به‌روزرسانی می‌کنند و از بارگذاری کامل صفحه جلوگیری می‌کنند.

تغییر معماری. این رویکرد معمولاً شامل:

• ساخت رابط کاربری و مدیریت وضعیت عمدتاً در جاوااسکریپت سمت کلاینت (مانند React، Vue)
• ارتباط با سرور از طریق فراخوانی‌های AJAX و تبادل داده JSON
• تبدیل HTML به هدف رندرینگ و از دست دادن نقش ابررسانه‌ای آن

پیچیدگی بیشتر. در حالی که UIهای غنی را ممکن می‌سازد، SPAها اغلب پیچیدگی قابل توجهی ایجاد می‌کنند:

• مدیریت وضعیت سمت کلاینت و همگام‌سازی با سرور
• پیاده‌سازی مسیریابی و منطق رندرینگ سمت کلاینت
• مواجهه با «خستگی جاوااسکریپت» به دلیل ابزارها و وابستگی‌های پیچیده
  این معماری شبیه مدل‌های کلاینت ضخیم قدیمی است و از سیستم ابررسانه‌ای بومی وب فاصله می‌گیرد.

۵. Htmx: گسترش HTML برای برنامه‌های ابررسانه‌ای مدرن

Htmx یک کتابخانه جاوااسکریپت است که HTML را دقیقاً به این شکل گسترش می‌دهد و موضوع چند فصل بعدی این کتاب خواهد بود.

پل زدن شکاف. Htmx کتابخانه‌ای کوچک و بدون وابستگی است که HTML را به عنوان یک ابررسانه گسترش می‌دهد. این امکان را به توسعه‌دهندگان می‌دهد تا رابط‌های کاربری تعاملی مدرن بسازند بدون اینکه معماری ابررسانه‌ای وب را رها کنند.

مبتنی بر ابررسانه. Htmx از جاوااسکریپت برای جایگزینی HTML استفاده نمی‌کند، بلکه قابلیت‌های آن را تقویت می‌کند. این کتابخانه محدودیت‌های HTML ساده را با امکان:

• فعال‌سازی درخواست‌های HTTP توسط هر عنصر
• فعال‌سازی درخواست‌ها توسط هر رویداد DOM
• دسترسی به تمام متدهای HTTP (GET، POST، PUT، PATCH، DELETE)
• به‌روزرسانی بخش‌های خاص صفحه (ترانزکلوژن) به جای بارگذاری کامل صفحه
  رفع می‌کند.

رویکرد اعلامی. Htmx این کار را از طریق مجموعه‌ای از ویژگی‌های HTML با پیشوند hx- انجام می‌دهد. این باعث می‌شود تعریف رفتار نزدیک به عنصر HTML باشد و «محلی بودن رفتار» را بر جداسازی سخت مسئولیت‌ها ترجیح دهد.

۶. ویژگی‌های اعلامی، تعاملات Htmx را قدرتمند می‌کنند

Htmx HTML را به عنوان یک ابررسانه گسترش می‌دهد و طراحی شده تا این گسترش تا حد امکان طبیعی و سازگار با مفاهیم موجود HTML باشد.

مبتنی بر ویژگی‌ها. عملکرد اصلی Htmx از طریق ویژگی‌های اعلامی HTML ارائه می‌شود که شبیه به کنترل‌های بومی HTML مانند href و action است. این باعث می‌شود Htmx به عنوان توسعه‌ای طبیعی از زبان HTML احساس شود.

ویژگی‌های کلیدی:

• hx-get، hx-post، hx-put، hx-patch، hx-delete: مشخص کردن متد HTTP و آدرس URL برای درخواست فعال‌شده توسط عنصر
• hx-trigger: تعریف رویداد(های) DOM که درخواست را آغاز می‌کنند (مقدار پیش‌فرض بسته به عنصر متفاوت است)
• hx-target: مشخص کردن عنصری که محتوای آن توسط پاسخ به‌روزرسانی می‌شود
• hx-swap: کنترل نحوه جایگزینی یا تعامل محتوای پاسخ با محتوای عنصر هدف (مثلاً innerHTML، outerHTML، afterbegin)

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

۷. بهره‌گیری از هدرها و رویدادهای HTTP برای رابط‌های پویا

Htmx از این ویژگی HTTP بهره می‌برد و هدرهای اضافی و در نتیجه زمینه بیشتری به درخواست‌های HTTP خود اضافه می‌کند.

ارتباط پیشرفته. Htmx ارتباط استاندارد HTTP بین کلاینت و سرور را گسترش می‌دهد. هدرهای خاصی مانند HX-Request و HX-Trigger را اضافه می‌کند تا زمینه‌ای درباره درخواست AJAX به سرور ارائه دهد.

کنترل سمت سرور. سرور می‌تواند این هدرها را بخواند تا:

• تشخیص دهد آیا درخواست از Htmx است یا ناوبری معمولی مرورگر
• فقط قطعات HTML مورد نیاز برای به‌روزرسانی را به صورت شرطی رندر کند
• منطق متفاوتی بر اساس عنصر یا رویداد فعال‌کننده پیاده‌سازی کند

معماری مبتنی بر رویداد. Htmx همچنین رویدادهای سفارشی را منتشر و گوش می‌دهد:

• رویدادهایی در طول چرخه درخواست مانند htmx:configRequest و htmx:afterRequest فعال می‌کند
• سرور می‌تواند رویدادهای سمت کلاینت را از طریق هدر پاسخ HX-Trigger فعال کند
• این امکان به‌روزرسانی‌های جداشده و تعاملات پیچیده بین عناصر مختلف صفحه را فراهم می‌آورد.

۸. اسکریپت‌نویسی، تقویت‌کننده است نه جایگزین ابررسانه

هدف Htmx کاهش کد نیست، بلکه کدی خواناتر و سازگارتر با ابررسانه است.

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

محدودیت‌های اسکریپت‌نویسی سازگار با ابررسانه:

• قالب اصلی داده‌های مبادله شده همچنان ابررسانه (HTML/HXML) باقی می‌ماند.
• وضعیت سمت کلاینت خارج از DOM به حداقل می‌رسد.

ابزارهای مناسب. چند گزینه اسکریپت‌نویسی با این فلسفه همسو هستند:

• VanillaJS (جاوااسکریپت ساده) ساختار یافته با اصولی مانند محلی بودن رفتار (LoB) و ویژگی‌های داده (RSJS)
• Alpine.js: کتابخانه‌ای برای افزودن رفتار مستقیم در HTML با اتصال داده واکنشی
• _hyperscript: زبانی طراحی شده همراه با Htmx، متمرکز بر دستکاری DOM مبتنی بر رویداد با نحو شبیه زبان انگلیسی

تمرکز بر تعامل. اسکریپت‌نویسی در برنامه‌های ابررسانه‌ای بهترین کاربرد را در طراحی تعامل (انیمیشن‌ها، منطق محلی UI) دارد، در حالی که منطق کسب‌وکار و ارائه در سرور باقی می‌ماند. این سرور را به منبع حقیقت تبدیل می‌کند و کلاینت را ساده‌تر می‌سازد.

۹. APIهای داده JSON نیازهای متفاوتی نسبت به APIهای ابررسانه دارند

APIهای JSON ده سال پس از REST به عنوان ابزاری رایج در توسعه وب ظاهر شدند؛ REST درباره ابررسانه و نسخه ۱.۰ وب بود.

اهداف متفاوت. در حالی که API ابررسانه‌ای (مانند HTML روی HTTP) برای تعامل با کلاینت ابررسانه‌ای (مانند مرورگر) ایده‌آل است، APIهای داده JSON برای موارد استفاده متفاوتی طراحی شده‌اند.

موارد استفاده APIهای JSON:

• برنامه‌های موبایل (به‌ویژه غیر Hyperview)
• اسکریپت‌های خودکار و پردازش داده‌های حجیم
• یکپارچه‌سازی‌های شخص ثالث و همگام‌سازی داده‌ها

نیازهای متمایز. APIهای JSON معمولاً به:

• ثبات و نسخه‌بندی (کلاینت‌ها به ساختار وابسته‌اند)
• محدودیت نرخ و مکانیزم‌های احراز هویت قوی (معمولاً مبتنی بر توکن)
• نقاط انتهایی عمومی برای نیازهای داده‌ای گسترده
  نیاز دارند.

تکامل جداگانه. جدا نگه داشتن APIهای داده JSON از API ابررسانه‌ای اجازه می‌دهد هرکدام بر اساس نیازهای خود تکامل یابند. API ابررسانه‌ای می‌تواند برای UI برنامه تخصصی باشد، در حالی که API داده برای کلاینت‌های برنامه‌نویسی متنوع پایدار باقی می‌ماند.

۱۰. ابررسانه برای موبایل هم کار می‌کند: معرفی Hyperview

ابررسانه یک مفهوم کلی است و می‌تواند در همه انواع پلتفرم‌ها و برنامه‌ها به کار رود.

چالش‌های موبایل. توسعه سنتی موبایل بومی معمولاً به معماری کلاینت ضخیم منجر می‌شود که منطق در کلاینت و سرور پراکنده است، مشابه SPAها. این باعث پیچیدگی کد و مشکلات تغییر API می‌شود.

راه‌حل ابررسانه‌ای. به‌کارگیری معماری ابررسانه در موبایل راه‌حلی ارائه می‌دهد. سرور کنترل وضعیت برنامه را در دست دارد، کلاینت ساده می‌شود و مشکلات نسخه‌بندی API برطرف می‌گردد.

سیستم Hyperview. Hyperview یک سیستم ابررسانه‌ای مخصوص موبایل است که شامل:

• HXML: قالب ابررسانه‌ای مبتنی بر XML برای تعریف رابط‌های موبایل
• کلاینت Hyperview: کلاینت موبایل بومی (React Native) که HXML را رندر می‌کند

فراتر از وب‌ویوها. در حالی که جاسازی وب‌ویو ساده است، نمی‌تواند الگوهای UX بومی موبایل (ناوبری، ژست‌ها) را به خوبی بازتولید کند. Hyperview برای نمایش این الگوها به صورت بومی طراحی شده است.

۱۱. HXML و رفتارها: تعاملات ابررسانه‌ای بومی موبایل

HXML طوری طراحی شده که برای توسعه‌دهندگان وب که با HTML آشنا هستند، حس آشنایی داشته باشد.

قالب مبتنی بر XML. HXML از نحو XML مشابه HTML استفاده می‌کند که برای توسعه‌دهندگان وب قابل دسترس و با قالب‌سازی سمت سرور سازگار است. شامل عناصری برای الگوهای رایج UI موبایل مانند فهرست‌ها (<list>, <item>) و ورودی‌ها (<text-field>, <select-single>) است.

رفتارها برای تعامل. تعاملات HXML با استفاده از عناصر <behavior> تعریف می‌شوند که محرک‌ها و اقدامات را از هم جدا می‌کنند:

• trigger: تعامل کاربر (مثلاً press، longPress، visible، refresh)
• action: عملیات نتیجه (مثلاً push، back، replace-inner، append، alert، share)
• href: آدرس URL برای اقداماتی که نیاز به محتوای جدید دارند
• target: شناسه عنصری که برای به‌روزرسانی تغییر می‌کند

الگوهای بومی. رفتارها امکان تعاملات خاص موبایل مانند:

• ناوبری مبتنی بر پشته (push، back، new، close)
• کشیدن برای تازه‌سازی (refresh trigger)
• پیمایش بی‌نهایت (visible trigger، append action)
  را فراهم می‌کنند.

قابلیت توسعه. HXML و کلاینت Hyperview طوری طراحی شده‌اند که با عناصر و اقدامات سفارشی قابل گسترش باشند و توسعه‌دهندگان بتوانند ویژگی‌های منحصر به فرد اضافه کنند بدون نیاز به اسکریپت‌نویسی امری برای منطق اصلی.

۱۲. برنامه‌های ابررسانه‌ای، قدرت و سادگی سمت سرور را به حداکثر می‌رسانند

یکی از مزایای بزرگ رویکرد مبتنی بر ابررسانه این است که محیط سمت سرور را هنگام ساخت برنامه وب بسیار مهم‌تر می‌کند.

سرور به عنوان هسته. در برنامه‌های ابررسانه‌ای، سرور موتور اصلی وضعیت برنامه و منطق ارائه است. این از بلوغ و قدرت محیط‌های سمت سرور بهره می‌برد.

مزایای تمرکز بر سرور:

• دسترسی به موتورهای قالب‌سازی

آخرین به‌روزرسانی:: May 11, 2025