Pro tyto zdroje, které se v mnohém dokázaly chovat jako běžné aplikace spustitelné na PC, se vžilo pojmenování Rich Internet Applications (RIA). Ale zřejmě to, že je nutné pro zobrazení flashových aplikací instalovat speciální zásuvný modul a že pro vývoj těchto aplikací je nutné vlastnit placenou licenci, zapříčinilo, že Flash byl vždy vnímán jako pouze doplňkový (chcete-li okrášlující či prezentační) prvek na klasických HTML stránkách. Určitá nevýhoda Flashe se také objevila v nesnadné portaci zásuvného modulu na jiná zařízení než klasické prohlížeče na PC (mobilní telefony, PDA). Další technologie, které nebyly příliš úspěšné, jsou aplety napsané v jazyce Java a ActiveX společnosti Microsoft (Loosley, 2006).

Svou roli také zřejmě sehrál vznik open source projektu Mozilla. V roce 1998 jej založil Netscape po krachu svého prohlížeče Netscape Navigator, kdy uvolnil převážnou část zdrojových kódů (které ovšem byly později zcela přepsány). Start projektu Firefox přinesl značné oživení obecného povědomí o W3C standardech. Odborná veřejnost se začala více zajímat, jak jsou jejich stránky zobrazovány. Přibližně ve stejné době zveřejnila skupina W3C jazyk HTML 4.01 a hlavně XHTML, který byl reformulací HTML jazyka za použití XML.

Nic z toho ovšem nespustilo revoluci¹, o které jsme v předchozích kapitolách mluvili jako o Web as Platform. Tím bylo až, jak říká O’Reilly, spuštění dvou aplikací společností Google: Gmail a Google Maps (O’Reilly, 2005b). V těchto aplikacích byl, krom tradičního HTML, spojen jazyk Javascript (na straně klienta) a jazyk XML (na straně serveru). Jazyk Javascript se používá v asynchronním módu pro načítání částí stránky. Tím byla v podstatě poprvé použita sada technologií označená jako Asynchronous Javascript + XML – zkráceně AJAX. Zmíněným asynchronním přístupem se značně snížila doba odezvy RIA aplikací:

• informace jsou načítány ze serveru s předpokladem dalších možných požadavků uživatele (například načítání okolních čtverců zobrazené mapy, aby byl pohyb myší ve všech směrech plynulý),
• prvky na stránce mohou být překresleny po částech namísto nutnosti nového načtení celé stránky,
• vstupy od uživatele je možné serveru posílat v předem zvalidovaných dávkách (validace probíhá pomocí Javascriptu již na straně klienta),
• odezvy na některé vstupy uživatele mohou být generovány bez komunikace se serverem,
• data, která už jednou byla zpracována serverem, mohou být uložena na straně klienta pro pozdější použití.

„AJAX není jedna technologie. Ve skutečnosti je to několik technologií, na sobě nezávislých a samočinných, které při společném nasazení nabízejí další možnosti využití. AJAX zahrnuje:

• na standardech založené zobrazování pomocí XHTML a CSS;
• dynamické zobrazování a interakci pomocí Document Object Model;
• výměnu a manipulaci dat pomocí XML a XSLT;
• asynchronní příjem dat pomocí XMLHttpRequest;
• Javascript, který všechno to spojuje dohromady.“ (Garret, 2005)

Jedna z velkých nevýhod pro uživatele tradičních stránek založených na čistém HTML či XHTML je čas strávený čekáním na načítání stránek poté, co byla vyslána žádost kliknutím na některý prvek na stránce. Jak již bylo zmíněno, během let bylo učiněno několik pokusů přinést stránkám větší dynamiku za použití jednotlivých technologií jako Javascript, skryté rámce, DHTML, kaskádové styly a ActiveX prvku XMLHttpRequest od Microsoftu.

Obrázek 7 – Tradiční komunikace klient–server při načítání webových stránek

