Hypermedia Systems

1. Hypermedia: Potężna, lecz niedoceniana architektura

To właśnie kontrolki hypermedialne odróżniają hypermedia od innych rodzajów mediów.

Więcej niż dokumenty. Hypermedia to coś więcej niż tylko połączone ze sobą dokumenty, takie jak strony HTML. To architektura systemu, w której media zawierają kontrolki (np. linki i formularze) umożliwiające nieliniową interakcję i nawigację. To wykracza poza bierne konsumowanie treści, pozwalając na tworzenie dynamicznych systemów.

Elementy systemu. Kompletny system hypermedialny składa się z kilku współdziałających części:

• formatu hypermedialnego (HTML, HXML),
• protokołu sieciowego (HTTP),
• serwera udostępniającego API hypermedialne,
• klienta interpretującego hypermedia (przeglądarka internetowa, klient Hyperview).
  To właśnie zintegrowany system, a nie sam format, stanowi o jego sile.

Współczesne znaczenie. Mimo że hypermedia są powszechne w sieci, jako koncepcja architektoniczna często bywają dziś pomijane, zwłaszcza przez programistów skupionych na frameworkach po stronie klienta. Pełne zrozumienie systemu ujawnia jego potencjał do budowania solidnych i elastycznych aplikacji.

2. REST to hypermedia, nie tylko JSON

Jeśli silnik stanu aplikacji (a więc i API) nie jest napędzany przez hipertekst, to nie może być RESTful i nie jest API REST. Koniec dyskusji.

Definicja Fieldinga. Roy Fielding, twórca terminu REST, opisał architekturę sieci z końca lat 90., opartą na HTML wymienianym przez HTTP. Jednym z kluczowych ograniczeń REST jest „jednolity interfejs”, w tym „Hypermedia jako silnik stanu aplikacji” (HATEOAS).

Wyjaśnienie HATEOAS. Oznacza to, że odpowiedź hypermedialna (np. HTML) powinna zawierać wszystkie niezbędne informacje, by klient mógł zrozumieć dostępne akcje i przejścia.

• Linki HTML (<a>) i formularze (<form>) to kontrolki hypermedialne.
• Kodują one bezpośrednio możliwe kolejne stany (adresy URL, metody).
• Klient (przeglądarka) nie musi znać struktury API z góry.

JSON API są inne. Większość współczesnych API JSON nie posiada kontrolek hypermedialnych. Zwracają surowe dane, wymagając od klienta znajomości, jakie adresy i metody wywołać dalej. To ścisłe powiązanie czyni je API danych, a nie RESTful Hypermedia API, mimo powszechnego nadużywania terminu „REST” w branży.

3. Aplikacje Web 1.0 już były napędzane hypermedialnie

Nawet dziś, w świecie rozwoju webu zdominowanym przez duże frameworki JavaScript po stronie klienta, wiele osób wybiera prosty, klasyczny HTML, osiągając zamierzone cele i często będąc zadowolonym z efektów.

Proste i potężne. Wczesne aplikacje internetowe, zwane „Web 1.0” lub „aplikacjami wielostronicowymi” (MPA), budowano głównie za pomocą linków i formularzy HTML. Te dwie kontrolki hypermedialne, w połączeniu z HTTP, umożliwiały ogromną funkcjonalność dynamiczną.

Podstawowe mechanizmy:

• Linki (<a>) wywołują żądania HTTP GET do nawigacji.
• Formularze (<form>) wywołują żądania HTTP GET lub POST do przesyłania danych i zmiany stanu.
• Serwer odpowiada nowym HTML-em, zastępując całą stronę.

Naturalnie RESTful. Te aplikacje z natury przestrzegały zasad REST. Przeglądarka jako klient hypermedialny interpretowała kontrolki HTML, by komunikować się z serwerem. To podejście było proste, solidne i bardzo elastyczne wobec zmian po stronie serwera.

4. SPA i JSON API: inna droga, często bardziej skomplikowana

Aplikacje zbudowane w tym stylu nie są napędzane hypermedialnie: nie wykorzystują podstawowego systemu hypermedialnego sieci.

Wzrost popularności SPA. Rosnące zapotrzebowanie na interaktywne doświadczenia użytkownika doprowadziło do popularności aplikacji jednostronicowych (SPA). SPA używają JavaScriptu do bezpośredniej aktualizacji interfejsu w obrębie jednej strony, unikając pełnych przeładowań.

Zmiana architektury. Podejście to zwykle polega na:

• Budowaniu UI i zarządzaniu stanem głównie w JavaScript po stronie klienta (np. React, Vue).
• Komunikacji z serwerem przez wywołania AJAX, zwykle wymieniając dane JSON.
• HTML staje się jedynie celem renderowania, tracąc funkcję hypermedialną.

Większa złożoność. Choć umożliwiają bogate UI, SPA często wprowadzają znaczną złożoność:

• Zarządzanie stanem klienta i jego synchronizacja z serwerem.
• Implementacja routingu i logiki renderowania po stronie klienta.
• Radzenie sobie z „zmęczeniem JavaScriptem” wynikającym z rozbudowanych narzędzi i zależności.
  Ta architektura przypomina starsze modele grubych klientów, oddalając się od natywnego systemu hypermedialnego sieci.

