Bakalarska prace - Unicorn College

unicorn college
Katedra informačních technologií
bakalářská práce
Moderní webové aplikace – „Mashupy“
Autor BP: Michal Brauner
Vedoucí BP: Ing. Tomáš Holas
2012 Praha
Čestné prohlášení
Prohlašuji, že jsem svou bakalářskou práci na téma Moderní webové aplikace – „Mashupy“ vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury
a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury
a použitých zdrojů.
Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením
jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení
§11 a následujících autorského zákona č. 121/2000 Sb.
V Praze dne 16. srpna 2012
Michal Brauner
Poděkování
Děkuji vedoucímu bakalářské práce Tomáši Holasovi za účinnou metodickou, pedagogickou
a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Moderní webové aplikace – „Mashupy“
Modern web applications – „Mashups“
6
Abstrakt
Práce se zabývá moderními webovými aplikacemi a to především mashupy. Text je rozdělen
do dvou hlavních částí – teoretické a praktické. Cílem teoretické části je seznámit čtenáře
s pojmem mashup, historickým vývojem webových aplikací a jejich postupnou proměnou do
podoby, v jaké je známe dnes. Jakožto hlavní nástroj mashupů jsou v této části také podrobněji
rozebrány webové služby. Jsou zde popsány nejdůležitější technologie, protokoly a formáty,
se kterými se vývojář běžně setkává. Následuje úvod do několika oblíbených webových služeb a krátký popis tří vybraných mashupů. V praktické části je podrobně popsána aplikace
MyPlaces. Součástí popisu je vysvětlení datového modelu, popis struktury aplikace a také
způsob propojení s jednotlivými webovými službami. V této části je také popsáno nastavení
rozhraní na straně webových služeb.
Klíčová slova: webová aplikace, mashup, webová služba, sociální síť, Google Maps,
Picasa Web Albums, Facebook, Twitter, Google+
Abstract
The thesis deals with modern web applications, mashups in particular. The text is divided
into two main parts – the theoretical and practical one. The goal of the theoretical part is to
inform the reader about the term “mashup”, historical development of web applications and
their gradual transformation into the present form. Web services, as the main tool of mashups,
are analysed in this part in detail. The most important technologies, protocols and formats,
which a developer usually works with, are described here. It is followed by an introduction
into some of the popular web services and brief description of three selected mashups. In the
practical part, the MyPlaces application is described in detail. The description includes also
the explanation of a data model, description of the structure of the application as well as its
link to individual web services. This part also describes the setup of the interface on the part
of web services.
Keywords: web application, mashup, web service, social network, Google Maps,
Picasa Web Albums, Facebook, Twitter, Google+
7
Obsah
1 Úvod
10
2 Teoretická část
11
2.1
Co to je mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.1
Rozdělení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.1.2
Využívané technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
Technologie webových služeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.1
Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.2
XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.3
SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3.4
REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.5
JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.6
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.7
RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.8
ATOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Oblíbené webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4.1
Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.4.2
Picasa Web Albums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.4.3
Facebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Příklady mashupů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5.1
Flightradar24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5.2
Monniter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.5.3
Earth Album . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.4
2.5
3 Praktická část
29
3.1
Aplikace MyPlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
Technický pohled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.1
Využité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.2
Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.3
Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Propojení s externími aplikacemi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.3.1
Google Picasa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.3.2
Facebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.3
8
3.3.3
3.4
Twitter, Google+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Zhodnocení aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4 Závěr
53
5 Conclusion
54
Literatura
55
Seznam obrázků
59
Seznam příloh
60
9
1 Úvod
Tato bakalářská práce si klade za cíl přiblížit pojem „mashup“ a to v souvislosti s webovými
aplikacemi. Jedná se o relativně nový pojem, který se začal objevovat během posledního desetiletí a označuje speciální typ webových aplikací, které využívají pro svou funkčnost dvě
a více webových služeb. Mashupy jsou založené na webových službách, které byly dlouhou
dobu doménou interních informačních systémů. To se ale změnilo během posledních let, kdy
vývoj webových aplikací a služeb prošel (a stále prochází) dramatickým vývojem. Vzniká
velké množství služeb a jejich veřejné rozhraní je k dispozici vývojářům, kteří můžou tyto
služby libovolně kombinovat a vytvářet tak rozmanité aplikace. Během posledních let vznikají nové datové formáty pro komunikaci mezi aplikacemi a to především za účelem zjednodušit vývojářům práci s daty v různých programovacích jazycích a usnadnit jejich přenos
mezi systémy. Významnou změnou ve vývoji webových aplikací je také práce se sémantikou (významem) dat a jejich propojení se sociálními sítěmi. Toto je významné především při
budování komunity uživatelů.
V posledních letech se objevilo velké množství různých technologií pro práci s webovými službami. Nejvýraznějšími tahouny na poli webových služeb jsou velké internetové společnosti, mezi které patří Google, Amazon, Facebook, Twitter. I díky stále se zlepšující kvalitě
připojení k Internetu a zvětšující se přenosové kapacitě není dnes již potřeba klást velký důraz
na minimalizaci počtu požadavků klienta na server. V dnešních aplikacích probíhá komunikace se vzdálenými službami na pozadí a to v závislosti na akcích uživatele. Stránky bývají
velice interaktivní.
V rámci mojí práce se zaměřím na problematiku mashupů nejprve z teoretického pohledu a v druhé části této práce se budu zabývat popisem jednoduché webové aplikace a mashupu. Aplikace bude kombinovat data z několika webových služeb – mapových podkladů
Google Maps, obrázků Picasa Web Albums, sociálních sítí Facebook, Twitter a Google+.
Cílem této aplikace bude poskytnout uživatelům prostředí, kde budou moci publikovat fotogalerie a přiřazovat je na konkrétní místo na mapě. Místa potom můžou sdílet na sociálních
sítích, vyhledávat a filtrovat mapu podle různých kritérií.
10
2 Teoretická část
2.1 Co to je mashup
Termín mashup charakterizuje internetovou stránku, která využívá data a služby z jiných
zdrojů a díky kombinaci těchto zdrojů se autor snaží vytvořit novou a inovativní webovou
aplikaci [34]. Vzhledem k novému chápání významu webu, ne jako pouhé webové stránky,
ale jako interaktivního prostředí, dochází k celkové proměně webu. Aplikace se zaměřují na
uživatele, poskytují mu vysoký stupeň interaktivity a poskytují přehledné ovládání. Tato etapa
vývoje webu se považuje za druhou éru ve vývoji webu a často bývá označována neoficiálním termínem Web 2.0. Obsah webové aplikace bývá často tvořen samotnými uživateli, kteří
jej například můžou mezi sebou sdílet a vytvářet tak webové komunity. V rámci vlastností
stránek, které spadají do označení Web 2.0 a moderních aplikací obecně, můžeme definovat
dvě charakteristiky, kterými se současné webové aplikace odlišují od aplikací vytvořených
v devadesátých letech – důležitost dat a význam uživatelské komunity [23, s. 15].
Proč jsou data tak důležitá a proč chtějí velcí hráči na trhu, jako je například Google
nebo Amazon zpřístupňovat svá data pro veřejnost? Pěkný příklad uvedený v knize Programujeme mashup aplikace pro Web 2.0 v PHP [23, s. 15] by měl na tuto otázku odpovědět. Internetový gigant Amazon, zabývající se prodejem zboží přes Internet, vytvořil webovou službu umožňující vývojářům integrovat na své stránky funkci nakupování přes Internet.
Tímto otevřel brány do světa online nakupování malým vývojářům a zároveň si vytvořil nový
prodejní kanál. A to pouhým vytvořením aplikačního rozhraní ke svému systému a jeho poskytnutím veřejnosti. Amazon tímto získá další zákazníky, udělá si reklamu a tvůrce webové
aplikace dostane za každý uskutečněný obchod malou provizi. Standardní internetové obchody, které takovou službu neprovozují, se omezují pouze na zákazníky, kteří přijdou na
jejich portál a provedou zde nákup. Jejich objem prodejních kanálů nemá takový potenciál
růstu jako v případě Amazonu.
Druhou charakteristikou jsou uživatelské komunity [23, s. 15]. Vzhledem k vývoji
v posledních letech se stále více ukazuje, jak moc jsou důležitá data vytvořená samotnými
uživateli a jak podstatný je způsob využívání těchto dat. Ukázalo se, že například pouhé zobrazování uživatelských recenzí nestačí, je potřeba uživatele podnítit k vytvoření komunity lidí,
která se na webovou aplikaci bude stále vracet a případně bude dále růst. Vzorovou ukázkou
takové komunity uživatelů je Facebook, který se díky svým funkcím na sdílení mezi přáteli,
možnosti sdílet stránky, označovat co se uživatelům líbí a spoustě dalších funkcí stal globál-
11
ním hráčem na poli sociálních sítí. Jeho globální velikost dokládají i statistiky publikované
na jeho oficiálních stránkách [4]: na konci března 2012 měl celkem 901 milionů aktivních
uživatelů, z toho 526 milionů uživatelů aktivních denně.
2.1.1 Rozdělení
Podle účelu využití můžeme mashupy rozdělit na business mashupy, uživatelské mashupy
a datové mashupy [35]. Business mashup je webová aplikace, která využívá data z více zdrojů
za účelem podporovat firemní procesy. Výhodné je například použití těchto aplikací pro vývoj projektů agilní metodikou, kdy je potřeba spolupráce jak ze strany vývojářů, tak ze strany
managementu nebo zákazníka. Mashup tak musí umět pracovat s daty z různého softwaru
a výsledek předávat ostatním zainteresovaným osobám [35]. Oproti tomu na uživatele orientovaný mashup je určený pro veřejné využití a získává data z veřejných webových služeb [35].
Ukázkovým příkladem může být například personalizace hlavní stránky Google1 . Registrovaný uživatel si na hlavní stránku může umístit prvky pro zobrazování oblíbeného zpravodajství, aktuálního počasí, modul pro vyhledávání v jízdních řádech a spoustu dalších prvků.
V případě, že webová aplikace využívá data z více zdrojů podobného formátu, zpracovává
je a předává dál v jednotném formátu, jedná se o datový mashup. Tyto mashupy se využívají
například pro agregaci aktuálních zpráv z různých zpravodajských serverů.
Další možné rozdělení může být podle jejich funkce a podle architektury mashupu [34].
Z funkcionálního pohledu je můžeme rozdělit do několika kategorií: mapy, videa a fotky, vyhledávání a nakupování zboží, zpravodajství. Asi nejznámější webovou službou používanou
mashupy, která poskytuje rozhraní pro práci s mapami je Google Maps. Díky jejímu rozhraní
může libovolná webová aplikace umísťovat na mapu místa, značkovat je informacemi, počítat
vzdálenosti, vyhledávat adresy a provádět další užitečné věci. Uživatel tak může vidět informace dané aplikace (mashupu) graficky uspořádané v mapě. Po úspěchu Google se na trhu
postupně objevily další webové služby poskytující rozhraní pro práci s mapou – Bing Maps
(Microsoft), Yahoo Maps (Yahoo) a MapQuest (AOL), ovšem nejúspěšnější a nejvyužívanější
zůstává i v současnosti Google Maps [34].
Dalším důležitým prvkem mashupů jsou videa a fotografie. Mezi nejznámější webové
aplikace pro sdílení fotografií patří Flickr, který umožňuje uživatelům nahrávat fotografie, přiřazovat jim informace (tzv. meta informace) a sdílet mezi sebou. Mashup potom může načítat
obrázky, zobrazovat je na mapě podle místa pořízení nebo z nich vytvářet různá fotoalba,
koláže fotek a podobně [34]. Významným zástupcem webových služeb umožňujících sdílení
videa je Youtube, který v roce 2006 koupila společnost Google [6].
Mashupy pro vyhledávání a nakupování zboží tu existovaly už dlouho předtím, než
byl termín mashup poprvé použit. Služby jako PriceGrabber, BizRate, Google Froogle (dnes
známý pod názvem Google Product Search [5]) fungující jako vyhledávače zboží a porov1 http://www.google.com/ig
12
návače cen, využívaly B2B (business-to-business) technologie. S příchodem mashupů došlo
pouze ke zveřejnění jejich rozhraní veřejnosti a vývojáři tak získali možnost využívat jejich
funkce. Dalším zdrojem dat a informací pro potencionální mashup můžou být zdroje zpravodajství (například New York Times, Reuters a další). Taková aplikace potom může agregovat
zprávy z různých zdrojů a zobrazovat je v jednotné formě svým uživatelům [34].
Z pohledu architektury můžeme mashupy rozdělit na dva základní typy – klientské
a serverové [35]. U klientských mashupů probíhá komunikace s webovými službami přímo
v prohlížeči uživatele (pomocí technologií JavaScript, Ajax apod.). Oproti tomu serverové
mashupy si veškerá data připraví na straně serveru a klientskému prohlížeči předají až výsledek. Výhoda klientských mashupů spočívá v aktuálnosti dat, protože ty se získávají přímo
ze zdroje, zatímco serverové mashupy data nejprve stáhnou k sobě, zpracují je a potom předají
uživateli. V praxi se většinou používá kombinace obou přístupů [34].
2.1.2 Využívané technologie
Struktura mashup aplikace je složena ze třech logicky a fyzicky oddělených částí [34], které
spolu navzájem komunikují a vyměňují si potřebná data. Na každou část jsou kladeny jiné
technologické požadavky, které se pokusím přiblížit v následujícím textu. Standardní mashup
se skládá z rozhraní webových služeb, vlastní webové aplikace a prohlížeče uživatele.
Rozhraní webových služeb slouží pro vlastní komunikaci mezi aplikacemi. Aby bylo
možné standardizovat způsob výměny dat, bylo vytvořeno několik protokolů. Podle knihy
Programujeme Mashup aplikace pro Web 2.0 v PHP [23, s. 17] patří mezi často se vyskytující protokoly XML-RPC (tento protokol byl postupně nahrazen modernějším protokolem
SOAP [9]), REST (zde je důležité poznamenat, že REST není ani tak protokol jako spíše styl
SW architektury [36] – více v kapitole 2.3.4) a protokol SOAP. Kromě těchto tří technologií
existují ještě další způsoby, jak získávat data. Mezi ně patří například protokoly RSS a Atom
a také technika zvaná „screen scraping“ [34], pomocí které je možné získávat data přímo
ze zdrojového kódu stránky. Jednotlivé technologie budou podrobněji popsány v kapitole 2.3.
Dalším blokem je vlastní webová aplikace, která bývá implementovaná v technologiích typu PHP, Java, ASP. V podstatě se jedná o jakýkoliv jazyk, ve kterém je možné vytvořit
HTML aplikaci, včetně komunikace s databází, zakládání uživatelských sezení a dalších požadovaných funkčností na programovací jazyk. Neméně významnou části mashupu je webový
prohlížeč uživatele. Prohlížeč bývá většinou nejproblematičtější částí z pohledu vývoje aplikace a to z důvodu existence různých prohlížečů od různých výrobců. Bohužel ne každý interpretuje standardy správně, což platí převážně u starších prohlížečů, které jsou stále hojně
používané, například ve velkých společnostech. Webový prohlížeč musí kromě nezbytného
HTML (případně XHTML a dalších podobných standardů), JavaScriptu a CSS podporovat
také Ajax pro asynchronní volání požadavků (načtení dat bez potřeby obnovit prohlížeč). Tyto
technologie jsou naštěstí v moderních prohlížečích plně podporované, i když občas s rozdíl-
13
nou interpretací zdrojového kódu, ale i tento stav se postupně zlepšuje. V blízké budoucnosti
se také zřejmě dočkáme nástupu zcela nové technologie HTML5, která by měla standardy
staré téměř 20 let [1] nahradit a přizpůsobit technologie současným trendům.
2.2 Historie
Pro popsání historie mashupů v kontextu webových aplikacích a internetových stánek obecně,
se pokusím popsat vývoj webu přímo od jeho vzniku. Počátky webu sahají až do počátku
devadesátých let minulého století. První návrh hypertextového protokolu HTTP a s ním souvisejících technologií vytvořil již v roce 1989 Tim Berners-Lee [12] v rámci své práce pro
CERN (Evropská organizace pro jaderný výzkum [3]). Kvůli rostoucímu objemu zpracovávaných dat se snažil najít způsob jak lépe zpracovávat informace a umožnit jejich snadné
sdílení mezi zaměstnanci. Výsledkem jeho práce byl dokument [20] napsaný v březnu 1989
a popisující základy protokolu HTTP. O rok později vytvořil první webový server a grafický
webový prohlížeč – WorldWideWeb, který byl později přejmenován na Nexus a uvolněn pro
veřejnost v roce 1991 [29].
V těchto letech existovalo pouze několik málo internetových stránek, jejichž obsah
byl navíc relativně strohý. Tehdejší web uměl zobrazit pouze text, obrázky, základní formátování textu a odkazy. První průlom ve vývoji webu nastal v první polovině devadesátých let,
kdy se zrodily prohlížeče Mosaic (1993) a Netscape (1994) [2]. Po uveřejnění těchto prohlížečů se začal Internet rychle šířit a to především do univerzit, větších společností, ale také
do domácností. Ty se tehdy připojovaly pomocí modemu a vytáčeného spojení, za které se
platilo v hodinových sazbách. V roce 1994 umožnil americký poskytovatel internetového připojení AOL vytvářet vlastní internetové stránky pomocí speciálního software a zpřístupňovat
je na Internetu [1]. Milionům svých zákazníků tak umožnil prezentovat vlastní web na Internetu. V důsledku tohoto začaly vznikat první WYSIWYG editory, které umožňovaly vytvářet
stránky bez znalosti HTML kódu. Následovala další vlna šíření Internetu mezi lidmi a počet
webových stránek začal rychle stoupat. Pro představu, na konci roku 1994 existovalo zhruba
10 tisíc webových stránek, v červnu roku 1995 jich bylo 23 tisíc a v lednu 1996 jich bylo
zhruba 100 tisíc. V polovině devadesátých let se začínají objevovat nové prohlížeče a vzniká
mezi nimi konkurenční boj. Nastupuje Opera (1995) a Internet Explorer (1995) [2], který
začal díky integraci do populárních Windows vytlačovat v té době nejrozšířenější Netscape.
S rostoucím počtem online uživatelů také stoupaly požadavky na internetové stránky
a to především na jejich uživatelskou přívětivost a použitelnost. V devadesátých letech tak postupně vznikaly nové technologie, mezi které patří Cookies, JavaScript, CSS, XML a Ajax [2].
Z Internetu téměř mizí klasické statické stránky, které jsou postupně nahrazovány dynamickými stránkami, které umožňují reagovat na požadavky uživatele. S velkým počtem technologií a absencí závazného standardu se postupně začal objevovat problém s kompatibilitou
stránek pro jednotlivé prohlížeče. V roce 1994 proto založil Tim Berners-Lee [12] meziná-
14
Obrázek 2.1: Vývoj počtu stránek v letech 1990 - 2008
Zdroj: http://www.pingdom.com
rodní konsorcium W3C, které si klade za cíl standardizovat webové technologie a zajistit, aby
se vývoj webu ubíral jednotnou cestou, kterou budou respektovat všichni výrobci prohlížečů.
Velkým průlomem ve vývoji Internetu bylo rozšíření vysokorychlostního internetu do domácností (během prvních let dvacátého prvního století) [7] a tímto milníkem končí první etapa
vývoje webu, často označovaná neoficiálním termínem Web 1.0 [1]. V tomto období (konec devadesátých let a počátek 21. století) roste počet internetových stránek exponenciálním
tempem, růst do roku 2008 graficky znázorňuje obrázek 2.1.
Po rozšíření vysokorychlostního připojení se Internet dostává k masám obyvatel a dnes
je ve vyspělých státech téměř každá domácnost online. O rozšíření internetu a jednoduchosti
na něm něco publikovat svědčí i to, že k dubnu 2012 je na Internetu umístěno odhadem minimálně 8,63 bilionů stránek [14]. Postupným zdokonalováním nových technologií je možné
využívat Internet v mnoha dalších oblastech. Vznikají první webové aplikace umožňující nakupovat na webu (eBay, eshopy), začínají vznikat první sociální sítě (MySpace, Facebook) [1]
a další relativně komplexní aplikace. Roste význam uživatelsky vytvářeného obsahu a ten se
stává důležitým prvkem moderních webových aplikací. Jeho význam se umocňuje ještě možností sdílet jej mezi uživateli. Návštěvníci stránek můžou jednoduchým způsobem vkládat
obrázky, označovat je, přidávat popisky a provádět mnoho dalších akcí souvisejících se vzájemnou komunikací uživatelů. Protože se klade důraz na vysokou interaktivitu s uživatelem,
musí být tyto stránky interaktivní, uživatelsky přívětivé a hlavně rychlé (prohlížeče musí být
optimalizované pro výkon). To vedlo ke zdokonalení technologií vytvořených v devadesátých
letech, v roce 2009 například vzniká jQuery (framework pro usnadnění práce s JavaScriptem
a pro snadné vytváření grafických efektů přímo v prohlížeči uživatele), vzniká prohlížeč Google Chrome a druhý dech také nabírá Safari od společnosti Apple [29]. Tato druhá etapa se
často označuje neoficiálním termínem Web 2.0, který poprvé použil Darcy DiNucci v roce
1999 ve svém článku „Fragmented future“ [25]. Píše zde:
„Web, jak ho známe teď, který se jako statický text načte do okna prohlížeče, je jen
zárodek webu, který přijde. První záblesky Webu 2.0 se již začínají objevovat a my sledujeme,
jak se toto embryo začíná vyvíjet. Web bude chápán ne jako obrazovky plné textu a grafiky, ale
15
jako prostředí, jako éter, jehož prostřednictvím dochází k interaktivitě. Objeví se na obrazovce
počítače, na televizním přijímači, na palubní desce, na mobilním telefonu, na herní konzoli,
a možná, že i na vaší mikrovlnné troubě.“
Jak můžeme pozorovat dnes, nebyl daleko od pravdy. Společně s termínem Web 2.0
se objevuje i termín sémantický web, který se snaží vybudovat takovou infrastrukturu, kde
každá obsahová informace bude mít svůj význam, vztah k ostatním (neboli sémantiku) a bude
možné s ní strojově pracovat [34]. Pro možnost modelovat data podle jejich významu byl konsorciem W3C vytvořen standardizovaný model pro definici zdrojů na webu – RDF (Resource
Description Framework). RDF je založeno na XML a snaží se o pojmenování vztahů mezi
objekty (pomocí tzv. trojúhelníku definuje podmět, předmět a vztah mezi nimi) [28].
Společně s vývojem interaktivních webových aplikací, jejich zvyšujícímu se množství, zvýrazněním významu dat a hlavně růstem jejich objemu se postupem času stávalo nutné
umožnit komunikaci mezi různými aplikacemi. Ať už se jednalo o společnost která má více
informačních systémů a potřebuje zajistit vzájemnou komunikaci mezi nimi anebo například o aplikaci agregující novinky z celého světa do jedné aplikace. Díky rostoucí složitosti
a komplexnosti webových aplikací bylo nutné přijmout způsob myšlení, který je s úspěchem
využíván v programovacích jazycích. A to je snaha o rychlost vývoje, jednoduchost a možnost
opětovného použití. Webové aplikace se začínaly vyvíjet tak, aby bylo možné jejich některé
části rychle a jednoduše využívat znovu. Toto vedlo k postupnému rozšíření webových služeb nejenom do firemních intranetů ale díky jednoduchosti svého rozhraní také do běžných
uživatelských stránek (formou klienta webové služby).
Již v raných fázích Internetu vyčlenil Microsoft speciální tým, který měl pracovat na
komunikačním protokolu SOAP [30]. Postupným vývojem se tento komplexní protokol stal
vhodným pro spolehlivou, bezpečnou a na transakcích založenou komunikaci mezi aplikacemi. Jeho hlavní nevýhodou byla příliš vysoká složitost, což byl hlavní důvod, proč nedošlo k jeho masivnímu rozšíření. Jeho hlavní použití bylo (a stále je) v podnikových aplikacích [38]. Postupným zdokonalováním technologií se kladly vyšší požadavky na ovladatelnost
stránek a i to byl důvod rozšíření Ajaxu (technologie umožňující načíst data bez obnovení
stránky) a potom stačil jen malý krok ke vzniku nových protokolů pro webové služby optimalizované pro prohlížeče a komunikaci mezi jednotlivými stránkami (REST, JSON) [30].
Tyto protokoly umožňovaly snadnou komunikaci mezi komponenty jedné webové
aplikace (společně s využitím Ajaxu) ale i mezi různými aplikacemi. Mezi průkopníky těchto
veřejných webových služeb patří velcí hráči jako například Google, Amazon, eBay, Microsoft, Yahoo, Twitter a samozřejmě také Facebook. Tyto společnosti poskytly veřejné API
a umožnili tak jakémukoliv vývojáři využívat jejich služby na svých stránkách. V posledních několika letech to vedlo k masivnímu rozšíření webových služeb a následnému vzniku
termínu mashup, označující aplikaci, která využívá více těchto webových služeb současně.
16
2.3 Technologie webových služeb
Webové služby jsou v současnosti důležitým prvkem moderních webových aplikací a především nezbytnou součástí mashupů, protože díky nim můžou komunikovat s API ostatních
aplikací. Standardizační organizace W3C popisuje webovou službu jako softwarový systém
určený identifikátorem URI, jehož veřejné rozhraní a vazby jsou definovány pomocí XML.
Na základě znalosti popisu služby komunikují ostatní systémy s vybranou službou a to způsobem popsaným v její definici. Pro výměnu dat využívá zprávy založené na XML a pro jejich
přenos standardní internetový protokol [13]. Důležité je ovšem dodat, že tato definice, která
vychází ze specifikace protokolu SOAP (viz. 2.3.3), není nijak závazná a v současnosti existuje mnoho služeb, které jsou založeny na jednodušších technologiích (viz. dále). O aplikaci,
která využívá služby (například mashup) říkáme, že je postavená na SOA (Service Oriented
Architecture - architektura orientovaná na služby).
Jak můžeme vidět na obrázku 2.2, na služby orientovaná architektura se skládá ze tří
hlavních částí: klienta, který komunikuje se službou, adresáře webových služeb a jejich popisu (discovery agencies) a samotné webové služby. Pro správné fungování služby je nejprve
potřeba, aby se o ní vědělo. Toto zajistí adresář webových služeb, který klientům poskytne
také jejich popis. Na základě získaného popisu služby s ní klient může přímo komunikovat.
V praxi se občas vynechává adresář služeb a nahrazuje se dokumentací k webové službě,
která definuje umístění rozhraní webových služeb a jejich popis. S tímto se často setkávají
tvůrci mashupů, protože poskytovatelé veřejných rozhraní se snaží, aby jejich použití bylo co
nejjednodušší a nebylo potřebné psát další kód pro dotazování se adresáře webových služeb.
Aplikace postavená na SOA většinou kombinuje různé protokoly, datové formáty a principy v závislosti na službách, se kterými komunikuje. Kromě základních technologií využívaných pro webové aplikace (jako je HTML, CSS a JavaScript) musí využívat řadu technologií
navíc. Mezi nejdůležitější technologie, bez kterých by SOA aplikace vůbec nevznikly, patří
Ajax. Pomocí něj může aplikace komunikovat se službami a jinými komponentami aplikace
na pozadí načtené stránky (a bez vědomí uživatele). Stránka může načítat data z různých
zdrojů a na základě činnosti uživatele dynamicky zobrazovat na stránce. Vývojáři SOA aplikací (a tedy i mashupů) se běžně setkávají s názvy XML–RPC, SOAP, REST, JSON, XML,
RSS a ATOM. V následujícím textu postupně popíši každou technologii zvlášť.
2.3.1 Ajax
První článek o Ajaxu se objevil v roce 2005 a jeho autorem byl Jesse James Garrett [27].
V článku popisuje Ajax ne jako jednu technologii, ale jako skupinu více spolupracujících
technologií. Mezi tyto technologie patří W3C standardy pro webové prezentace, DOM (Document Object Model), technologie pro výměnu dat a manipulaci s nimi (XML a XSLT),
objekt XMLHttpRequest pro asynchronní přenos dat a JavaScript. Stránky využívající Ajax
můžou odesílat požadavky na pozadí načtené stránky a uživatel tudíž nemusí pro získání
17
Obrázek 2.2: Architektura orientovaná na služby
Zdroj: http://www.w3.org
informace obnovovat celou stránku, ale načte se mu pouze potřebná část stránky. Prvním
průkopníkem této technologie byl Google, který Ajax zahrnoval do svých aplikací (například
Orkut, Gmail, Google Maps a další) [27] už v době, kdy se tato technologie teprve začínala
objevovat a ještě neexistovaly frameworky pro její snadné využívání. Po něm následovaly další
společnosti (Flickr, Amazon) a dnes Ajax využívá téměř každá stránka, která se snaží být alespoň trochu interaktivní. Jeho masivnímu rozšíření přispěl i framework jQuery (2006 [19]),
který poskytuje funkce pro snadnou práci s Ajaxem a stránkou obecně.
2.3.2 XML-RPC
Protokol XML–RPC (XML Remote Procedure Call) je protokol pro webové služby založený
na formátu XML, který pro přenos dat využívá mechanismus HTTP a jeho metodou POST.
Protokol byl vytvořen v roce 1998 Davidem Winerem ze společnosti UserLand [9]. Tento
protokol je velice jednoduchý, soubor XML nevyužívá žádné jmenné prostory ani atributy.
Důležitým prvkem XML–RPC volání jsou hlavičky požadavku, který je odeslaný na
webovou službu. Podle specifikace ([41]) musí hlavička obsahovat parametry User−Agent,
Host, Content−Type (musí být text/xml) a Content−Length, který musí být nastavený
správně. Příklad možného volání XML–RPC ukazuje následující kód.
18
1
2
3
4
5
6
7
8
9
<?xml v e r s i o n ="1.0"? >
<methodCall >
<methodName>examples . getStateName < / methodName>
<params>
<param>
<value >< i 4 >41 </ i 4 > </ value >
</ param>
</ params>
</ methodCall >
Na prvním řádku vidíme definici XML souboru. Druhý řádek již obsahuje značku
obalující vlastní tělo volání. Značka <methodName>...</methodName> definuje název
metody, kterou bude webová služba volat. Značkou <params>...</params> jsou ohraničené
jednotlivé parametry. Na tomto příkladu je také vidět, že nevyužívá žádné XML atributy ale
pouze elementy.
2.3.3 SOAP
Jako nástupce jednoduchého XML–RPC vznikl protokol SOAP (Simple Object Access Protocol), který je také nezávislý na platformě a je určený pro komunikaci mezi vzdálenými službami. Zprávy posílané pomocí tohoto protokolu jsou založeny na XML formátu a skládají se
z hlavičky zprávy, která slouží k přenosu pomocných informací (například ověření uživatele
apod.) a jejího těla. Strukturu zprávy (požadavku i odpovědi) striktně definuje WSDL dokument, který opět využívá schéma XML. V definici tohoto dokumentu jsou uvedeny metody,
které webová služba poskytuje, jejich návratové hodnoty, datové typy (jednoduché nebo komplexní) a spojovací body. Výhoda tohoto principu spočívá v tom, že webová služba může vždy
ověřit validitu požadavku ještě před jeho zpracováním [34].
Historie tohoto protokolu začíná v roce 1998 díky společnostem Microsoft, DevelopMentor a Userland a již 13. září 1999 se světu představila první verze protokolu – SOAP 0.9.
Po několika úpravách vznikla v prosinci 1999 verze SOAP 1.0 a v květnu 2000 byl návrh protokolu (tehdy již ve verzi 1.1) odeslán standardizační organizaci W3C [39]. V této době již
na protokolu spolupracovala i společnost IBM a díky této spolupráci vznikla implementace
protokolu v prostředí JAVA. Následoval rychlý vývoj, který byl postupně přenechán organizaci Apache XML Project jako open source. V této době již výrobci přicházeli s vlastními
implementacemi pro různé platformy [39].
V září 2000 byla v rámci W3C založena pracovní skupina pro XML protokol, která
jako výchozí bod své práce přijala SOAP 1.1 a převzala tak zodpovědnost za jeho vývoj.
Po mnoha měsících vývoje, v červnu 2003, uveřejnila W3C doporučení pro webové služby
založené na XML, které neslo označení SOAP 1.2 [10]. SOAP je využíván převážně v enterprise aplikacích, protože dokáže jednoznačně popsat validní strukturu zprávy, kterou dokáže
automaticky kontrolovat a webová služba využívající tento protokol také dokáže pracovat
s chybovými stavy, což zvyšuje odolnost aplikace vůči neočekávaným situacím.
19
2.3.4 REST
REST (Representational State Transfer) není protokol jako SOAP, ale jedná se o architektonický styl pro návrh webových služeb. V roce 2000 jej ve své dizertační práci popsal Roy Fielding [26]. Tento styl je založen na protokolu HTTP a využívá jeho metod PUT, GET a POST
pro vkládání, čtení, editaci a mazání záznamů (tato skupina operací bývá označovaná jako
CRUD – create, read, update, delete). Dnes bývá metoda PUT často nahrazována metodou
POST s potřebnými parametry – jedná se opět o další zjednodušení architektury, ke kterému
se dospělo postupným vývojem. K vytvoření nového požadavku na webovou službu se potom využívá pouze unikátní URL adresy, která v sobě nese informaci o metodě, která se má
vykonat a případné parametry pro tuto metodu [26]. Výsledkem po provedení metody může
být jakýkoliv formát dat, jaký si vývojáři domluví (mezi nejčastěji využívané patří XML,
JSON). Jak je vidět, REST definuje pouze způsob přístupu k metodám, nedefinuje už jednotlivé datové typy a vývojáři webových služeb si můžou zvolit takový formát, jaký jim vyhovuje.
Výhoda oproti SOAP protokolu spočívá především v jeho jednoduchosti a snadnosti použití,
například není potřeba vytvářet rozsáhlou specifikaci webové služby. Tato vlastnost by v některých případech mohla být brána jako nevýhoda (enterprise webové aplikace vyvíjené ve
velkých týmech), ale pro samostatné programátory a malé týmy, které většinou produkují
jednodušší mashupy, se tento přístup ukázal být velice výhodný a také přispěl k širokému
rozšíření webových služeb [31]. Dnes patří REST mezi jeden z nejpoužívanějších stylů pro
vytváření webových služeb.
Jak jednoduché může být použití protokolu REST, si ukážeme na příkladu. Mějme
hypotetickou webovou službu založenou na architektuře REST umožňující práci s adresářem
kontaktů. V příkladech nebudu z důvodu jednoduchosti řešit zabezpečení a autorizaci uživatele. Následující příklad ukazuje jednoduché volání GET pro získání seznamu kontaktů:
h t t p : / / a p i . my−domain . cz / c o n t a c t / g e t
Druhý příklad ukazuje, jak je možné v rámci REST architektury předávat parametry.
V tomto případě by služba vrátila detail kontaktu s identifikátorem „1“:
h t t p : / / a p i . my−domain . cz / c o n t a c t / g e t / 1
Pro vložení nového záznamu se potom může využít metoda POST (případně PUT, ale
spíše se používá standardnější POST) volaná společně s daty, které definuje specifikace pro
metodu „insert“:
h t t p : / / a p i . my−domain . cz / c o n t a c t / i n s e r t
Výše uvedené příklady ukazují, jak architektura přistupuje k metodám a parametrům.
Datový formát, který bude použit pro výměnu informací a jak tedy budou vypadat vrácená
20
data po volání metod už záleží na poskytovateli příslušné webové služby. Mezi často používané formáty patří například JSON (2.3.5) nebo XML (2.3.6).
2.3.5 JSON
Aby komunikace mezi webovými službami mohla probíhat prostřednictvím standardních datových formátů, bylo nutné tyto formáty nadefinovat a to tak aby byly jednoduché na používání a také aby byly široce podporované v programovacích a skriptovacích jazycích. Jedním
z nových formátů vzniklých pro výměnu dat mezi webovými aplikacemi je JSON (JavaScript
Object Notation). JSON je textový formát určený pro serializaci strukturovaných dat vycházející ze serializace v JavaScriptu [8] a je tedy vhodný pro interaktivní aplikace, které tento
skriptovací jazyk využívají. Formát podporuje základní datové typy a strukturované datové
typy. Mezi základní typy patří řetězce, čísla, logické hodnoty (pravda, nepravda) a hodnota
null. K strukturovaným datovým typům patří objekty a pole. Objektem se myslí nesetříděný
seznam klíčů a jejich hodnoty, kde klíč je řetězec a hodnota může být jeden ze základních
nebo strukturovaných typů. Polem se rozumí setříděný seznam žádné anebo více hodnot [24].
Hlavní výhodou JSON oproti dalšímu často využívanému formátu XML (viz. 2.3.6)
je jeho jednoduchost a efektivnější práce s ním v JavaScriptu. Je také úspornější z pohledu
objemu přenášených dat. Díky těmto vlastnostem byla podpora tohoto formátu přidána do
většiny programovacích jazyků [8] a často se využívá ve spojení s REST architekturou (2.3.4).
2.3.6 XML
XML (Extensible Markup Language) je, podobně jako JSON, formát určený pro přenos dat.
O jeho vývoj se stará organizace W3C, jejímž cílem je vytváření a udržování standardů. XML
definuje obecná pravidla pro zápis dokumentu formou značek do strukturované podoby [16].
Tato pravidla definují, jakým způsobem je možné používat značky, elementy a další prvky
dokumentu. Obsahová část a struktura dokumentu je na vývojáři. Je tedy na něm, aby si zvolil
názvy jednotlivých elementů a určil, jak budou data strukturována. Tato struktura může vycházet například ze struktury databáze nebo z vlastností objektu implementovaného v rámci
aplikace. XML vychází z formátu SGML (jehož aplikací je také HTML), který byl vyvinut v 70. letech minulého století v laboratořích IBM. Jeho velkou nevýhodou byla přílišná
složitost, a proto v roce 1996 vytvořili Jon Bosak, Tim Bray, C. M. Sperberg–McQueen, James Clark a několik dalších očištěnou a odlehčenou verzi SGML. Výsledkem bylo v únoru
1998 publikování první verze XML 1.0. Formát měl u vývojářů okamžitý úspěch [15] a postupně se z něj stal jeden z nejvyužívanějších formátů pro přenos dat. Zatím poslední verzi je
XML 1.1, která byla publikovaná v srpnu 2006 [17].
21
2.3.7 RSS
RSS (Really Simple Syndication) je datový formát určený pro snadné zpřístupňování webového obsahu (neboli takzvanou online syndikaci, poskytování aktuálních informací). Formát
je založen na XML, ale jeho definice byla zjednodušena a optimalizována pro snadný popis
informací (mající většinou podobný nebo stejný formát). Tohoto zjednodušení bylo dosaženo definováním pevné struktury souboru a stanovením povolených značek pro jednotlivé
prvky (elementy) popisující zprávu (například nadpis, anotace, autor, datum a další). RSS byl
vytvořen společností UserLand v roce 1997 a následně využíván společností Netscape jako
komunikační kanál (1999). V roce 2002 byla společností UserLand vytvořena zatím poslední
verze RSS 2.0 [21]. Během svého vývoje se z něj stal jeden z nejoblíbenějších a nejvyužívanějších datových formátů pro publikování aktualit, novinek, blogů, zpravodajství apod. Jak
může RSS dokument vypadat, ukazuje následující příklad:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml v e r s i o n = " 1 . 0 " encoding =" u t f −8"?>
<rss version ="2.0" >
<channel >
< t i t l e >Example Feed < / t i t l e >
< d e s c r i p t i o n > I n s e r t w i t t y o r i n s i g h t f u l remark here < / d e s c r i p t i o n >
< l i n k > h t t p : / / example . org / < / l i n k >
< l a s t B u i l d D a t e >Sat , 13 Dec 2003 1 8 : 3 0 : 0 2 GMT< / l a s t B u i l d D a t e >
<managingEditor >johndoe@example . com ( John Doe ) < / managingEditor >
<item >
< t i t l e >Atom−Powered Robots Run Amok< / t i t l e >
< l i n k > h t t p : / / example . org / 2 0 0 3 / 1 2 / 1 3 / atom03 < / l i n k >
< g u i d isPermaLink =" f a l s e " > urn : u u i d :1225 c695−cfb8 −4ebb−aaaa−80da344efa6a < / guid >
<pubDate >Sat , 13 Dec 2003 1 8 : 3 0 : 0 2 GMT< / pubDate >
< d e s c r i p t i o n >Some t e x t . < / d e s c r i p t i o n >
</ item >
</ channel >
</ rss >
První řádek definuje hlavičku XML souboru a říká, v jaké znakové sadě je poskytován. Řádek číslo 2 označuje RSS dokument a upřesňuje, že se jedná o verzi 2.0. Po hlavičkách následují vlastní data, obalená značkou <channel>...</channel>. Řádky 4-8 popisují
informační kanál (v pořadí jak jsou uvedeny postupně: nadpis, popis, odkaz na kanál, datum
poslední aktualizace, editor kanálu). Po informacích o kanálu následuje posloupnost značek
<item >...</ item>, kde každá značka popisuje jednu zprávu. U zprávy se definuje nadpis,
odkaz, unikátní identifikátor, datum publikace a popis (řádky 10-14). RSS definuje ještě další
nepovinné značky, které je možné v dokumentu použít, všechny dostupné je možné nalézt na
oficiálních stránkách formátu 2 .
2 http://www.rssboard.org/rss-specification/
22
2.3.8 ATOM
Podobně jako RSS je ATOM datový formát určený pro poskytování zpráv prostřednictvím
Internetu. Jeho cílem je eliminovat nevýhody protokolu RSS a vytvořit čistší formát. Stejně
jako RSS je i ATOM založen na formátu XML a podobným způsobem také strukturuje data.
První oficiální verze byla publikována v létě 2005 jako Atom 1.0 [22] a následně byla v prosinci 2005 vydána jako RFC 4287 [33]. Formát Atom zavádí přísnější pravidla pro obsah
dokumentu, zavádí více povinných informací, oproti RSS umožňuje rozlišovat typ dat v elementech (obyčejný text, text uvozený zpětnými lomítky, XHTML kód, ukazatel na dokument
umístěný na webu a některé další způsoby zápisu dat) [37]. Pro porovnání obou formátů uvádím kód, který vznikl konverzí ukázky v předchozí kapitole do Atomu:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml v e r s i o n = " 1 . 0 " encoding =" u t f −8"?>
<feed xmlns =" h t t p : / / www. w3 . org / 2 0 0 5 / Atom" >
< t i t l e >Example Feed < / t i t l e >
< s u b t i t l e > I n s e r t w i t t y o r i n s i g h t f u l remark here < / s u b t i t l e >
< l i n k h r e f =" h t t p : / / example . org / " / >
<updated >2003−12−13T18 : 3 0 : 0 2 Z < / updated >
< author >
<name>John Doe< /name>
<email >johndoe@example . com< / email >
</ author >
< i d >urn : u u i d : 6 0 a76c80−d399−11d9−b93C−0003939e0af6 < / i d >
<entry >
< t i t l e >Atom−Powered Robots Run Amok< / t i t l e >
< l i n k h r e f =" h t t p : / / example . org / 2 0 0 3 / 1 2 / 1 3 / atom03 " / >
< i d >urn : u u i d :1225 c695−cfb8 −4ebb−aaaa−80da344efa6a < / i d >
<updated >2003−12−13T18 : 3 0 : 0 2 Z < / updated >
<summary>Some t e x t . < / summary>
</ e n t r y >
</ feed >
Můžeme vidět, že hlavička XML souboru se definuje stejným způsobem jako u RSS.
Druhý řádek označuje protokol Atom a definuje jmenný prostor formátu. Podobně jako u RSS,
i Atom nejprve popisuje informační kanál. Jak můžeme vidět, názvy některých značek se
odlišují (například < subtitle >...</ subtitle >, určený pro popis). Rozšířil se také element
<author>...</author> popisující autora. Rozdíl mezi těmito formáty je také v tom, že zatímco RSS definuje povinné položky pouze nadpis, odkaz a popis, v Atomu musí být navíc
vyplněny ještě prvky <id >...</ id> a <updated>...</updated>.
2.4 Oblíbené webové služby
V této kapitole krátce popíši několik oblíbených a často využívaných API, s některými jsem
se také setkal v rámci mé praktické části. Zaměřím se na webovou službu pro práci s kartografickými údaji – Google Maps a službu pro práci s alby a fotografiemi - Picasa Web Albums,
obě dvě služby jsou od společnosti Google. Dále se budu zabývat sociální sítí Facebook.
23
2.4.1 Google Maps
Google Maps se řadí mezi nejpoužívanější rozhraní pro přístup k mapovým podkladům. Podle
ProgrammableWeb3 je Google Maps nejvyužívanějším API. Poprvé bylo představeno v únoru
2005 a přineslo revoluční způsob využívání map na webových stránkách [40], což bylo dříve
buď příliš drahé, nebo příliš složité. Za jeden z prvních mashupů využívající mapové API je
považována aplikace HousingMaps.com4 . Tato aplikace přidává na mapu značky označující
domy a byty k prodeji nebo pronájmu (v USA nebo v Londýně) [23]. Google Maps v současné době poskytuje několik kategorií API, které je možné využít pro různé funkcionality
poskytované mapami. Tato rozhraní jsou přehledně popsána, a to včetně užitečných příkladů,
na oficiálních stránkách aplikace Google Developers5 .
Mezi nejvýznamnější a zřejmě nejvyužívanější rozhraní patří Maps JavaScript API,
které bylo uvolněno již ve své třetí verzi. Tato verze umožňuje jednoduše přistupovat k mapám prostřednictvím JavaScriptu a je optimalizovaná také pro využití v mobilních zařízeních,
což je důležité hlavně kvůli rozšíření chytrých mobilních telefonů. Pokud se na toto rozhraní
podíváme z pohledu technologií, jak byly uvedeny v části 2.3, celá komunikace je postavená
na technologii Ajax a webová služba je založená na architektuře REST. Z pohledu vývojáře
mashupu ovšem stačí pouze načíst potřebnou knihovnu (načtením definovaného JS souboru,
který je umístěn na serverech Google), zavolat inicializační funkci a potom už pouze využívat
knihovní funkce. Programátora nemusí zajímat, jaká architektura webové služby je zvolená
anebo jaký protokol je používán pro výměnu dat – pouze volá příslušné JS funkce. V některých případech je samozřejmě potřeba znát data, která jsou očekávána na vstupu nebo výstupu
– a to například při pokročilejší práci s rozhraním. Google Maps využívá XML i JSON. Následující příklad ukazuje příklad využití API:
1
2
3
4
5
6
7
8
9
10
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " >
function i n i t i a l i z e () {
v a r myOptions = {
c e n t e r : new google . maps . LatLng ( −34.397 , 1 5 0 . 6 4 4 ) ,
zoom : 8 ,
mapTypeId : google . maps . MapTypeId .ROADMAP
};
v a r map = new google . maps . Map( document . getElementById ( " map_canvas " ) , myOptions ) ;
}
</ s c r i p t >
Uvádím pouze funkci, které je určená pro inicializaci mapy a předpokládá načtení
příslušného JS souboru obsahující knihovny pro mapy a existenci elementu, do kterého bude
mapa vložena – například <div id="map_canvas">...</div>. Řádky 3-7 obsahují základní
konfiguraci nové mapy. Čtvrtý řádek označuje souřadnice místa, vůči kterému bude mapa
vycentrovaná. Následující řádek definuje počáteční přiblížení mapy a šestý řádek určuje typ
3 http://www.programmableweb.com/
4 http://www.housingmaps.com/
5 https://developers.google.com/maps/documentation/
24
mapy. V osmém řádku se už pouze vytvoří vlastní mapa (v parametru obsahuje ukazatel na
element v dokumentu, kde se má zobrazit a v druhém parametru obsahuje nastavení mapy)
a instance se po vytvoření přiřadí do proměnné.
Kromě Maps JavaScript API rozhraní nabízí Google Maps také Maps Image APIs,
které poskytuje jednoduché získávání statických obrázků (použitelné jako statický obrázek do
stránky) z mapových podkladů (případně ze StreetView – poskytuje nafocené snímky z ulice).
Google Earth API poskytuje rozhraní pro zpřístupňování této aplikace na webových stránkách
a Maps for Business nabízí podporu pro podnikové aplikace. Mezi další zajímavé API v rámci
Google Maps patří Web Services (obsahuje například funkce pro hledání místa dle adresy
v textové podobě) a Places API (poskytuje informace o zajímavých místech).
2.4.2 Picasa Web Albums
Picasa Web Albums je webová aplikace společnosti Google určená pro snadné ukládání a sdílení alb s fotografiemi. První verze byla uveřejněná v červnu 2006 [32] s celkovou kapacitou
250 MB. Dnes již nabízí kapacitu 1 GB (podporuje fotky i videa), přičemž do této kapacity
se započítávají pouze fotografie větší než 2048 x 2048 px.
Picasa Web Albums je v současné době úzce spojená s Google+, fotky nahrané do
jedné z těchto aplikací se automaticky promítnou v té druhé. Poskytované API je aktuálně
ve své druhé verzi a je založené na protokolu, který byl vytvořen společností Google – Google Data Protocol. Protokol využívá architekturu REST a pro výměnu dat formát Atom. Tento
protokol definuje základní podobu zpráv, kterou musí všechny odeslané a přijaté požadavky
splňovat. Protože je tento protokol využíván více službami společnosti Google (včetně Picasa Web Albums), musí se v některých případech rozšířit specifikace Atomu a to přidáním
dalších jmenných prostorů. Toto je princip, kterým je možné do XML zprávy přidávat nové
validní elementy, a protože Atom vychází z XML, může se tento princip použít i pro Atom.
Následující příklad ukazuje, jak jednoduché je získat seznam alb pomocí této služby
(předpokládá již přihlášeného uživatele). V ukázce lze vidět využití architektury REST i s předáváním parametrů. V tomto příkladu jsou obsažené parametry feed a user. Hodnota parametru user – userID definuje identifikátor uživatele, jehož alba jsou získávána. Parametr feed
má hodnotu api a definuje tvar odpovědi na požadavek.
1
GET h t t p s : / / picasaweb . google . com / data / feed / a p i / user / userID
2.4.3 Facebook
Facebook je v současné době největší sociální síť, která má více než 800 milionů uživatelů [11]. Sociální síť se vyznačuje tím, že obsah aplikace vytváří samotní uživatelé. Tento
obsah mezi sebou můžou sdílet, označovat jako oblíbený a samozřejmě mezi sebou můžou
25
komunikovat. Pro sociální sítě jsou data velice důležitá, protože čím zajímavější jsou data
na sociální síti a čím více uživatelů vytváří data, tím je komunita uživatelů stabilnější. API
vzniklo za účelem umožnění integrace sociálních funkcí na webové stránky po celém světě.
Tímto si Facebook otevřel nový informační kanál pro získávání uživatelských dat. Vývojáři
můžou na svých stránkách snadno integrovat funkce pro zveřejňování informací na Facebook
a uživatel ani nemusí opustit stránku, kterou si právě prohlíží.
Facebook API je možné využívat třemi základními způsoby – integrace sociálních
funkcí na stránky, integrace těchto funkcí do mobilních zařízení a vytváření aplikací pro Facebook (spouštěné uvnitř jeho stránek). Já se v tomto popisu zaměřím na popis rozhraní pro
vývojáře webových stránek a tedy na integraci funkcí Facebooku do webové aplikace. Základní charakteristiky API, a to především architektura a formát dat jsou ale stejné pro všechny
tři typy. Přehledný popis celého API a to včetně názorných ukázek je k dispozici na speciální
stránce určené pro vývojáře6 .
Facebook poskytuje několik možností jak do aplikace integrovat sociální funkce. Nejjednodušší možností je využití takzvaných „Sociálních pluginů“, pro jejichž implementaci
stačí do stránek pouze vložit příslušný kód. Aby měli vývojáři s implementací co nejméně
práce, Facebook vytvořil nástroj, který má za cíl tento kód na základě vstupních parametrů vygenerovat. Výsledný kód na pozadí načte do webové stránky potřebný obsah, který v aplikaci
zajistí požadovanou funkcionalitu. Toho lze dosáhnout využitím různých způsobů implementace. První způsob využívá značku <iframe></iframe>, do které se načte potřebný obsah. Je
to nejstarší způsob jak načíst do stránky obsah z jiné aplikace. Další možností je využít speciální rozšíření HTML vyvinuté Facebookem – XFBML, které HTML rozšiřuje o nové značky
(a to přidáním nového jmenného prostoru do hlavičky HTML dokumentu). Tyto značky jsou
potom zpracovávány pomocí JavaScript SDK (knihovna pro podporu webových služeb poskytovaných Facebookem). Poslední možností je využít HTML5, které již obsahuje všechny
potřebné atributy, které se v předchozím případě musely rozšiřovat pomocí XFBML. Mezi
často využívané Sociální pluginy patří například „tlačítko Like“, box pro komentování obsahu, tlačítko pro přihlášení k Facebooku a další. Více pluginů je uvedeno na oficiálních
stránkách Facebook Developers.
Druhou možností pro integraci stránky se sociální sítí je využití již zmíněného JavaScript SDK. Podle Facebook Developers obsahuje tato knihovna funkce pro využívání
REST API (starší a nedoporučuje se používat) a Graph API. Všechny uvedené jsou založené
na architektuře REST a v převážné většině využívají JSON jako datový formát pro přenos
dat. Graph API je název pro zatím nejnovější API, které je založené na rozdílném pohledu na
data. Data jsou vnímána jako graf, který se skládá z objektů (lidé, obrázky, události a stránky)
a ze vztahů mezi nimi (přátelství, sdílení nějakého obsahu, označení osoby na fotografii). Toto
rozhraní oproti předchozímu REST API zjednodušuje volání jednotlivých požadavků a dělá
jej tak snáze použitelnějším. Kromě JavaScript SDK, které slouží k práci s Facebook rozhra6 http://developers.facebook.com/
26
ním na straně klienta (prohlížeče), je možné využít také další SDK, například PHP SDK a pro
mobilní platformy iOS SDK a Android SDK.
Následující příklad ukazuje jak jednoduché je získání informací o přihlášeném uživateli v rámci webové aplikace. FB.api je knihovní funkce určená pro zavolání požadavku na
API. Jako první parametr očekává název metody, která se má zavolat (název vychází z REST
architektury) a v druhém parametru je funkce, která se zavolá po získání výsledku.
1
2
3
FB . a p i ( ’ / me’ , f u n c t i o n ( response ) {
a l e r t ( ’ Your name i s ’ + response . name ) ;
});
2.5 Příklady mashupů
Jak je uvedeno v kapitole 2.1.1, mashupy můžeme rozdělit do několika kategorií. Mashup
může pracovat s mapovými podklady, s videem nebo fotkami, může sloužit pro vyhledávání a nakupování zboží přes Internet a také může agregovat informace ze zpravodajských
serverů. Spoustu informací týkající se jednotlivých mashupů poskytuje stránka zabývající se
webovými API obecně – ProgrammableWeb7 . Její součástí je i adresář mashupů, ve kterém
je možné vyhledávat mashupy podle kategorií. V následujícím textu se v krátkosti zmíním
o třech zajímavých mashupech z různých kategorií.
2.5.1 Flightradar24
FlightRadar248 je mashup, který využívá mapové podklady Google Maps a na kterých zobrazuje reálný letecký provoz po celém světě. Aplikace využívá sítě speciálních přijímačů
ADS-B signálu, který v současnosti vysílá zhruba 60% dopravních letadel. Tyto informace se
ukládají na serveru, odkud je vlastní webová aplikace získává a v reálném čase zobrazuje na
Google mapě ikonky letadel značící jednotlivé stroje. Po kliku na stroj aplikace zobrazí detailní informace o letu (výška, rychlost, odkud letí a kam apod.). Flightradar24 také využívá
Twitter a Facebook pro možnost sdílení odkazu na stránku a také pro zobrazování posledních
příspěvků na Twitteru a Facebooku.
2.5.2 Monniter
Dalším zajímavým mashupem je Monitter9 . Tato aplikace spadá do kategorie agregování dat.
Jejím účelem je v reálném čase zobrazovat zprávy obsahující dané klíčové slovo načítané ze
7 http://www.programmableweb.com
8 http://www.flightradar24.com/
9 http://monitter.com/
27
sociální sítě Twitter a zobrazovat je uživatelům. Hlavní výhodou je možnost najednou sledovat
více těchto vyhledávání. Aplikace také umožňuje filtrovat zobrazené zprávy podle lokality.
2.5.3 Earth Album
Aplikace Earth Album10 je určená pro zobrazování obrázků ze sítě Flickr podle vybraného
místa na mapě. Po kliknutí na libovolné místo na mapě se automaticky načtou nejlépe ohodnocené obrázky z vybrané lokality a nabídnou se uživateli k prohlédnutí.
10 http://www.earthalbum.com/
28
3 Praktická část
3.1 Aplikace MyPlaces
Součástí mé bakalářské práce je také aplikace MyPlaces1 , která představuje jednoduchý mashup využívající následující API: GoogleMaps, Facebook, Google Picasa Web Albums a Twitter. Cílem této aplikace je poskytnout uživatelům webovou stránku, ve které můžou sdílet svá
webová alba na Google mapě, vyhledávat alba ostatních uživatelů a mají možnost sdílet alba,
která se jim líbí prostřednictvím Facebooku a dalších sociálních sítí. Zdrojové kódy aplikace
naleznete na přiloženém CD (příloha 1).
MyPlaces se snaží být maximálně jednoduchá a intuitivní, téměř veškerá komunikace
se serverem probíhá pomocí Ajaxu. Pro využití všech funkčností aplikace je potřeba, aby byl
uživatel registrovaný. Registraci je možné provést buď ručním vyplněním údajů anebo prostřednictvím Facebooku a po jejím dokončení dojde k automatickému přihlášení uživatele. Do
aplikace je možné se také přihlásit přímo prostřednictvím Facebooku bez prvotní registrace,
v tomto případě dojde k automatické registraci uživatele. Pokud se jedná o nového uživatele,
aplikace si nejprve vyžádá práva k využívání osobních údajů (přístup k seznamu přátel apod.).
Aby bylo funkční vyhledávání míst podle přátel přihlášeného uživatele, je nutné po každém
přihlášení do aplikace synchronizovat jeho seznam přátel. Protože tato operace chvíli trvá
(v závislosti na počtu přátel), je nutné ji provádět pouze v nutných případech a to například
při přihlášení. Pokud je uživatel úspěšně přihlášen do systému, může pod svým jménem přidávat nová místa. Ke každému místu je potřeba vložit název, popis a jeho umístění na mapě.
Umístění lze vybrat jednoduše buď klikem přímo na editační mapě ve formuláři pro vložení
místa anebo vyplněním vyhledávacího pole v pravé horní části editační mapy. Při psaní jsou
automaticky vyhledávána místa a po jejich výběru dojde k označení místa na editační mapě.
U každého místa lze také vybrat, jestli je místo veřejné nebo není (v takovém případě se zobrazuje pouze samotnému uživateli – použitelné například pokud ještě nemá hotovou editaci
místa, ale chce jej mít už uložené).
Po úspěšném vytvoření místa je potřeba mu přiřadit webové album z aplikace Google
Picasa (odkaz „přiřadit fotogalerii“ v horní části detailu místa). Při prvním pokusu získat
webová alba je potřeba se do externího systému přihlásit. Podobně jako u Facebooku, i zde
si aplikace vyžádá oprávnění přistupovat k uživatelským datům. Po povolení práv se načte
seznam webových alb, přičemž aplikace načítá pouze veřejná alba. Pokud by uživatel přiřadil
1 http://myplaces.micky.cz
29
k místu neveřejné album, nebylo by pro ostatní uživatele dostupné a celá aplikace by tímto
postrádala význam.
Aplikace umožňuje také změnit uživatelská data registrovaného uživatele (ovšem pouze
v rámci aplikace, změny se nepromítnou na Facebooku) a vyhledávat místa. Základní filtr pro
místa se nachází v horní liště a je tvořen vybírací lištou (selectbox). Pro přihlášené uživatele
umožňuje filtrovat pouze místa vložená uživatelem nebo místa vložená jeho přáteli. Další
možností jak vyhledávat místa je použití textového pole (opět v horní liště aplikace), do kterého stačí napsat název místa, které se hledá a stisknout enter. Na mapě by se měly zobrazit
místa odpovídající zadanému názvu.
3.2 Technický pohled
3.2.1 Využité technologie
Využité technologie můžeme rozdělit do dvou základních skupin: na serverové straně a na
klientské straně. Na straně serveru je použit skriptovací jazyk PHP 5.2.10 společně s frameworkem Symfony 1.4.13, který jsem si vybral, protože zjednodušuje a urychluje vytváření
webových aplikací (stejně jako ostatní frameworky) ale také je k němu vytvořena bohatá dokumentace a množství tutoriálů a používá ho rozsáhlá komunita programátorů. Líbilo se mi
také jeho založení na MVC architektuře (model-view-controller). Jeho výraznou výhodou je
i to, že využívá ORM nástroj pro mapování objektového modelu na databázový relační model. Díky tomuto nástroji se práce s databází velice zjednodušuje. Symfony podporuje dva
ORM nástroje: Propel a Doctrine, já si vybral nástroj Doctrine, protože je podle mého názoru
jednodušší na použití. Pro správné fungování Doctrine jsem musel správně nakonfigurovat
framework (především přístupy do databáze) a vygenerovat objektový model podle databázového modelu. Pro vygenerování objektového modelu dodává Symfony speciální skripty, které
se spojí s databází a model vygenerují. Jako databáze je použita databáze MySQL 5.0.67.
Technologie využité na klientské straně, jsou takové, které jsou prováděny na straně
prohlížeče (klienta) a zde prezentují data uživateli, případně zajišťují interaktivitu s aplikací.
Pro prezentaci dat využívá aplikace XHTML společně s CSS 3, které popisuje jak má aplikace vypadat. Pro zajištění interaktivity s uživatelem využívá MyPlaces JavaScript společně
s frameworkem jQuery 1.3.4, který je také využit pro komunikaci pomocí Ajaxu. Do jQuery
jsem také přidal několik zásuvných modulů a to pro lightbox ve kterém se zobrazují fotky
a pro carousel, který zajišťuje zobrazení náhledů fotogalerií v detailu místa.
Pro komunikaci s externími aplikacemi jsou použity speciální knihovny v JavaScriptu,
které jsou dodané výrobcem rozhraní (Facebook, Twitter) anebo speciální knihovny v PHP,
některé dodané výrobcem a některé jsem implementoval sám (Picasa Web Albums). Jako
formát pro výměnu dat je potom použit JSON anebo Atom.
30
Obrázek 3.1: Datový model aplikace
Zdroj: vlastní zpracování
3.2.2 Datový model
Datový model aplikace MyPlaces je velice jednoduchý, skládá se pouze z několika tabulek pro
ukládání nezbytných informací o uživatelích a jejich místech. Ostatní data (například fotky)
jsou dynamicky načítané z externí webové služby. Datový model znázorňuje obrázek 3.1,
který je vytvořen v nástroji MySQL Workbench. Jedná se o program, poskytující potřebné
funkce pro návrh datového modelu a jeho následnou synchronizaci s databází. Aplikace MyPlaces je vyvinutá pro MySQL databázi.
Každá tabulka obsahuje minimálně čtyři sloupce, které popisují základní parametry záznamu. Sloupec id obsahuje unikátní identifikátor záznamu (primární klíč), sloupec
enabled označuje, jestli je možné se záznamem pracovat (zobrazovat jej apod.) a sloupce
created_at a updated_at obsahují datum a čas vytvoření a poslední změny záznamu. Nastavování data a času poslední aktualizace záznamu je docíleno pomocí vlastnosti sloupce
updated_at, který je typu timestamp, což je datový typ, který může mít defaultní hodnotu
CURRENT_TIMESTAMP. Protože tato hodnota může být v rámci jedné tabulky použita
pouze jednou, musel jsem pro nastavování data a času vytvoření (sloupec created_at) použít
triggery.
31
Hlavní tabulkou je users, která obsahuje všechna data týkající se uživatelů. Sloupec
name obsahuje jméno a příjmení uživatele. O obsahu sloupce email vypovídá jeho název.
Tento sloupec je unikátní, protože může být společně se sloupcem password použit pro přihlášení uživatele (pokud se nechce přihlašovat pomocí Facebooku). Pro identifikaci uživatele
na Facebooku slouží sloupec fb_id, který obsahuje unikátní identifikátor uživatele na této síti.
Tento parametr je povinnou součástí většiny požadavků na Facebook API. Sloupec registered_with_facebook identifikuje, že uživatel byl zaregistrován prostřednictvím Facebooku.
Tento sloupec se používá ve validačních funkcích při zjišťování, jestli je heslo povinné nebo
není. Tato tabulka má vytvořený index pro sloupec fb_id a unikátní index pro email. Indexy
zajišťují rychlé vyhledávání i při velkém počtu záznamů.
Tabulka users_fb_friends slouží pro ukládání informací o přátelích uživatelů. Při filtrování je použita pro omezení zobrazených míst na místa přátel přihlášeného uživatele. Tato
tabulka obsahuje základní informace o přátelích, které jsou získané z výsledku volání metody
pro získání seznamu přátel. Každý záznam je spojen se záznamem v tabulce users prostřednictvím cizího klíče podle sloupce fk_users_id. Podobně jako tabulka users, i users_fb_friends
obsahuje index na sloupec fb_id.
Poslední tabulka se jmenuje places. Obsahuje informace o jednotlivých místech vytvořených uživateli. Záznamy jsou spojené s uživateli stejným způsobem jako záznamy z tabulky users_fb_friends – přes cizí klíč. Každé místo obsahuje jméno (sloupec name), popis
(content), souřadnice na mapě (coord_lat, coord_lng) a příznak, jestli je album veřejné nebo
není (public). Při vytvoření místa (nebo při změně názvu) se automaticky generuje speciální
název určený pro seo (sloupec seo_name), který se následně používá pro generování url adresy daného místa. Pro identifikaci webového alba, které je místu přiřazeno slouží sloupce
picasa_album_ident (identifikátor alba) a picasa_album_user_id (identifikace vlastníka alba
– identifikátor uživatele v systému Picasa Web Albums).
3.2.3 Implementace
Jak už bylo napsáno v úvodu praktické části, aplikace je naprogramována v jazyce PHP s využitím frameworku Symfony. Programový kód můžeme rozdělit podle způsobu využití do
několika kategorií. Do první kategorie patří vlastní kód aplikace prováděný na serveru a zajišťující získávání dat z databáze, reakce na uživatelské požadavky a další potřebnou logiku
související s aplikací. Jedná se o sadu controllerů, které jsou volány aplikací. Druhá kategorie
zahrnuje knihovny pro komunikaci s externími službami (prováděné na serveru nebo na straně
klienta) a do třetí kategorie můžeme zařadit tu část aplikace, která zajišťuje prezentování dat
uživateli a umožňuje mu ovládat stránku na straně klienta (HTML šablony, kaskádové styly
CSS, JavaScript). Do aplikace jsem také zavedl napojení na Google Analytics, které umožňuje monitorovat návštěvnost stránek.
32
Popis controllerů
Jádrem celé aplikace je framework Symfony, který definuje základní architekturu aplikace,
strukturu souborů, komunikaci s databází a také zajišťuje automatickou kontrolu vstupních
dat (parametrů). Aplikace je složená ze základních modulů, kterým se v terminologii MVC
říká controller. Každý z těchto modulů se skládá z akcí, které jsou tvořeny programovým
kódem a šablonou pro prezentaci dat. MyPlaces využívá několik controllerů, přičemž ten
hlavní, určený pro obsluhu stránky jako celku, se nazývá map. Zajišťuje zpracování příchozích
parametrů z adresní řádky a následné vygenerování obsahu stránky. Pomocí Ajaxu se potom
volají akce dalších controllerů, jejichž obsah se načítá do definovaných částí obsahu.
Mezi další důležité controllery patří například place, který obsahuje akce pro práci
s jednotlivými místy. Obsahuje akce pro získávání seznamu míst v různých formátech (getJson, getXml), pro práci s místem (saveAjax, removeAjax, addGoogleAlbumSave, addGoogleAlbumRemove) a další akce využívané v aplikaci. Pro práci s uživateli jsou vytvořené controllery login, logout a register. Login a logout slouží pro přihlašování a odhlašování uživatelů. Controller logout je velice jednoduchý, protože obsahuje pouze jednu akci, která smaže
uživatelskou session. Controller login je složitější, protože musí zajišťovat možnost přihlásit
uživatele buď na základě vloženého emailu a hesla anebo prostřednictvím Facebooku. Proces přihlášení pomocí Facebooku je složen ze dvou bloků kódu. Zatímco první blok využívá
JavaScriptového API, které zajistí komunikaci se vzdáleným serverem a získání uživatelské
session, druhý blok je součástí programového kódu PHP a zajišťuje spárování uživatele přihlášeného na Facebook s uživatelem uloženým v databázi MyPlaces (v případě, že takový
uživatel neexistuje, dojde k jeho vytvoření) Na základě znalosti uživatele dojde k vytvoření
nové session přihlášení. Ukázkovou funkci pro přihlášení uživatele prostřednictvím Facebooku uvádím zde:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function fbLogin ( ) {
FB . g e t L o g i n S t a t u s ( f u n c t i o n ( response ) {
i f ( response . authResponse ) {
f b S e s s i o n = response . authResponse ;
} else {
FB . l o g i n ( f u n c t i o n ( response ) {
i f ( response . authResponse ) {
f b S e s s i o n = response . authResponse ;
}
else {
/ / user c a n c e l l e d l o g i n
}
},
{ scope : ’ user_about_me , u s e r _ l o c a t i o n , u s e r _ s t a t u s , email , f r i e n d s _ l o c a t i o n ’ } ) ;
}
} , true ) ;
}
Jedná se o JavaScriptovou funkci fbLogin, která se nejprve pokusí získat status přihlášeného uživatele na Facebooku. Na řádku 2 je volání vzdáleného API, jehož výsledek se
33
zpracovává na řádku 3, a pokud je uživatel již přihlášen, uloží se jeho session do proměnné
fbSession (řádek 4). Pokud není uživatelská session vyplněná, je potřeba zavolat API pro přihlášení uživatele (řádek 6). Volání funkce FB.login očekává dva parametry. První parametr
je funkce, která se zavolá po dokončení požadavku na přihlášení a druhý parametr obsahuje různé nastavení dostupné při přihlašování. V příkladu je uvedena položka scope, která
umožňuje nastavit práva, která aplikace vyžaduje po uživateli pro svou funkčnost. Uživatel
bude požádán, aby tato práva pro aplikaci povolil. V případě úspěšného přihlášení se získá
na řádku 8 uživatelská session a uloží do proměnné fbSession. Tato proměnná je globální proměnná JavaScriptu a je využívána při každém volání Facebook API. Po přihlášení uživatele
je automaticky znovu načtena celá stránka pro inicializaci všech potřebných funkcí.
Podobně jako přihlášení funguje i registrace (controller register). Také umožňuje registraci přímým vložením dat o uživateli anebo pomocí Facebooku. Pokud se chce uživatel
zaregistrovat pomocí Facebooku, proces je založen na dotázání API na informace o uživateli,
následném předvyplnění těchto informací do formuláře (bez hesla) a jeho odeslání na server
jako při standardní registraci. Při prvotním spárování s Facebookem (a potom při každém novém přihlášení) se snaží aplikace získat informace o přátelích přihlášeného uživatele a tyto
informace uložit do tabulky users_fb_friends. Protože tato operace může chvíli trvat (zejména
u uživatelů mající velký počet přátel), můžou být reakce aplikace na uživatele v prvních okamžicích po přihlášení pomalejší.
Pro některé operace s externími službami obsahuje aplikace dva controllery – facebook a google. První z nich zajišťuje pouze synchronizaci přátel uživatele, zbývající funkcionalita je vytvořená v JavaScriptu. Controller google se stará o přihlašování a odhlašování
z aplikace Google Picasa. Proces přihlašování do této aplikace začíná zavoláním akce login
controlleru google (v novém okně prohlížeče). Ten využívá speciální knihovny (popsané dále)
pro autentizaci a autorizaci uživatele. Tyto operace se dokončí po přesměrování na speciální
stránku Google. Po přihlášení dojde k opětovnému přesměrování zpět do aplikace MyPlaces
kde se po úspěšném přihlášení vygeneruje jednoduchý HTML kód, který pomocí JavaScriptu
zpracuje data informující o uživatelské session (v rámci aplikace Google Picasa) a poté zavře
automaticky otevřené okno prohlížeče.
Poslední controller se nazývá js a zajišťuje vygenerování JavaScriptového kódu, který
se načte v aplikaci jako obyčejný JS soubor. Tento způsob je využíván pro nastavení některých
proměnných z aplikace do JavaScriptu.
Popis knihoven pro komunikaci s externími službami
Pro komunikaci s externími službami jsou v této aplikaci využity knihovny, které jsou dodávané společně s rozhraním. Pouze v případě Google Picasa API jsem si musel část knihoven
vytvořit sám, protože MyPlaces využívá novou verzi rozhraní, pro které nejsou knihovny pro
PHP ještě vytvořené.
34
Komunikace s Facebook API je založená z větší části na JavaScriptových knihovnách,
které jsou načítané přímo ze serverů Facebooku. Jak vypadá inicializace FB API ukazuje tento
příklad:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
window . f b A s y n c I n i t = f u n c t i o n ( ) {
FB . i n i t ( {
appId : facebookAppId , / / App ID
s t a t u s : t r u e , / / check l o g i n s t a t u s
c o o k i e : t r u e , / / enable c o o k i e s t o a l l o w t h e s e r v e r t o access t h e s e s s i o n
oauth : t r u e , / / enable OAuth 2 . 0
xfbml : t r u e
/ / parse XFBML
});
/ / Load t h e SDK Asynchronously
( function (d ){
v a r j s , i d = ’ facebook−j s s d k ’ ; i f ( d . getElementById ( i d ) ) { r e t u r n ; }
j s = d . createElement ( ’ s c r i p t ’ ) ; j s . i d = i d ; j s . async = t r u e ;
j s . s r c = " / / connect . facebook . n e t / cs_CZ / a l l . j s " ;
d . getElementsByTagName ( ’ head ’ ) [ 0 ] . appendChild ( j s ) ;
} ( document ) ) ;
Veškeré načtení a provedení potřebných skriptů probíhá asynchronně, takže inicializace nezpomaluje uživatele při práci se stránkou. Základní načtení API zajišťují řádky 11 – 16.
Jedná se pouze o vytvoření nového elementu script s nastaveným parametrem src. Zajímavý
je řádek 14 obsahující adresu API. Tento řádek obsahuje hodnotu cs_CZ a tím se definuje jazykové nastavení pro komunikaci s uživatelem (jinými slovy, tímto jazykem bude Facebook
komunikovat s uživatelem). Vlastní inicializace je zajištěna voláním API funkce FB.init s potřebnými parametry. Parametr appId obsahuje unikátní identifikátor MyPlaces, který je uložen na straně Facebooku. Každá aplikace, která toto API využívá, musí mít tento identifikátor
zaregistrovaný. Status určuje, že aplikace bude získávat aktuální stav přihlášení uživatele, pro
povolení využívání cookies na serveru je potřeba nastavit parametr cookie. Parametr oauth
určuje, jestli bude API využívat nový způsob autentizace uživatele – OAuth 2.0 a pro využití
XFBML (speciální značkovací jazyk pro jednoduché vkládání FB funkcionality do stránky) je
potřeba povolit příslušný parametr. Většina těchto parametrů nejsou povinná (kromě appId),
ale jsou uvedené z důvodu větší přehlednosti.
Pro načtení seznamu přátel uživatele je využit controller facebook a jeho akce loadFriends. Tato akce využívá speciálního dotazovacího jazyka FQL, který je ideální pro flexibilní
dotazování a získání potřebných dat uložených na Facebooku. Jazyk je velice podobný jazyku
SQL, ale na rozdíl od něj je omezen pouze na výběr dat (neobsahuje příkazy pro vkládání,
mazání ani změnu dat). Ukázku volání, která vrátí seznam přátel aktuálně přihlášeného uživatele, si můžete prohlédnout v tomto příkladu:
35
1
2
3
4
5
6
SELECT
uid , f i r s t _ n a m e , c u r r e n t _ l o c a t i o n , last_name , b i r t h d a y _ d a t e , pic_square , sex
FROM user
WHERE
u i d IN (SELECT u i d 2 FROM f r i e n d WHERE u i d 1 = me ( ) )
ORDER BY u i d ASC
Řádek 2 definuje sloupce, které se mají vrátit (jejich název vypovídá o informaci, kterou obsahují), na řádku 3 se definuje, tabulka odkud se budou data získávat a podmínka, kterou musí data splňovat je uvedená na řádku 5. Součástí podmínky je vnořený dotaz, který vrátí
seznam uid všech přátel přihlášeného uživatele (ten se získá pomoc metody me()). Můžeme
také nastavit, jak mají být položky řazeny (řádek 6). Dotaz se provede zavoláním speciální
adresy, jejíž součástí je parametr obsahující zakódovaný FQL dotaz a access_token, který
identifikuje uživatelskou session. Ukázku volání zachycuje následující příklad:
1
2
$ f q l Q u e r y U r l = ’ h t t p s : / / graph . facebook . com / f q l ?q = ’ . u r l e n c o d e ( $fQ ) . ’ & access_token = ’ . $aT ;
$ f r i e n d s = json_decode ( $ t h i s −>jsonParseNumToStr ( f i l e _ g e t _ c o n t e n t s ( $ f q l Q u e r y U r l ) ) ) ;
Řádek 1 nastavuje do proměnné url adresu pro dotazování a přiřazuje do ní parametry
q (zakódovaný dotaz) a access_token identifikující přihlášeného uživatele. Na dalším řádku
se potom zavolá funkce file_get_contents pro načtení výsledku volání takto poskládané url.
Výsledek volání je ve formátu JSON, který se musí opravit pomocnou funkcí jsonParseNumToStr (tuto funkci jsem našel na internetu 2 a použil ji v aplikaci) zajišťující správnou interpretaci velkých čísel (například identifikátor uživatele) v PHP. Funkce json_decode potom
výsledek zkonvertuje do objektové struktury, kterou je možné procházet v cyklu.
V aplikaci je využit ještě jeden způsob propojení aplikace a Facebooku a to již zmíněné XFBML. Je použito na stránce s detailem místa (controller place, akce show) pro vložení tlačítka Like a Facebook komentářů. Tlačítko i komentáře očekávají několik parametrů,
přičemž nejdůležitější je parametr href, který definuje adresu, ke které se prvek váže. V MyPlaces se tedy jedná o adresu detailu místa. Vložení prvků do stránky si můžete prohlédnout
v tomto příkladu:
1
2
< f b : l i k e h r e f ="###URL_DETAILU###" send =" f a l s e " w i d t h ="390" show_faces =" t r u e " > </ f b : l i k e >
< f b : comments h r e f ="###URL_DETAILU###" num_posts = " 5 " w i d t h ="390" > </ f b : comments>
Na prvním řádku je vložení tlačítka Like a druhý řádek zajišťuje vložení komentářů. Obsahují parametr href a některé další parametry, které jsou popsané v dokumentaci
k API3 . V terminologii Facebook API se těmto prvkům říká sociální pluginy. Pro jejich využívání je také potřeba rozšířit hlavičku HTML stránky a do značky html přidat parametr
2 http://stackoverflow.com/questions/7716148/facebook-credits-signed-request-what-is-the-difference-
between-buyer-receiver
3 http://developers.facebook.com/
36
xmlns:fb="http :// ogp.me/ns/fb#", který zajistí možnost validního použití jinak neznámých
značek. Pro flexibilitu sociálních pluginů umožňuje Facebook přidat na stránku, které se prvek týká (tedy například url detailu místa) speciální meta tagy, kterými se definuje například
obrázek, popis a nadpis, který bude zobrazen při sdílení na Facebooku. Metatagy a způsob
jejich využívání je ukázán v následujícím příkladu. Tento blok kódu se umisťuje do hlavičky
stránky.
1
2
3
4
<meta
<meta
<meta
<meta
p r o p e r t y =" og : t i t l e " c o n t e n t ="###NADPIS_SDILENEHO_OBSAHU###"/ >
p r o p e r t y =" og : u r l " c o n t e n t ="###ADRESA_SDILENEHO_OBSAHU###"/ >
p r o p e r t y =" og : site_name " c o n t e n t ="###NAZEV_STRANKY###" / >
p r o p e r t y =" og : d e s c r i p t i o n " c o n t e n t ="###POPIS_SDILENEHO_OBSAHU###"/ >
Pro propojení s Google mapami je opět využita JavaScriptová knihovna poskytovaná
výrobcem API. Podobně jako u Facebook API, i zde se v JavaScriptu vygeneruje element
script, který zajistí načtení potřebných knihoven. Poté lze volat jednotlivé funkce. Pro snadnou práci s rozhraním pro mapy jsem si vytvořil jednoduchou JavaScriptovou knihovnu, která
zapouzdřuje jednu konkrétní mapu umístěnou na stránkách. Její kód je v souboru /web/js/lib/mymap.js a jedná se o třídu s názvem MyMap. Díky zapouzdření mapy a všech informací
o ní do jedné instance je jednoduché v aplikaci pracovat s více mapami. Více map je použito při editaci místa a výběru umístění místa na mapě. Třída MyMap obsahuje základní
instanční proměnné, které slouží pro uchovávání dat potřebných pro fungování třídy, ale také
pro nastavení potřebných parametrů mapy. Důležitou proměnnou je markers, která obsahuje
množinu všech markerů aktuálně umístěných na mapě. V terminologii Google Maps API se
markerem označuje jakékoliv místo na mapě, které může mít přiřazený popis, odkaz, obrázek apod. Markery je vhodné umisťovat do pole (není to nutné, pouze vhodné) kvůli pozdější
práci s nimi. Je možné na nich spouštět různé metody a události, například simulovat kliknutí na marker – toto je použito například při automatickém zobrazení detailu místa. Pro
práci s markery obsahuje třída MyMap funkce placeMarker, placeMarkers, removeAllMarkers, highlightMarker a highlightMarkerAll, které slouží pro umisťování a mazání markerů
z mapy a také pro jejich zvýrazňování barvou uvedenou v nastavení třídy (pomocí instančních
proměnných standardIconImage a highLightIconImage). V aplikaci je také použito vyhledávání na mapě (v editaci místa je součástí Google mapy), které je zajištěno pomocí funkce
google.maps.places.Autocomplete(input);. Tato funkce odchytává události na textovém
poli (které je uvedeno v jejím parametru) a při psaní názvu místa zajišťuje automatické vyhledávání a nabízení nalezených míst (místa jsou získaná z databáze Google Maps).
Načítání seznamu markerů zajišťuje metoda placeAllMarkers. Jako první parametr
očekává adresu XML souboru, ze kterého má načíst místa. V MyPlaces se jako XML soubor
předává odkaz na controller place a jeho akci getXml, která na základě nastaveného filtru
vrátí seznam míst ve formátu XML a ten je následně zpracován metodou placeAllMarkers.
Pro každé místo jsou získány informace o jeho pozici, identifikátoru a také o jeho adrese.
37
Vložení markeru do pole markerů a jeho zobrazení na mapě zajišťuje metoda placeMarker,
která je volaná pro každé získané místo. Při tvorbě třídy MyMap bylo také potřeba vyřešit
inicializaci Google Maps API a to tak, aby se provedla pouze jednou (i v případě používání
více map na stránce). K inicializaci třídy MyMap slouží metoda init, kterou je potřeba zavolat
po vytvoření instance třídy. Init v případě potřeby volá statickou metodu MyMap._init, která
zajistí načtení knihoven API. Po načtení nastaví statickou proměnnou MyMap.apiInitialized
na hodnotu true a při dalším volání metody init (např. při vytvoření nové mapy na stránce) se
již nevolá.
Nejsložitější bylo propojení aplikace s Google Picasa Albums. V současné době jsou
k dispozici dvě verze rozhraní, přičemž já chtěl v aplikaci využít aktuální verzi 2.0. Bohužel
pro tuto verzi není v době psaní práce k dispozici knihovna pro využívání API v PHP. K dispozici jsem měl pouze knihovnu google-api-php-client, která kromě Picasa Albums podporuje
velké množství dalších služeb. Tuto knihovnu jsem použil pouze pro přihlašování do Google
Picasa Albums, které funguje stejně jako do všech služeb Google. Pro přihlášení je využito
OAuth 2.0 a výše uvedená knihovna. Podobně jako u Facebooku, i zde bylo nutné aplikaci
MyPlaces zaregistrovat a získat unikátní identifikátor. Kromě identifikátoru bylo potřeba ještě
správně nastavit redirectUri, což je url adresa, kam se přesměruje prohlížeč po přihlášení
(úspěšném nebo neúspěšném). Všechny konstanty jsou definované v konfiguračním souboru
/apps/frontend/config/app.yml.
Pro komunikaci s Google Picasa Albums jsem vytvořil kolekci speciálních tříd, které
zapouzdřují knihovnu google-api-php-client a vlastní řešení pro komunikaci s Google Picasa
Albums. Hlavní třída se jmenuje GoogleApi a je umístěná v souboru /lib/GoogleApi.php. Při
vytvoření instance třídy GoogleApi se nejprve vytvoří instance třídy apiClient, která reprezentuje klienta pro základní komunikaci s externí službou (je součástí knihovny google-apiphp-client). Před prvním použitím je nutné nejprve nastavit veškeré identifikátory získané při
registraci aplikace a také nastavit po uživateli požadované oprávnění. Toto se provede zavoláním funkce setScopes s uvedením požadovaných parametrů. Ukázku si můžete prohlédnout
v následujícím kódu:
1
2
3
4
5
6
$ c l i e n t −>setScopes (
array (
’ h t t p s : / / picasaweb . google . com / data / ’ ,
’ h t t p s : / / www. g o o g l e a p i s . com / auth / u s e r i n f o . p r o f i l e ’
)
);
Lze vidět, že jako parametr funkce očekává pole řetězců, z nichž každý identifikuje
službu, ke které bude mít aplikace přístup. Po vytvoření instance třídy je již možné komunikovat s externími službami, k tomu slouží několik metod. Pro přihlašování uživatele do
aplikací Google obsahuje třída metody pro autorizaci a autentizaci uživatele (authenticate
a authorize). Ukázka využití třídy GoogleApi je uvedená v tomto příkladu:
38
1
2
3
4
5
6
7
$googleApi = new GoogleApi ( ) ;
i f ( $googleApi −>a u t h e n t i c a t e ( ) ) {
i f ( ! $googleApi −>isLogged ( ) ) {
$googleApi −>a u t h o r i z e ( ) ;
}
}
Při přihlašování je nejprve zavolána metoda pro autentizaci uživatele (řádek 3), která
zajistí uložení speciálního tokenu v session. Tento token je potom používán při ověřování
přihlášení uživatele. Po úspěšné autentizaci je funkcí isLogged otestováno, zda je uživatel
přihlášen a že má správná přístupová práva (řádek 4). Pokud ne, je zavolána metoda pro autorizaci, která přesměruje uživatele na externí adresu, kde musí povolit práva aplikace (řádek
5). Poté je přesměrován zpět. Mezi další metody, které pracují s uživatelskou session patří
logout, která uživatele z aplikací Google odhlásí. Všechny tyto metody využívají knihovnu
google-api-php-client.
Pro komunikaci s Google Picasa Albums jsem vytvořil kolekci tříd, které zapouzdřují data získaná z této služby a také poskytují základní rozhraní pro volání požadavků. Tyto
třídy jsou uložené v souborech GoogleApiPicasa.php, GoogleApiPicasaAlbum.php a GoogleApiPicasaAlbumPhoto.php. První soubor obsahuje hlavní třídy pro práci s webovými alby.
Nejdůležitější třídou uloženou v tomto souboru je třída GoogleApiPicasa, která reprezentuje
klienta, určeného pro volání požadavků. K tomu využívá dvě privátní metody _request a _responseParseXml, které jsou volané veřejnými metodami getAlbums (načtení seznamu alb)
a getPhotos (načtení seznamu fotek konkrétního alba). Proces dotazování na externí službu
začíná jednou z funkcí getAlbums nebo getPhotos a to vygenerováním potřebné url s definovanými parametry a zavoláním metody _request. Zde dojde k inicializaci knihovny Curl, která
se používá pro načítání obsahu url v rámci skriptu. Pro úspěšnou komunikaci je potřeba nastavit správně hlavičky, které budou zasílány externí službě. Mezi vyžadované hlavičky patří
GData−Version: 2 a Authorization : ###TOKEN_TYPE### ###ACCESS_TOKEN###. První
z nich identifikuje použitou verzi API a druhá hlavička umožňuje autorizaci požadavku na
straně externí služby. Po nastavení hlaviček se provede volání url adresy služby a získá se výsledek (který by měl být validní XML soubor). Pokud není výsledek prázdný, dojde k zavolání funkce _responseParseXml a ta zajistí konverzi XML dokumentu do objektové struktury,
kterou lze jednoduše procházet a načítat tak získaná data. Ke konverzi XML na objektovou
strukturu je použita funkce simplexml_load_string.
Aby se práce se získanými daty ještě usnadnila, vytvořil jsem kolekci objektů, do které
je konvertována načtená struktura dat typu SimpleXmlElement. Na rozdíl od této struktury
objektů, mnou vytvořené třídy jsou šité na míru Google Picasa API. Každá třída zapouzdřuje určitá data získaná z požadavku (například album, fotka apod.) a případně je doplněná
o metody, které dokáží dále pracovat s jejím obsahem nebo nějakým způsobem zpracovávat
její data. Funkce getAlbums a getPhotos potom vrací instance těchto tříd. Protože je jedná
39
o třídy, které mají základní funkčnost společnou (načtení dat z SimpleXMLElementu) a liší
se pouze obsahem, který zpracovávají, případně některými funkcemi, vytvořil jsem základní
třídu GoogleApiPicasaSimpleObject, ze které všechny konkrétní třídy dědí. Její hlavní výhodou je automatické zpracování XML struktury (v podobě elementů SimpleXMLElement)
a konverze na objekt knihovny GoogleApiPicasa. Pro definici parametrů, které je potřeba
odchytávat ze SimpleXMLElementu je nutné nějakým způsobem specifikovat názvy atributů
(případně vnořených elementů). Toto je provedeno v děděných třídách definicí atributů třídy.
GoogleApiPicasaSimpleObject potom tyto atributy projde a ze struktury XML si načte potřebné hodnoty. V kódu potom stačí vytvořit konkrétní objekt, v parametru konstruktoru mu
předat strukturu typu SimpleXMLElement a objekt se automaticky zaplní daty (pouze parametry uvedené v deklaraci funkce). Jak už bylo zmíněno, pro získání seznamu webových alb
je použita funkce getAlbums. Tato funkce zavolá url adresu uvedenou zde:
1
h t t p s : / / picasaweb . google . com / data / feed / a p i / user / d e f a u l t ?&access= p u b l i c
V požadavku je skryto několik parametrů, přičemž některé jsou součástí adresy (více
informací v popisu REST architektury 2.3.4) a některé jsou předávány jako GET parametry.
Prvním z těch vložených přímo do adresy je parametr feed a jeho hodnota api. Parametr určuje
charakter vrácených dat a podle specifikace může nabývat hodnot api nebo base. Základní
rozdíl mezi nimi je v množství dat, které jsou vráceny. Hodnota api určuje, že se vrací všechny
data patřící k albu (včetně různých metainformací apod.), zatímco base vrací pouze základní
obsah ve formátu Atom. Dalším parametrem je user a jeho hodnota default. User označuje
uživatele, jehož alba jsou vrácena. Hodnota default označuje aktuálně přihlášeného uživatele,
ale může obsahovat také uživatelské jméno nebo identifikátor uživatele. Poslední parametr je
předáván jako GET parametr a jmenuje se access. Jeho smysl je specifikovat typ alb, které se
mají vrátit a to z pohledu jejich soukromí. Může nabývat hodnot all, private, public a visible.
Jejich podrobná specifikace je uvedená v dokumentaci [18].
Pro zapouzdření webového alba je vytvořená třída GoogleApiPicasaAlbum. Její součástí je definice povolených hodnot parametru access (viz. odstavec výše), které lze potom
používat kdekoliv v aplikaci. Třída obsahuje atributy jednoduchého typu (id, published, updated, title a summary) a atributy komplexního typu, pro které je vytvořena instance příslušné
třídy. Mezi tyto atributy patří category (kategorie alba, třída GoogleApiPicasaCategory),
link (odkaz na album, třída GoogleApiPicasaLink), author (informace o autorovi alba, třída
GoogleApiPicasaAlbumAuthor), media (popis alba ve formátu Media RSS, třída GoogleApiPicasaMedia) a gPhoto (rozšiřující informace o albu, třída GoogleApiPicasaGPhotoAlbum).
Zajímavými atributy jsou media a gPhoto. Tyto atributy jsou totiž ve zdrojovém XML uložené ve speciálním jmenném prostoru, a proto je nutné se při přístupu k nim přepnout do
tohoto prostoru. Způsob načtení gPhoto ukazuje tento příklad:
40
1
2
3
4
$ g P h o t o s S t r u c t = $ x m l S t r u c t −> c h i l d r e n ( ’ h t t p : / / schemas . google . com / photos / 2 0 0 7 ’ ) ;
i f ( i s _ o b j e c t ( $gPhotosStruct ) ) {
$ t h i s −>gPhoto = new GoogleApiPicasaGPhotoAlbum ( $ g P h o t o s S t r u c t ) ;
}
Na prvním řádku vidíme získání dat z určitého jmenného prostoru (dle dokumentace)
a na základě těchto dat potom vytvoříme instanci třídy GoogleApiPicasaGPhotoAlbum. Podobně se vytváří i instance třídy GoogleApiPicasaMedia ukládaná do atributu media.
Třída GoogleApiPicasaAlbum také obsahuje několik funkcí, které jsou v aplikaci používané pro načítání specifických informací o albu. Jednou z nich je funkce getThumbnailImageSrc používaná pro načítání odkazu na náhled alba. Informace o náhledech jsou uloženy
ve třídě GoogleApiPicasaMedia (atribut media), přičemž u náhledového obrázku může být
nastavena jeho velikostech (je možné ji definovat parametrem thumbsize v url adrese volání
služby). Pokud není thumbsize specifikovaný, načítá se náhled s defaultní velikostí. Velikostí
náhledového obrázku je dokonce možné nastavit více, v takovém případě bude vráceno více
odkazů na náhledy. I pro tento případ je funkce getThumbnailImageSrc nachystaná a na vstupu
očekává dva nepovinné parametry $width a $height, které umožňují specifikovat velikost náhledového obrázku. Další důležitá funkce nazývaná getLink se používá pro získání odkazu na
webové album. Těchto odkazů je v popisu alba více (odkazují na výpisy v různých formátech)
a funkce očekává nepovinný parametr $type, který umožňuje specifikovat typ odkazu vrácený
funkcí. Defaultní hodnota parametru je „text/html“. Mezi zbývající užitečné funkce patří getIdent pro získání unikátního identifikátoru alba, getNumberOfPhotos pro získání počtu fotek
a getUserIdent pro získání identifikátoru vlastníka alba. Všechny tyto funkce čerpají data ze
třídy GoogleApiPicasaGPhotoAlbum.
Pro zapouzdření jednotlivých fotek alba je vytvořena třída GoogleApiPicasaAlbumPhoto. Obsahuje podobné atributy jako předchozí třída (category, title apod.) a navíc obsahuje
také atribut content, do kterého je uložená instance třídy GoogleApiPicasaAlbumPhotoContent obsahující odkaz na samotný obrázek (společně s jeho typem – například „image/jpeg“).
Podobně jako při získávání webových alb, i při získávání seznamu fotek je nutné vygenerovat
url volající webovou službu. Jak může url vypadat se můžete podívat zde:
1
2
h t t p s : / / picasaweb . google . com / data / feed / a p i / user /### UID ###/ albumid /### AID###?imgmax=800&
thumbsize =64 ,200
Parametry feed a user mají stejný význam jako v předchozím případě, pouze v tomto
příkladu není použita hodnota user pro aktuálně přihlášeného uživatele, ale identifikátor uživatele. Navíc jsou zde parametry imgmax pro nastavení velikosti, v jaké má být vrácená fotka
(odkaz na ní je uložen v atributu content). O proměnné thumbsize je psáno již výše, tomto příkladu je vidět jak je možné specifikovat více velikostí náhledového obrázku. Důležité je ještě
uvést, že jak do proměnné imgmax, tak do proměnné thumbsize je možné vkládat pouze po-
41
volené hodnoty velikostí, které jsou popsané ve specifikaci. MyPlaces využívá také rozhraní
Twitteru a Google+ a to pro sdílení odkazů na těchto sítích. Implementace je podobná jako
vložení tlačítka Facebook Like a je tedy velice jednoduchá. Stačí pouze vložit kousek kódu
do HTML šablony a veškerá komunikace a funkčnost je zajištěna automaticky (jak ukazuje
následující příklad):
1
2
3
4
<a h r e f =" h t t p s : / / t w i t t e r . com / share " c l a s s =" t w i t t e r −share−b u t t o n "
data−l a n g =" en " data−u r l ="###URL###"
data−t e x t ="###TEXT###" >Tweet < / a>
<g : plusone s i z e ="medium " h r e f ="###URL###" > </g : plusone >
Řádek 1 obsahuje kód pro vložení tlačítka určeného pro odeslání odkazu na aplikaci
na Twitter. V data-url se definuje adresa odesílaná na Twitter (například adresa místa) a do
parametru data-text se vloží předvyplněný text „tweetu“. Na druhém řádku se vkládá tlačítko
pro sdílení na Google+, opět se definuje adresa, která se má sdílet. Protože celá aplikace funguje na Ajaxovém volání skriptů na pozadí, nastal problém při používání tlačítek sociálních
sítí (Facebook, Twitter a Google+) společně s Ajaxem. Při načtení obsahu pomocí Ajax volání nedošlo k vygenerování těchto tlačítek. Problém jsem vyřešil docela snadno a to tak, že
při každém načtení obsahu Ajaxovým voláním se zavolají funkce pro nucené vygenerování
těchto tlačítek:
1
2
3
4
5
6
7
8
9
10
11
i f ( FB ) {
FB . XFBML . parse ( document . getElementById ( ’ r i g h t _ c o n t e n t ’ ) ) ;
}
i f ( t w t t r && t w t t r . w i d g e t s ) {
t w t t r . widgets . load ( ) ;
}
i f ( gapi ) {
g a p i . plusone . go ( ) ;
}
Popis prezentační vrstvy
Prezentační vrstva je ta část aplikace, která se zobrazuje uživateli a případně vykonává kód
na straně klienta (webový prohlížeč). MyPlaces využívá XHTML pro tvorbu šablon stránek,
CSS3 pro popis vzhledu stránek a JavaScript společně s jQuery pro ovládání interaktivních
prvků na straně klienta. Aplikace se skládá z několika hlavních bloků – hlavička v horní části,
a obsahová část pod ní, která je dále složena z mapy a vlastního obsahu. Rozvržení aplikace
můžete vidět na obrázku 3.2. Jak je na tomto obrázku vidět, v hlavičce je umístěné menu
(které se liší pro přihlášené a nepřihlášené uživatele), základní filtr (opět se liší pro přihlášené
a nepřihlášené uživatele), vyhledávací pole s automatickým doplňováním míst a úplně vpravo
je umístěn box se jménem uživatele (pokud je přihlášen). Základní filtr umožňuje přihlášeným
42
Obrázek 3.2: Základní rozvržení aplikace MyPlaces
Zdroj: vlastní zpracování
uživatelům filtrovat místa podle svých přátel a také zobrazovat pouze svá místa. Vyhledávání
v textovém poli potom vyhledává ve všech místech, které splňují podmínku základního filtru.
Pod hlavičkou leží obsahová část, jejíž hlavním prvkem je mapa umístěná vlevo. Tato
mapa je interaktivní, umožňuje přibližovat a oddalovat zobrazení, měnit typ mapy a také reaguje při kliknutí na značku. Mapa je také automaticky načítána při změně vyhledávacího
filtru. Vedle mapy se nachází užší blok, do kterého se na základě akcí uživatele zobrazují
konkrétní data (kliknutí na značku na mapě, výběr položky v menu, zobrazení hlavní stránky
apod.). Na obrázku 3.2 je vidět detail místa. Ten se skládá z nadpisu, autora a popisu. Následuje seznam fotek umístěných v carouselu, sociální tlačítka a úplně dole je umístěn blok pro
vkládání komentářů k místu.
Soubory pro styly jsou umístěné v adresáři /web/css/, který obsahuje adresář vendor/
pro uložení externích pluginů, a tři soubory: main.css (hlavní soubor stylů), map.css (styly pro
mapu) a reset.css použitý pro počáteční vynulování stylů (aby byly defaultní hodnoty nastaveny pro všechny prohlížeče stejně). Podobně jsou rozdělené i JS soubory v adresáři /web/js/.
V adresáři vendor/ jsou uložené pluginy do jQuery a v adresáři lib/ jsou mnou vytvořené
knihovny. Souboru main.js je určený pro všechny hlavní skripty prováděné na stránce. Facebook.js zajišťuje komunikaci s Facebookem a map.js se stará o ovládání mapy (případně
map). Při načtení stránky se nejprve provede inicializace stránky, tím se myslí nastavení událostí na jednotlivé prvky na stránce a načtení obsahu hlavní stránky. Vše se provede po načtení
stránky pomocí funkce ready, kterou poskytuje jQuery. Pro vlastní inicializaci se volá funkce
initContent. Tuto funkci jsem zavedl kvůli Ajaxovým voláním v aplikaci a nutnosti inicializovat stránku i pro tyto dílčí volání. Zde se potom přiřadí prvkům většina událostí a také
43
se inicializují API externích rozhraní. Jak ukazuje následující příklad, funkce očekává jeden
parametr označující identifikátor nadřazeného elementu, pro jehož vnořené prvky se bude
provádět inicializace:
1
2
3
4
5
6
7
8
9
10
11
12
function initContent ( root ) {
//
...
$ ( r o o t + ’ . ajaxForm ’ ) . b i n d ( ’ submit ’ , f u n c t i o n ( event ) {
event . p r e v e n t D e f a u l t ( ) ;
ajaxFormSubmit ( t h i s ) ;
});
//
...
}
Pro načítání obsahu v pravé části je vytvořena funkce showRightContent. Tato funkce
očekává na vstupu dva parametry – první obsahuje url, která bude zavolána pro získání obsahu a druhý parametr je funkce, která se zavolá po úspěšném načtení obsahu. Funkce po
načtení obsahu kromě zavolání inicializační funkce (viz. výše) zavolá také speciální kód pro
Google Analytics, který do databáze zapíše záznam o přístupu na danou url. Vyhledávání
v místech je zajištěno textovým polem. Funkcionalita umožňuje vyhledávat místa podle jejich názvu nebo podle autora místa. Při vkládání hledaného řetězce v textovém poli dochází
k průběžnému vyhledávání míst a jejich nabízení k výběru formou vybírací lišty (viz. obrázek 3.3). Funkčnost je zajištěna pomocí funkce autocomplete, která je součástí jQuery.
Na straně serveru je vyhledávání implementováno controllerem place a jeho akcí getJObrázek 3.3: Filtrování míst
son, kde v parametru se pošle text aktuálně
vloženého řetězce. Akce getJson se postará
o vyhledání míst nebo uživatelů a předá je
zpět ve formátu JSON. Před vypsáním jsou
data ještě mírně upravena a doplněna o třídy
stylů (je to z důvodu, aby bylo možné upravovat vzhled výpisu). Aby mohla aplikace
Zdroj: vlastní zpracování
reagovat na požadavek vyhledání vloženého
řetězce, musely být k textovému poli, lupě
vedle něj a položce z nabídnutého seznamu přiřazeny události na stisk klávesy enter (textové
pole), klik (lupa) nebo výběr položky (seznam položek). Po vyvolání jedné z těchto událostí dojde k zavolání JavaScriptové funkce reloadGoogleMap, u které se v parametru uvede
url adresa pro vrácení seznamu míst (url zahrnuje vyhledávací řetězec). Funkce nejprve vyčistí mapu odstraněním aktuálně zobrazených míst a potom vyvolá požadavek na akci getXml
controlleru place. Výsledkem je seznam míst ve formátu XML, který se potom předá instanci
44
třídy MyMap uložené v proměnné globalMap a pomocí funkce placeMarkers se místa získaná z XML zobrazí na mapě.
3.3 Propojení s externími aplikacemi
MyPlaces je provázána s několika externími aplikacemi. Závislá je na aplikacích Google Maps
a Google Picasa, na nichž je postavená funkčnost MyPlaces. Pro komunikaci s okolím potom
využívá sociální sítě, které sice nejsou nezbytně nutné pro funkčnost, ale jsou vhodné pro
vytvoření komunity uživatelů. Ze sociálních sítí je aplikace nejvíce napojená na Facebook,
protože z něj načítá uživatelská data, umožňuje sdílet přihlášení do aplikace s Facebookem
a také využívá několik sociálních pluginů. O něco méně je propojená se sítěmi Twitter a Google+, na které umožňuje pouze sdílet odkazy na aplikaci a detail místa s uvedením vlastního
komentáře. Z pohledu nastavení v externí aplikaci bylo nutné nastavit aplikaci na straně Google Picasa a na straně Facebooku. U ostatních stačilo pouze volat poskytované rozhraní.
Z tohoto důvodu se v následujícím textu zaměřím na nastavení aplikace pro Google Picasa
a pro Facebook. Zaměřím se především na popis prostředí, ve kterém se externí aplikace
nastavuje a při tom se pokusím popsat jejich možnosti (i ty které jsem nevyužil ve své práci).
3.3.1 Google Picasa
Pro komunikaci s aplikací Google Picasa může být uživatel přihlášen nebo nepřihlášen. Protože při vytváření a editaci místa načítá MyPlaces alba přihlášeného uživatele, bylo potřeba
zajistit přihlašování do Google Picasa. Toto přihlašování je jednotné s přihlašováním do všech
služeb Google. Pro vývojáře je k dispozici několik možností, jak uživatele přihlásit. Já použil nejnovější způsob, který Google poskytuje a tím je OAuth 2.0. Pro využití OAuth 2.0
je nutné aplikaci nejprve zaregistrovat v aplikaci Google APIs Console4 , která představuje
globální rozhraní pro nastavování služeb poskytovaných Googlem. Při vstupu do aplikace
Google APIs Console se v levé části zobrazí lišta s výběrem projektů, které jsou přiřazeny
přihlášenému uživateli. Pod lištou s projekty se nachází menu. Pro nás nejdůležitější položkou je „API Access“, ve které je možné zaregistrovat aplikaci pro použití OAuth 2.0. Na obrázku 3.4 můžeme vidět, že aplikace je definovaná svým názvem a emailem zaregistrovaným
v Google (Branding information). Pod informacemi o produktu se nachází informace o identifikátorech pro webovou aplikaci (Client ID for web applications). Tyto identifikátory jsou
potom definované v aplikaci a využité při přihlašování uživatelů. Důležitým parametrem je
„Redirect URIs“, který nastavuje url adresy, kam se aplikace přesměruje po přihlášení. Toto je
důležité z bezpečnostních důvodů. Po registraci aplikace a získání identifikátorů je již možné
přistupovat k webovým albům a vyžadovat po uživatelích přihlášení.
4 https://code.google.com/apis/console/
45
Obrázek 3.4: Ukázka Google APIs Console
Zdroj: vlastní zpracování
3.3.2 Facebook
Pokud chceme vytvořit aplikaci, která bude komunikovat s Facebookem, musíme ji nejprve
zaregistrovat. První stránka, na kterou by měly směřovat naše kroky před realizaci propojení,
by měla být Facebook Developers5 . Na této stránce lze nalézt téměř vše, co potřebuje vývojář pracující s rozhraním Facebooku. Pro zaregistrování nové aplikace nebo editaci stávající
je v menu odkaz Aplikace. Pro vstup do této sekce musíte být přihlášeni. V levém menu se
zobrazí již vytvořené aplikace nebo aplikace, ve kterých jste zařazeni jako vývojáři. V pravé
části se potom zobrazí detail první dostupné aplikace (viz. obrázek 3.5). V horní části je uveden souhrn nastavení aplikace. Nejdůležitější je ID aplikace, které je použito jako parametr
pro JavaScript API, se kterým aplikace komunikuje. Dalším klíčem je „Tajný klíč aplikace“,
který je použit jako parametr pro dotazování API v některých knihovnách pro komunikaci
s rozhraním (např. PHP apod.). V souhrnu je dále uveden název aplikace, který musí být
unikátní, kontaktní email a adresa aplikace. Adresa aplikace je uvedena z bezpečnostních důvodů. V případě, že bude FB aplikace někam přesměrovávat, může přesměrovat pouze na
tuto adresu. K přesměrování dochází, pokud se aplikace snaží přihlásit do Facebooku pod
uživatelem na straně serveru (například pomocí PHP, ne pomocí JavaScriptu). Na stránce
dále najdeme seznam rolí uživatelů přiřazených k aplikaci. Facebook rozlišuje několik typů
uživatelských rolí: administrátor, developer, tester, uživatel pro náhled do aplikace a testovací
uživatel. První čtyři typy rolí se liší svými oprávněními v nastavení aplikace. Testovací uživatel je speciální uživatel pro usnadnění testování aplikace (proto není nutné testovat s reálnými
uživateli). Další dva bloky – Protokol Open Graph a Statistiky nejsou v MyPlaces využívané
a proto jsou prázdné.
Pokud klikneme na odkaz „Upravit nastavení“, zobrazí se obrazovka podobná té,
jak ukazuje obrázek 3.6. V první části máme možnost resetovat klíč App Secret (Tajný klíč
aplikace, viz. obrázek 3.5) a nastavit obrázek a ikonku aplikace (ty se potom zobrazují ve vy5 http://developers.facebook.com/
46
Obrázek 3.5: Detail aplikace ve Facebook Developers
Zdroj: vlastní zpracování
skakovacích oknech vyvolaných aplikací). Dále zde můžeme nastavit informace, které jsme
viděli ve shrnutí na obrázku 3.6. Je možné také zvolit kategorii aplikace a povolené domény,
odkud bude možné s aplikací komunikovat. Nakonec je potřeba vybrat způsob, jakým se bude
aplikace integrovat do Facebooku. MyPlaces využívá první možnosti – „Přihlášení pomocí
Facebooku“. Tento způsob v podstatě umožňuje webové aplikaci načítat data uživatelů a pracovat s nimi. Facebook také umožňuje vytvořit aplikaci přímo v prostředí Facebooku. V praxi
to potom vypadá tak, že aplikace si načte obsah ze zvolené adresy a otevírá se přímo v rozhraní
Facebooku. Dále je možné zvolit typ aplikace pro mobilní platformy (Apple iOS nebo Android). Pokud jsme v záložce základního nastavení, zobrazí se v levém menu další odkazy pro
podrobnější nastavení. Pod prvním odkazem „Auth Dialog“ se skrývá nastavení autorizačního okna, které se vyvolává v případě, že uživatel nemá dostatečná oprávnění pro aplikaci.
Je zde možné nastavit různé texty (shrnutí aplikace, doplňkový název aplikace apod.), adresu
ochrany osobních údajů a je také možné nastavit vyžadovaná oprávnění. Toto nastavení rozšiřuje konfiguraci propojení přímo v aplikaci MyPlaces. Po provedení nastavení je také možné
si nechat zobrazit náhled okna.
Pokud se podíváme na další položku v levém menu, nalezneme zde podstránku „Rozšířené“. Zde je možné nastavit podrobnější nastavení aplikace. U každé položky se objevuje
znak „?“ a pokud na něj najedeme myší, zobrazí se nápověda ke každé konkrétní položce.
Za zmínku stojí například nastavení „režimu pískoviště“ (sandbox). Tento režim povoluje využívání aplikace pouze vývojářům. Je také možné zde definovat restrikce na uživatele, kteří
můžou aplikaci využívat a to jak omezení podle země uživatele, tak podle jeho věku. Je také
možné upozornit Facebook, že aplikace souvisí s alkoholem a on se pak snaží zajistit, aby ne-
47
Obrázek 3.6: Nastavení aplikace ve Facebook Developers
Zdroj: vlastní zpracování
bylo možné používat aplikaci v zemích, kde by její použití nemuselo být legální (v závislosti
na věku uživatele). Zároveň ale uvádí, že tvůrce aplikace je zodpovědný za obsah stránky.
Další dvě záložky – „App Center“ a „Localize“ slouží pro nastavení vzhledu a lokalizace aplikace v Centru aplikací. Centrum aplikací je stránka vytvořená Facebookem6 , která
poskytuje databázi aplikací běžících v prostředí Facebooku. Jedná se o nástroj určený pro zviditelnění aplikací, který umožňuje vyhledávat je podle kategorií, hodnocení nebo oblíbenosti.
Pokud bychom chtěli vytvořit podobnou aplikaci, museli bychom využít nastavení v těchto
dvou záložkách. Protože MyPlaces nevyužívá centrum aplikací, nemusel jsem zde nic nastavovat. V pořadí další záložkou v levém menu je záložka „Protokol Open Graph“. Tento
protokol je určen pro nastavení způsobu zobrazení informací z aplikace na Facebooku. Pro
každou aplikaci využívající Open Graph je možné definovat reálné objekty, se kterými aplikace pracuje (například film, kniha, restaurace), a pokud uživatel v aplikaci provede u tohoto
objektu nějakou akci, například klikne na tlačítko Like, v jeho profilu se zobrazí informace
v příslušné kategorii. Hlavním účelem Open Graph je tedy pracovat se sémantikou (významem) sdílených informací.
V záložce „Úlohy“ je možné definovat role uživatelů zainteresovaných do vývoje
aplikace. Jedná se o stejné nastavení jako v souhrnném nastavení aplikace. Další záložka
se jmenuje „Kredity“ a umožňuje nabízet lidem virtuální dárky nebo jiné služby. Poslední
záložkou v levém menu je „Insights“ určená pro zobrazování statistik aplikace. Zde najdete
přehledy o aktivitě uživatelů, počtu návštěvníků a další statistiky aplikace.
6 http://www.facebook.com/appcenter/
48
Obrázek 3.7: Aplikace „Object Debugger“
Zdroj: vlastní zpracování
Pod levým menu najdeme také odkazy pro různé testovací nástroje usnadňující vývoj
nových aplikací. Jednou z nich je „Object Debugger“7 , sloužící pro ladění informací protokolu Open Graph. Do vstupního formuláře se vloží url adresa stránky, která se má otestovat
a po odeslání aplikace zobrazí informace z testované stránky s upozorněním na případné
nedostatky, které je potřeba opravit. Obrázek 3.7 ukazuje, jak vypadá výsledek debuggeru.
Nejzajímavější částí je blok pojmenovaný „Object Properties“, který zobrazuje načtené informace z metainformací. Mezi metainformace získané pomocí Open Graph patří webová adresa
objektu (og:url) a typ objektu (og:type) Typ objektu může nabývat pouze povolených hodnot, ale Facebook umožňuje vytvářet i vlastní typy. Důležité jsou potom především informace,
které jsou použity pro zobrazení příspěvku na zdi Facebooku, mezi tyto patří nadpis příspěvku
(og:title), jeho popis (og:description) a obrázek (og:image). Tento obrázek musí mít nejmenší
velikost 200px, jinak se nezobrazí. Mezi další nástroj poskytnutý Facebookem pro vývojáře
patří „Graph API Explorer 8 “ který umožňuje ladit dotazy pro Graph API a FQL Query. Nástroj poskytuje jednoduché rozhraní, kde můžete do vstupního pole psát dotaz, a po odeslání
se zobrazí výsledek. Zároveň poskytuje nápovědu ve formě klíčových slov, které lze vkládat
do požadavku.
Jak vypadá výsledná integrace sociálních pluginů Facebooku do aplikace ukazuje obrázek 3.8. Nejprve je vložené tlačítko Like, na které se po kliknutí zobrazí okno s možností
vložit vlastní komentář. Pod ním je vložený plugin pro vkládání komentářů k místům, který
umožňuje také nastavit, jestli bude výsledný komentář zobrazen na Facebooku. Na stránce Facebook Developers9 je přehled sociálních pluginů, které Facebook podporuje. Kromě „Like
Button“ a „Comments“, které jsem použil v MyPlaces, zde najdeme například také „Send
7 https://developers.facebook.com/tools/debug
8 https://developers.facebook.com/tools/explorer/
9 http://developers.facebook.com/docs/plugins/
49
Button“ pro posílání zpráv přátelům, „Login Button“ pro přihlašování uživatelů, „Activity
Feed“ pro zobrazování aktivit na Facebooku a další. Každý plugin má svá specifická nastavení, které ovlivňují jeho vzhled, ale také způsob jakým se vkládá do stránky.
Pro „Like Button“ probíhá nastavení ve dvou
krocích. V prvním kroku se nastavuje poObrázek 3.8: Sociální pluginy
doba tlačítka. Je možné si vybrat ze tří základních podob a to zobrazení tlačítka bez
čísla udávající počet celkových „like“ pro určitou adresu, s číslem vedle tlačítka a s číslem zobrazeným v bublině nad tlačítkem.
Je také možné nastavit šířku tlačítka, povoZdroj: vlastní zpracování
lit zobrazení stínu, zvolit si barevné schéma
(světlé, tmavé) a nebo vybrat jeden z nabízených fontů, který bude použit v tlačítku. Po zvolení parametrů tlačítka stačí kliknout na odkaz
„Get Code“ a zobrazí se okno s vygenerovaným kódem, který stačí pouze zkopírovat a vložit do stránek. Tlačítko bude vygenerováno v takové podobě, jaká byla zvolená v nastavení.
Kód může být vygenerován pro několik technologií (zmíněných v teoretické části, 2.4.3) –
HTML5, XFBML a IFrame. V aplikaci MyPlaces jsem využil XFBML. V dalším kroku je
možné vygenerovat metainformace pro stránku, ke které se váže tlačítko „Like“. Jak už bylo
v této práci zmíněno, metainformace využívají protokol Open Graph. Podobné nastavení lze
provést i pro „Comments“. Opět je možné nastavit vzhled boxu s komentáři – šířka, barevné
schéma a navíc počet zobrazených příspěvků. Výsledný kód se opět zobrazí po kliku na tlačítko „Get code“.
3.3.3 Twitter, Google+
Pro sdílení informací na Twitteru slouží tlačítko „Tweet“. Nejjednodušší cesta jak vložit tlačítko na webové stránky je s využitím JavaScriptu (způsob je podobný jako
u XFBML). Vzhled tohoto tlačítka je také
možné nastavovat a to pomocí parametrů,
které jsou přehledně popsané na stránce
Twitter Developers10 . Parametr je možné nastavit několika způsoby (uvádím v pořadí od
nejvyšší priority po nejnižší prioritu) – definicí přímo v adrese pro načtení tlačítka,
Obrázek 3.9: Ukázka „Tweet“ okna
Zdroj: vlastní zpracování
10 https://dev.twitter.com/docs/tweet-button
50
uvedení v atributu tagu <a> (uvádí se s prefixem „data–“), zapsáním do atributu rel tagu
<a> (možné definovat pouze některé parametry) a jako poslední možnost je ponechat standardní nastavení. V aplikaci MyPlaces jsem využil definici pomocí atributů s prefixem
„data–“. Z nastavení, které je možné použít, můžeme jmenovat například „data–url“ pro
definici adresy, která se posílá na Twitter, „data–via“ pro definici uživatele, pod kterým se
„tweet“ posílá, „data–text“ pro nastavení textu, který bude předvyplněný (viz. obrázek 3.9).
Pro tlačítko je také možné nastavit pozici čísla udávající počet „tweetů“ („data-count“) a jeho
velikost („data-size“). Pro tlačítko „+1“ určené k sdílení na Google+ existuje, podobně jako
pro Facebook, jednoduchý nástroj, který vygeneruje potřebný kód. To lze v aplikace Google Developers11 , kde je možné si vybrat velikost tlačítka a jazyk tlačítka. V rámci pokročilejšího nastavení je možné také definovat „JS callback function“, které definuje JS funkci
volanou po kliknutí na tlačítko. Nástroj opět vygeneruje kód, který stačí vložit do stránek.
Po kliknutí na tlačítko „+1“ se zobrazí okno se zobrazenými informacemi zísObrázek 3.10: Sdílení na Google+
kané pomocí protokolu Open Graph (stejně
jako Facebook). V okně je také možné vložit
vlastní text a vybrat okruh kde se bude informace sdílet (viz. 3.10).
3.4 Zhodnocení aplikace
Výsledkem mé praktické části je vytvořená
aplikace MyPlaces, jejímž cílem je poskytZdroj: vlastní zpracování
nout registrovaným uživatelům přehledné
prostředí pro publikování svých webových
alb na mapě. Aby bylo možné tyto alba a vytvořená místa sdílet mezi ostatními, poskytuje pro každé místo možnost odeslat jej do sítě Facebook, Twitter nebo Google+. Aplikace
je primárně laděná pod webovým prohlížečem Google Chrome a Firefox, ale měla by bez
problémů fungovat i v Internet Exploreru 8+. Pouze v Internet Exploreru jsem se setkal s pomalejší odezvou, což je podle mého názoru dáno obecně pomalejším prohlížečem.
Protože jsem se při konzultacích ohledně aplikace setkal s názory, že lidé příliš nechápali, k čemu je aplikace dobrá, umístil jsem na hlavní stránku návod jak aplikaci používat.
Návod je posloupnost pěti kroků, od registrace, přes vytvoření webového alba, místa a jejich propojení až po vyhledávání. Aby byla aplikace také uživatelsky přívětivá, snažil jsem se
maximum akcí provádět na pozadí pomocí Ajaxu. Toto se mi myslím podařilo, jediné obnovení stránky nastane při přihlašování a odhlašování uživatele. V aplikaci se také na některých
11 https://developers.google.com/+/plugins/+1button/
51
místech vyvolávají vyskakovací okna (zejména při přihlašování nebo registraci pomocí Facebooku), proto jsem tam přidal červenou hlášku, která je upozorňuje na nutnost mít povolená
vyskakovací okna. Do aplikace jsem také přidal sledování návštěvnosti pomocí Google Analytics a to umožňuje sledovat různé statistiky týkající se návštěvnosti stránek. Bude tak zajímavé
sledovat, jestli sociální sítě budou zvyšovat návštěvnost aplikace.
Aplikaci by bylo možné dále vylepšit, doplnit ji například o propojení s alby uloženými na Facebooku, udělat hezčí vzhled „markerů“ na mapě. Dobrým nápadem by bylo také
vytvořit stránku na Facebooku, která by byla s aplikací propojená, a jejím cílem by bylo podporovat komunitu uživatelů používající aplikaci. Ke zvýšení uživatelské přívětivosti by bylo
možné udělat upload fotek přímo z aplikace na Google Picasa.
52
4 Závěr
V této práci jsem se zabýval webovými aplikacemi, jejichž hlavní charakteristikou je využívání více webových služeb současně. Mashupy, jak se tyto aplikace nazývají, zažívají v posledních letech „boom“ a každý den vznikají nové aplikace s rozmanitou funkčností. Může
se jednat o mapové aplikace, aplikace pracující s fotkami, videem, aktualitami nebo sociálními sítěmi. Zejména v posledních letech začínají vývojáři propojovat mashupy se sociálními
sítěmi, jelikož ty můžou být potencionálním zdrojem návštěvnosti. Webové aplikace se začínají zaměřovat na budování komunit uživatelů, kteří se na stránky neustále vrací. Protože
současné aplikace jsou odlišné od těch vytvořených v devadesátých letech minulého století,
není překvapivé že pro ně vzniklo nové označení – Web 2.0.
V první části mé práce jsem se zabýval teoretickým úvodem do problematiky mashupů, webových aplikací a služeb. Nejprve jsem čtenáře s tímto pojmem seznámil a popsal
vývoj webu od jeho zrodu až po moderní webové aplikace. V následující kapitole jsem se
zaměřil na technologie určené pro vytváření webových aplikací. Hlavní charakteristiky a historický vývoj jsem se snažil popsat u několika významných protokolů a datových formátů. Na
závěr teoretické části jsem popsal několik oblíbených webových služeb a v krátkosti zmínil
tři ukázky mashupů.
Součástí praktické části je webová aplikace a mashup, jehož cílem je vytvořit prostředí
pro publikaci fotogalerií vytvořených v Google Picasa na mapě. Celá aplikace je také propojená se sociálními sítěmi. Při vývoji aplikace jsem se tak prakticky setkal s technologiemi
popsanými v teoretické části. U některých služeb jsem si také vyzkoušel nastavení rozhraní
na straně webové služby a objevil další možnosti které API nabízí.
Myslím si, že práce byla pro mě přínosem, dokázal jsem se zorientovat v množství používaných technologií a některé z nich si potom prakticky vyzkoušet. Zjistil jsem, že vytvořit
mashup není příliš složité, ale že hlavním problémem a příčinou neúspěchu velkého množství
mashupů, je především vytvořit aplikaci se smysluplnou funkčností a především komfortním
uživatelským prostředím, které bude vynikat nad ostatními aplikacemi podobného typu.
53
5 Conclusion
In this work, I dealt with web applications, which are basically characterised by the use of
several web services at a time. Mashups, as these applications are called, have been booming
in recent years; every day, new applications are created, featuring various functions. These
can involve map applications, applications working with photos, videos, news and social networks. It has been quite usual recently, that developers have begun to link mashups with
social networks, which can be a potential source of visits. Web applications are starting to
focus on the creation of communities of users, who tend to come back to the pages. Since the
current applications differ from those developed in the 1990s, it is not surprising that a new
name has been created for them - Web 2.0.
In the first part of my thesis, I dealt with the theoretical introduction to the issue of
mashups, web applications and services. First of all, I introduced the term to the readers and
described the development of the web from its origination up to modern web applications.
In the next chapter, I focused on technologies intended for designing web applications. I tried
to describe the main characteristics and historical development of several important protocols and data formats. The theoretical part ends with the description of several popular web
services and brief reference to three examples of mashups.
The practical part includes also a web application and a mashup, which is aimed at
creating the environment for publishing photographs created in Google Picasa on a map. The
whole application is linked with social networks. In developing the application, I encountered the technologies described in the theoretical part in practice. Working with some of the
services, I could try to set up an interface on the part of a web service and found new features
offered by API.
I think the thesis is of great benefit to me, I managed to familiarise myself with the
numerous technologies and to try some of them in practice. I found out that it is not very
difficult to create a mashup, but the main problem and reason for so many mashups failing is
primarily that the application should be developed with meaningful functions and primarily
comfortable user environment, which will stand out from other applications of a similar type.
54
Literatura
[1] The emergence of Web 2.0 and mashups [online]. 2009.
Dostupné
z:
http://searchcrm.techtarget.com/feature/
The-emergence-of-Web-2-0-and-mashups.
[2] The evolution of the Web [online]. 2011. Dostupné z: http://evolutionofweb.
appspot.com/.
[3] Evropská organizace pro jaderný výzkum [online].
Dostupné z: http:
//cs.wikipedia.org/wiki/Evropsk%C3%A1_organizace_pro_
jadern%C3%BD_v%C3%BDzkum.
[4] Facebook statistics [online]. Facebook, 2012. Dostupné z: http://newsroom.fb.
com/content/default.aspx?NewsAreaId=22.
[5] Back to basics [online]. Google, 2007. Dostupné z: http://googleblog.
blogspot.com/2007/04/back-to-basics.html.
[6] Google To Acquire YouTube [online]. Google, 2006. Dostupné z: http://www.
google.com/press/pressrel/google_youtube.html.
[7] Internet Access - History [online]. 2012. Dostupné z: http://en.wikipedia.
org/wiki/Internet_access#History.
[8] Introducing JSON [online]. Dostupné z: http://www.json.org/.
[9] From XML-RPC to SOAP: A Migration Guide [online]. 2002. Dostupné z: http:
//www.xml.com/pub/a/ws/2002/12/18/endpoints.html.
[10] SOAP Version 1.2 [online]. W3C, 2007. Dostupné z: http://www.w3.org/TR/
soap/.
[11] [online]. socialbakers.com, 2012.
com.
Dostupné z: http://www.socialbakers.
[12] Tim Berners-Lee, Director [online]. Dostupné z: http://www.w3.org/People/
all#timbl.
55
[13] Web Services Architecture [online]. W3C, 2002. Dostupné z: http://www.w3.
org/TR/2002/WD-ws-arch-20021114/#whatisws.
[14] The size of the World Wide Web (The Internet) [online]. Dostupné z: http://www.
worldwidewebsize.com/.
[15] The Evolution of XML [online]. O’Reilly & Associates, 2002. Dostupné z: http:
//docstore.mik.ua/orelly/xml/xmlnut/ch01_04.htm.
[16] Introducing XML [online]. O’Reilly & Associates, 2002. Dostupné z: http://
docstore.mik.ua/orelly/xml/xmlnut/ch01_01.htm.
[17] Extensible Markup Language (XML) 1.1 [online]. W3C, 2006. Dostupné z: http:
//www.w3.org/TR/2006/REC-xml11-20060816/.
[18] Picasa Web Albums Data API [online]. 2012. Dostupné z: https://developers.
google.com/picasa-web/.
[19] jQuery History [online]. jQuery Foundation, 2012. Dostupné z: http://jquery.
org/history.
[20] BERNERS-LEE, T. Information Management: A Proposal [online]. 1989. Dostupné z:
http://www.w3.org/History/1989/proposal.html.
[21] BOARD, R. A. RSS - Specification History [online]. Dostupné z: http://www.
rssboard.org/rss-history.
[22] BUREš, J. Atom 1.0 [online]. interval.cz, 2006. Dostupné z: http://interval.
cz/clanky/atom-10/.
[23] CHOW, S.-W. Programujeme Mashup aplikace pro Web 2.0 v PHP. Computer Press,
2008. ISBN 978-80-251-2057-6.
[24] CROCKFORD, D. The application/json Media Type for JavaScript Object Notation
(JSON) [online]. 2006. Dostupné z: http://www.ietf.org/rfc/rfc4627.
txt?number=4627.
[25] DINUCCI, D. Fragmented future. 1999. Dostupné z: http://www.darcyd.com/
fragmented_future.pdf.
[26] FIELDING, R. T. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. Dostupné z: http:
//www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
56
[27] GARRETT, J. J.
Ajax: A New Approach to Web Applications [online]. 2005.
Dostupné z: http://www.adaptivepath.com/ideas/
ajax-new-approach-web-applications.
[28] GROUP, R. W. Resource Description Framework (RDF) [online]. W3C, 2004. Dostupné z: http://www.w3.org/RDF/.
[29] GUBE, J.
The History of Web Browsers [online]. 2009.
Dostupné
z:
http://sixrevisions.com/web-development/
the-history-of-web-browsers/.
[30] HINTON, B.
The Evolution of Web Services Development in an
RIA World [online]. 2010.
Dostupné z: http://tech.lds.org/
index.php/component/content/article/1-miscellanous/
306-the-evolution-of-web-services-development-in-an-ria-world.
[31] JAMES, P. Representational State Transfer (REST) [online]. 2011. Dostupné z: http:
//www.peej.co.uk/articles/rest.
[32] LENSSEN, P. Google Picasa Web Albums Live [online]. 2006. Dostupné z: http:
//blogoscoped.com/archive/2006-06-14-n55.html.
[33] M. NOTTINGHAM, R. S. RFC 4287 - The Atom Syndication Format [online]. The
Internet Society, 2005. Dostupné z: http://www.faqs.org/rfcs/rfc4287.
html.
[34] MERRILL, D. http://www.ibm.com/developerworks/xml/library/x-mashups/index.html
[online]. 2006. Dostupné z: http://www.ibm.com/developerworks/xml/
library/x-mashups/index.html.
[35] PEENIKAL, S. Mashups and the enterprise, 2009. Dostupné z: http://www.
mphasis.com/pdfs/Mashups_and_the_Enterprise.pdf.
[36] R. T. FIELDING, R. N. T. Principled Design of the Modern Web Architecture, Květen 2002. Dostupné z: http://www.ics.uci.edu/~taylor/documents/
2002-REST-TOIT.pdf.
[37] RUBY, S. Rss20AndAtom10Compared [online]. 2008. Dostupné z: http://www.
intertwingly.net/wiki/pie/Rss20AndAtom10Compared.
[38] SINGH, T.
REST vs. SOAP – The Right WebService [online].
2009.
Dostupné
z:
http://geeknizer.com/
rest-vs-soap-using-http-choosing-the-right-webservice-protocol/.
57
[39] STEVE GRAHAM, D. D. a. k.
Building Web Services with Java.
Sams
Publishing, 2004.
Dostupné z: http://www.informit.com/articles/
article.aspx?p=327825. ISBN 978-0672321818.
[40] SVENNERBERG, G.
Beginning Google Maps API 3 (Expert’s Voice in
Web Development).
Apress, 2010.
Dostupné z: http://www.amazon.
com/Beginning-Google-Experts-Voice-Development/dp/
1430228024%3FSubscriptionId%3D0JYN1NVW651KCA56C102%26tag%
3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative%
3D165953%26creativeASIN%3D1430228024. ISBN 978-1430228028.
[41] WINER, D. XML-RPC Specification [online]. 2003. Dostupné z: http://xmlrpc.
scripting.com/spec.html.
58
Seznam obrázků
2.1
2.2
Vývoj počtu stránek v letech 1990 - 2008 . . . . . . . . . . . . . . . . . .
Architektura orientovaná na služby . . . . . . . . . . . . . . . . . . . . . .
15
18
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
Datový model aplikace . . . . . . . . . . .
Základní rozvržení aplikace MyPlaces . . .
Filtrování míst . . . . . . . . . . . . . . . .
Ukázka Google APIs Console . . . . . . .
Detail aplikace ve Facebook Developers . .
Nastavení aplikace ve Facebook Developers
Aplikace „Object Debugger“ . . . . . . . .
Sociální pluginy . . . . . . . . . . . . . . .
Ukázka „Tweet“ okna . . . . . . . . . . . .
Sdílení na Google+ . . . . . . . . . . . . .
31
43
44
46
47
48
49
50
50
51
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Seznam příloh
1. CD se zdrojovými kódy aplikace a elektronickou verzí bakalářské práce
a) myplaces/ – adresář s aplikací MyPlaces
i. myplaces/source/ – zdrojové kódy aplikace
ii. myplaces/db/ – export struktury databáze
iii. myplaces/install.txt – popis instalace
b) BP_Brauner_Michal_ucla368.pdf - elektronická verze bakalářské práce
60