Oproti standardnímu modelu komunikace webových aplikací, kde je prohlížeč zodpovědný za iniciaci žádosti webovému serveru a za zpracování odpovědi, AJAX model poskytuje zprostředkující mezivrstvu – AJAX Engine, která zajišťuje tuto komunikaci. AJAX Engine je obyčejně javascriptový objekt volaný¨vždy, kdykoli mají být od serveru přijata další data. To je zásadní rozdíl proti tradičnímu přístupu, kde dojde pouze k poskytnutí odkazu na další (externí) zdroj/URL, jehož načtení musí klient potvrdit (např. uživatel kliká na šipku pro posun mapy). V pojetí AJAXu může být odkaz na zdroj vyvolán a zpracován pomocí AJAX Engine. Požadavek je zpracován asynchronně, což znamená, že požadavek bude vyslán, ale nebude se čekat na odpověď, namísto toho se bude dále provádět kód klienta a odpověď bude zpracována později.

Server, který obyčejně dodává klientům na základě jejich požadavku HTML dokumenty, CSS šablony vzhledu nebo javascriptový kód, je kromě toho nakonfigurován tak, že vrací i data, která umí AJAX Engine interpretovat. Tato data jsou nejčastěji ve formě XML, ale lze použít jakýkoliv jiný formát, který AJAX Engine podporuje.

V okamžiku, kdy obdrží AJAX Engine odpověď ze serveru, může provést příslušnou akci – parsování dat, změnu podoby uživatelského rozhraní či poskytnutí zaslaných informací uživateli. Díky tomu, že tento proces zahrnuje přenos menšího množství informací než tradiční webový aplikační model a uživatelské rozhraní je aktualizováno rychleji a bez nutnosti překreslování celého výsledného aplikačního okna, uživatel může pracovat rychleji (Toth, 2007; Loosley, 2006).

Obrázek 8 – Komunikace klient–server za pomoci AJAXu

V posledních dnech se také velmi živě diskutuje o produktu Silverlight od společnosti Microsoft, který má být konkurencí Adobe Flash.´

Pro názornost si uveďme příklad mikroformátu hCard, který umožňuje vložit osobní nebo organizační kontakt založený na standardu vCard na webovou stránku:

<div class="vcard">
<div class="org">
<div class="organization-name"><strong>IDS Scheer ČR, s.r.o.</strong></div>
</div>
<div class="adr">
<div class="street-address">Vídeňská 55<br />639 00&nbsp;&nbsp;Brno<br /></div>
</div>
<div class="contact">
<dl class="tel">
<dt class="type">Telefon</dt> <dd class="value">+420 543 524 666</dd>
<dt class="type">Fax</dt> <dd class="value">+420 543 524 601</dd>
</dl>
<dl class="web">
<dt>E-Mail</dt><dd class="email"><a class="mail" href="mailto:info-cz@ids-scheer.com">Napište nám<span class="aural">to: IDS Scheer ČR, s.r.o.</span></a></dd>
</dl>
</div>
</div>

Obrázek 9 – Zápis adresních informací v mikroformátu hCard

Výsledné zobrazení mikroformátu na stránkách společnosti IDS Scheer ČR.

Je patrné, že se tento kód v normálním prohlížeči zobrazil zcela běžným způsobem. Větší podpora mikroformátů by měla přijít s novými verzemi prohlížečů Firefox a Internet Explorer – v těch by mělo být možné uložit uváděný příklad adresy rovnou do seznamu kontaktů v e-mailové aplikaci uživatele nebo rovnou zobrazit uvedenou adresu v některé z mapových služeb.

Z dalších mikroformátů můžeme jmenovat kupříkladu hCalendar pro reprezentaci informací o událostech, hResume pro životopisy a XFN (XHML Friends Network) pro zobrazení sociálních relací. Mikroformátů je celá řada a celá řada je ve stadiu připomínkování.
Mikroformáty jsou malinkým krůčkem na cestě k sémantickému webu, jehož vznikající standardy jsou zatím příliš složité pro jednoduché nasazení, ale lze očekávat, že se v součinnosti s rozvojem nových nástrojů s příjemným a jednoduchým uživatelským rozhraním budou objevovat čím dál častěji.

V prostředí webu začaly taková API poskytovat velké servery jako Google a Amazon, u nás začínají s poskytováním firmy Seznam a Atlas. Velmi kvalitní zdroj informací v tomto oboru je Programmable web – nabízí přehled hotových mash-upů, seznam jednotlivých API i možné scénáře užití.

Patrick Zandl uvádí ve svém článku velmi praktický způsob využití API mapového systému: Pokud potřebujete sledovat pohyb flotily svých vozidel, není nic snazšího, než je vybavit modulem pro vysílání GPS souřadnic a napsat pár řádek kódu, který zajistí zobrazení aktuální pozice vozidla na mapovém podkladu (Zandl, 2007).