5. Htmx: rozszerzenie HTML dla nowoczesnych HDAs

Htmx to biblioteka JavaScript, która rozszerza HTML właśnie w ten sposób i będzie tematem kolejnych rozdziałów tej książki.

Łączenie światów. Htmx to niewielka, pozbawiona zależności biblioteka JavaScript, zaprojektowana do rozszerzania HTML jako hypermediów. Pozwala programistom tworzyć nowoczesne, interaktywne interfejsy bez rezygnacji z podstawowej architektury hypermedialnej sieci.

Zorientowana na hypermedia. Htmx używa JavaScriptu nie do zastępowania, lecz do wzbogacania możliwości HTML. Przezwycięża ograniczenia czystego HTML, umożliwiając:

• Wywoływanie żądań HTTP z dowolnego elementu.
• Wyzwalanie żądań na dowolne zdarzenia DOM.
• Dostęp do wszystkich metod HTTP (GET, POST, PUT, PATCH, DELETE).
• Aktualizację wybranych fragmentów strony (transkluzja) zamiast pełnych przeładowań.

Deklaratywne podejście. Htmx realizuje to za pomocą zestawu atrybutów HTML (z prefiksem hx-). Dzięki temu definicja zachowania pozostaje blisko elementu, którego dotyczy, promując lokalność zachowania zamiast ścisłego rozdzielenia obowiązków.

6. Deklaratywne atrybuty napędzają interakcje Htmx

Htmx rozszerza HTML jako hypermedia i jest zaprojektowany tak, by to rozszerzenie było naturalne i spójne z istniejącymi koncepcjami HTML.

Sterowanie atrybutami. Podstawowa funkcjonalność Htmx jest dostępna przez deklaratywne atrybuty HTML, naśladujące styl natywnych kontrolek jak href czy action. Dzięki temu htmx wydaje się naturalnym rozszerzeniem języka.

Kluczowe atrybuty:

• hx-get, hx-post, hx-put, hx-patch, hx-delete: określają metodę HTTP i URL żądania wywoływanego przez element.
• hx-trigger: definiuje, które zdarzenie DOM inicjuje żądanie (domyślnie zależnie od elementu).
• hx-target: wskazuje element, którego zawartość zostanie zaktualizowana odpowiedzią.
• hx-swap: kontroluje sposób zastępowania lub łączenia zawartości elementu docelowego (np. innerHTML, outerHTML, afterbegin).

Proste i potężne. Te atrybuty pozwalają na złożone interakcje, takie jak aktualizacje w miejscu, aktywne wyszukiwanie czy leniwe ładowanie, przy minimalnym lub zerowym użyciu imperatywnego JavaScriptu. Zachowanie definiuje się bezpośrednio na elemencie, co poprawia czytelność i łatwość utrzymania.

7. Wykorzystanie nagłówków HTTP i zdarzeń dla dynamicznych UI

Htmx korzysta z tej cechy HTTP i dodaje własne nagłówki, dostarczając dodatkowy kontekst do żądań HTTP.

Wzbogacona komunikacja. Htmx rozszerza standardową komunikację HTTP między klientem a serwerem. Dodaje specyficzne nagłówki żądań (np. HX-Request, HX-Trigger), które przekazują serwerowi informacje o charakterze żądania AJAX.

Kontrola po stronie serwera. Serwer może odczytywać te nagłówki, by:

• Rozpoznać, czy żądanie pochodzi od htmx, czy jest standardową nawigacją przeglądarki.
• Warunkowo renderować tylko potrzebne fragmenty HTML do aktualizacji.
• Stosować różną logikę w zależności od elementu lub zdarzenia wyzwalającego.

Architektura oparta na zdarzeniach. Htmx emituje i nasłuchuje na niestandardowe zdarzenia:

• Wyzwala zdarzenia w trakcie cyklu żądania (htmx:configRequest, htmx:afterRequest).
• Serwer może inicjować zdarzenia po stronie klienta przez nagłówek odpowiedzi HX-Trigger.
• Umożliwia to luźne powiązania i złożone interakcje między różnymi elementami strony.

8. Skrypty wzbogacają, nie zastępują hypermedia

Celem htmx nie jest mniej JavaScriptu, lecz mniej kodu, bardziej czytelnego i przyjaznego hypermedialnie.

Skrypty są dozwolone. Roy Fielding zauważył, że REST dopuszcza kod na żądanie (scripting). W HDAs skrypty są mile widziane, ale powinny wzmacniać model hypermedialny, a nie go zastępować.

Zasady przyjaznego skryptowania:

• Główny format wymiany danych pozostaje hypermedialny (HTML/HXML).
• Stan po stronie klienta poza DOM jest minimalizowany.

Narzędzia zgodne z filozofią:

• VanillaJS (czysty JavaScript) z zasadami takimi jak Lokalność Zachowania (LoB) i atrybuty danych (RSJS).
• Alpine.js: biblioteka do dodawania zachowań bezpośrednio w HTML z reaktywnym wiązaniem danych.
• _hyperscript: język stworzony wraz z htmx, skupiony na zdarzeniowej manipulacji DOM z anglojęzyczną składnią.