Pro malé společnosti a jejich vývojáře je výhoda použití API jasná: Zřejmě by nikdy neměli kapacitu ani prostředky na vytvoření takových druhů aplikací, u kterých by jen náklady na zaplacení autorských licenčních poplatků například pro použití kartografických materiálů dokázaly výrazně převýšit jejich rozpočet. Pro velké společnosti jako Google je poskytování API také výhodné – je to pro ně reklama a svým způsobem i upevnění jejich silné pozice na trhu.

Odnoží klasických mash-upů jsou takzvané widgety (v pojetí společnosti Microsoft gadgety). To jsou jednoduché aplikace pro umístění informací (zdrojem dat není nutně web) na pracovní ploše operačního sytému pomocí speciální aplikace (Sidebar ve Windows Vista, Yahoo Widgets anebo Dashboard v MacOS) či v prostředí webu (například speciální widgetové šablony pro systém WordPress).

Zmatek jménem RSS
První pokus s použitím metadat pro syndikaci vyústil ve specifikaci Meta Content Framework firmy Apple, za nímž stál Ramanathan V. Guha. Meta Content Framework byl nasazen v aplikaci ProjectX (HotSauce) pro reprezentaci zdrojů v 3D prostředí. S návratem Steva Jobse do Apple byl tento zajímavý projekt bohužel zastaven.

Guha po zastavení projektu přešel do firmy Netscape, kde se setkal s vývojáři jazyka XML. Výsledkem bylo přepsání Meta Content Framework jako aplikace XML – tak se zrodil základ jazyka pro popis zdrojů – Resource Description Format (RDF), který byl přijat po úplném dopracování konsorciem W3C v roce 1997 jako standard. Přibližně ve stejné době přichází Microsoft se specifikací Channel Definition Format (CDF), který používá ve svém prohlížeči Internet Explorer 4, ale časem technologie upadá v zapomnění.

V roce 1999 firma Netscape vydává první verzi RSS 0.9 (RDF Site Summary), kterou používá ve svém portále My Netscape, tato specifikace byla derivátem jazyka RDF. Záhy je ale přepracována Danem Libbym, který formát zjednodušuje (opouští specifikaci RDF) a přidává části syndikačního formátu, který již dříve na svých stránkách používal David Winer, vzniká tak verze RSS 0.91 (Rich Site Summary). Po akvizici Netscape společností AOL je ale vývoj ze strany této korporace zastaven, dokonce ze stránek Netscape mizí DTD (Document Type Definition) tohoto formátu (později je obnoven).

To vedlo k ustanovení skupiny RSS-DEV, která měla ve vývoji formátu pokračovat. V roce 2000 tato skupina vydává novou verzi RSS 1.0, která se vrací k RDF a šířeji podporuje soubory metadat (Dublin Core). Bohužel tato verze není zpětně kompatibilní s řadou RSS 0.9x. Aby zmatku nebylo málo, Winer oznamuje, že pokračuje ve vývoji řady 0.91, o které tvrdí, že je intelektuálním vlastnictvím jeho společnosti UserLand Software. Z tohoto vývoje vzešlo několik dalších verzí a vyústilo ve vydání RSS 2.0 (Really Simple Syndication), které umožňovalo další rozšíření formátu pomocí XML (Bednář, 2006; Dočekal, 2003).

ATOM
Zmatek v RSS formátech vedl odbornou internetovou veřejnost k názoru, že je potřeba vytvořit nový formát, který by byl nezávislý na jakékoliv společnosti, mohl by být nasazen kýmkoliv, mohl být volně rozšiřitelný a hlavně, který by byl čistě a jasně vymezen . V roce 2003 Sam Ruby (je také autorem programovacího jazyka Ruby, kterému mnozí předpovídají velkou budoucnost na poli internetových aplikací) zřídil v prostředí wiki komunikační platformu pro diskuzi o takovém formátu. Přes počáteční porodní bolesti se zrodil formát ATOM 0.2 rychle následovaný verzí ATOM 0.3, který podpořila společnost Google jeho implementací do svých produktů. V roce 2005 organizace IETF schválila Atom Syndication Format 1.0 jako standard RFC 4287¹.

Hlavními rozdíly oproti RSS je možnost publikace nejen textových (HTML) informací, ale také XML či informací kódovaných pomocí Base-64 (kódování pro binární data, například video, dokumenty atd.).