Skupienie na interakcji. Skrypty w HDAs najlepiej służą do projektowania interakcji (animacje, lokalna logika UI), podczas gdy logika biznesowa i prezentacyjna pozostaje na serwerze. To utrzymuje serwer jako źródło prawdy i upraszcza klienta.

9. JSON Data API spełniają inne potrzeby niż Hypermedia API

JSON API pojawiły się dekadę po tym, jak REST był koncepcją hypermedialną i wersją 1.0 sieci.

Różne cele. Podczas gdy Hypermedia API (np. HTML przez HTTP) jest idealne do interakcji z klientem hypermedialnym (jak przeglądarka), JSON Data API służą innym zastosowaniom.

Przykłady zastosowań JSON API:

• Aplikacje mobilne (zwłaszcza nie-Hyperview).
• Skrypty automatyczne i przetwarzanie hurtowe danych.
• Integracje zewnętrzne i synchronizacja danych.

Specyficzne wymagania. JSON API zwykle potrzebują:

• Stabilności i wersjonowania (klienci są ściśle powiązani ze strukturą).
• Ograniczeń liczby wywołań i solidnych mechanizmów uwierzytelniania (często tokenowych).
• Ogólnych punktów końcowych obsługujących szerokie potrzeby danych.

Oddzielna ewolucja. Oddzielenie JSON Data API od Hypermedia API pozwala każdemu rozwijać się zgodnie z własnymi potrzebami. Hypermedia API może być wysoce wyspecjalizowane pod UI aplikacji, a Data API pozostaje stabilne dla różnorodnych klientów programistycznych.

10. Hypermedia działa także na urządzeniach mobilnych: wprowadzenie Hyperview

Hypermedia to ogólna koncepcja, którą można stosować na wszystkich platformach i w różnych aplikacjach.

Wyzwania mobilne. Tradycyjny natywny rozwój mobilny często prowadzi do architektur grubych klientów z logiką rozproszoną między klientem a serwerem, podobnie jak SPA. Skutkuje to złożonym kodem i problemami z utrzymaniem API.

Rozwiązanie hypermedialne. Zastosowanie architektury hypermedialnej na urządzeniach mobilnych oferuje wyjście z tego impasu. Serwer kontroluje stan aplikacji, upraszczając klienta i eliminując problemy z wersjonowaniem API.

System Hyperview. Hyperview to system hypermedialny dedykowany mobilności, składający się z:

• HXML: formatu hypermedialnego opartego na XML do definiowania UI mobilnego.
• Klienta Hyperview: natywnego klienta mobilnego (React Native) renderującego HXML.

Więcej niż webview. Choć osadzenie webview jest proste, trudno w nim odtworzyć natywne wzorce UX mobilne (nawigacja, gesty). Hyperview jest zaprojektowany, by reprezentować te wzorce natywnie.

11. HXML i zachowania: natywne interakcje hypermedialne na mobilnych

HXML został zaprojektowany tak, by był znajomy dla web developerów, przyzwyczajonych do pracy z HTML.

Format oparty na XML. HXML używa składni XML podobnej do HTML, co ułatwia dostęp web developerom i współpracę z szablonami po stronie serwera. Zawiera elementy dla typowych wzorców UI mobilnego, jak listy (<list>, <item>) i pola wejściowe (<text-field>, <select-single>).

Zachowania dla interakcji. Interakcje w HXML definiuje się za pomocą elementów <behavior>, oddzielając wyzwalacze od akcji.

• trigger: interakcja użytkownika (np. press, longPress, visible, refresh).
• action: wynikowa operacja (np. push, back, replace-inner, append, alert, share).
• href: URL dla akcji wymagających nowej zawartości.
• target: ID elementu do modyfikacji przy aktualizacjach.

Natywne wzorce. Zachowania umożliwiają mobilne interakcje, takie jak:

• Nawigacja oparta na stosie (push, back, new, close).
• Odświeżanie przez pociągnięcie (refresh).
• Nieskończone przewijanie (visible trigger, append action).

Rozszerzalność. HXML i klient Hyperview są zaprojektowane do rozszerzania o niestandardowe elementy i akcje, pozwalając programistom dodawać unikalne funkcje bez konieczności imperatywnego skryptowania logiki podstawowej.

12. HDAs maksymalizują siłę i prostotę po stronie serwera

Wielką zaletą podejścia hypermedialnego jest to, że znacznie zwiększa znaczenie środowiska po stronie serwera przy budowie aplikacji webowej.

Serwer jako rdzeń. W HDAs serwer jest głównym silnikiem stanu aplikacji i logiki prezentacji. Wykorzystuje to dojrzałość i moc środowisk serwerowych.

Korzyści z koncentracji na serwerze:

• Dostęp do potężnych silników szablonów do renderowania HTML/HXML.
• Bezpośredni dostęp do bazy danych dla efektywnych zapytań i logiki.
• Dojrzałe narzędzia organizacji kodu (MVC, moduły).
• Uproszczona logika klienta, zmniejszająca złoż