Ben Hammersley ve své prezentaci pro O’Reilly Emerging Technology Conference zmiňuje také určitou ztrátovost informací při použití RSS. Říká, že v okamžiku publikace zdroje už s určitostí známe jeho název, tvůrce, dobu vzniku, jeho obsah i kde se nachází – není tedy důvod tato data při agregaci nepoužít. Přesně tato pole jsou při použití specifikace ATOM povinná, u RSS 2.0 informace o tvůrci, datu i jednoznačném identifikátoru (URI) v základních povinných polích schází. (Hammersley, 2005).
Zdá se, že v boji formátů dnes přesto vítězí RSS 2.0, i když není výjimkou, že servery zpřístupňují data v několika syndikačních formátech najednou.

Dlužno podotknout, že dnes už je zkratka RSS užívána jako obecné označení syndikace v kterémkoliv formátu.

Agregace obsahu
K masovému rozšíření syndikačních formátů přispěla i možnost agregace poskytovaného obsahu pomocí čteček – tvz. agregátorů (feed aggregators, feed readers). Aplikace v prostředí podobném e-mailovému klientu v určitém intervalu kontrolují, zda na server nepřibyly nové informace. Analogie s e-mailovým klientem není úplně náhodná – syndikační formáty v určitém směru nahradily e-mailové newslettery , které se s nadměrným rozšířením spamu staly jako nástroj pro komunikaci nepoužitelné.

Čtečky mohou stahovat obsah z více možných zdrojů a nabízejí další možnosti jeho filtrování. Tato vlastnost čteček se časem promítla i do samotných serverů – již tam je možné (před)vybrat, které informace budou odebírány. Dnes jsou čtečky zabudovány již do všech hlavních prohlížečů na trhu. Speciální možností jsou webové čtečky, kde se obsah v duchu webu jako platformy agreguje přímo na serveru aplikace. Velmi často jsou tyto čtečky zabudovány do blogovacích aplikací, takže jednotlivé blogy mohou být obohaceny i o informace z jiných zdrojů.

Objevuje se také debata, zda šířit pomocí syndikačních formátů celý obsah (tedy nejen krátký sumář) jednotlivých příspěvků. Plný obsah je pak možné pohodlně číst po stažení i na speciálních zařízeních (mobilní telefony, mp3 přehrávače atd.) v režimu offline. Hlavními argumenty pro jsou velmi snadná navigace a jednotné rozhraní pro čtení příspěvků z jednotlivých zdrojů. Proti stojí vyšší zátěž na připojení serverů (data jsou pravidelně stahována v krátkých intervalech).

Šíření speciálního obsahu
Pro šíření audionahrávek formou syndikačních formátů se vžil název podcasting². Tyto nahrávky mohou být speciální čtečkou (např. Ziepod) staženy a automaticky uloženy do hardwarového mp3 přehrávače³. Analogicky k tomu existují ještě videocasty (je šířeno video) nebo photofeedy (jsou šířeny fotografie).

Feedburner
Feedburner je aplikace pro poskytovatele obsahu ve formě některého ze syndikačních formátů, který znovu publikuje s přidanou hodnotou. Tou je především možnost sledování, kolik lidí je přihlášeno k odběru, automatický ping (viz kapitola o identifikaci blogů) nebo přihlášení k odběru syndikovaného obsahu e-mailem. Je možné také do feedu nechat automaticky přidávat kontextovou reklamu. Pro odběratele pak především naformátování syrového XML feedu do grafické podoby, automatické překódování do různých formátů (RSS vs. Atom) dle aplikace, která si ho vyžádala.
Od roku 2007, kdy byla služba koupena společností Google, jsou její funkce dostupné zdarma. Služba má otevřené API pro možnost využití v dalších aplikacích.

V praxi je nabízeno v aplikacích, které OpenID podporují, formulářové políčko, do kterého se vloží URL s identifikační adresou. Po stisknutí tlačítka k zalogování je uživatel přesměrován k poskytovateli jeho OpenID, kde po zadání hesla potvrdí, že poskytovatel může poskytnout jeho data žádající aplikaci, kam je po potvrzení zpět přesměrován a přihlášen.

Zbývá ještě doplnit tzv. desktop-centric princip, kdy jsou hesla uložena ve speciální aplikaci na uživatelově počítači.