Facebook vs Google - zlo vs zlo

Vždy mě bavilo pozorovat firmy jako je Facebook, Google, Twitter či Amazon. Za poslední dvě dekády se tyto firmy dokázaly dostat na vrchol a ukázat světu, že i při minimálních nákladech lze rozjet miliardový byznys.

V každém desetiletí lze najít firmu, která jako štika propluje kolem zkostnatělých molochů a prodere se na vrchol. Povedlo se to Applu, Microsoftu, Googlu a i Facebooku. Všechny tyto společnosti spojuje to, že jako mladá začínající firma si zvolili novou cestu, kterou do té doby nikdo neprozkoumal. Ať už to byli osobní počítače, operační systém pro všechny či sociální síť. Na začátku vždy vzbuzovali spíše úsměv na tvářích velkých IT gigantů, kteří jejich snahu viděli jako slepou uličku.

V dnešní době snad již nikdo nepochybuje o tom, že v dalším desetiletí se objeví jiná dravá ryba, která se opět prožene kolem velkých žraloků a získá své prvenství. Než k tomu ovšem dojde, budeme si muset vystačit s tím, co zde máme.

I když se dnes dá mluvit o jakési renezanci Microsoftu (díky změně vedení), která je viditelná jak v podobě snahy otevřít .NET či ve snaze začít chápat Windows jako službu, tak spíše se chci zaměřit na další dva velké hráče, které považuji za firmy udávající IT trend.

Facebook a Google

Facebook není jen místo, kde se dá povídat s kamarády. Google není jen internetový vyhledávač. Kdokoli, kdo se kdy více zajímal o IT a o to, co tyto firmy skutečně dělají, tak ví, že jejich snaha dávno převyšuje jejich původní cíl. Facebook, stejně jako Google, mají totiž ambice stát se hlavní entitou internetu a tím v podstatě internet pohltit.

Google k tomuto účelu používá různé služby, které lidem servíruje až pod nos. Díky androidu je to v podstatě ekosystém, ve kterém si lze vytvořit svůj vlastní svět.

Facebook má tuto roli o dost jednodušší. Díky pohlcení lidstva do sociální sítě má k dispozici vlastní univerzum, ve kterém si sám může určovat pravidla.

Temná strana

Každý asi očekává, že zde budu psát o tom, jak jsou tyto firmy nebezpečné z pohledu soukromí. Jistě by to byla pravda, ale jako člověk, který je zaměřen víc technicky si odpustím filozofování o tom, kde je ona míra ztráty soukromí. Osobně si myslím, že tu si každý musí a hlavně stále ještě může (i když už dost pracně), zvolit sám.

Na těchto firmách mi vadí jiná věc.

Temná strana Googlu

Google si za poslední dobu vybudoval dost špatnou pověst, co se týče poskytování nových technologií a služeb. Zvolit si Google jako hlavního technologického vendora je asi to samé jako vsadit na chrtí závody. Mnoho firem by mi jistě dalo za pravdu, když si zvolili Dart, GWT či Angular 1 jako hlavní technologii. Google má totiž tu úžasnou vlastnost, že pro něj není problém "zaříznout" cokoli, co se mu jednoduše nelíbí či nehodí. Stejně jako jejich služby, které mnozí využívali. Buď je Google zruší či změní tak, že se jedná o naprosto jinou věc.

Osobně bych byl více než opatrný v tom, jakou technologii od Googlu použít. A pokud někdo argumentuje: "Ale však za tím stojí velký Google", tak se na to dá odvědit pouze: "No právě proto".

Temná strana Facebooku

Facebook je z pohledu IT o dost mladší firma, která ovšem chytla ještě horší manýry než jaké má Google se svým: "Rušíme službu". Facebook totiž dělá něco mnohem horšího....
Jak jsem již uvedl, Facebook pohltil lidstvo do sociální sítě. Díky tomu získal jednu úžasnou věc a to je "institucionalizace". Všichni jsme díky Facebooku "popsatelní". Tohoto fenoménu začalo využívat mnoho dalších firem, kteří svůj byznys postavili na tom, že mají vše na dlani. Mají možnost získat informaci o tom kdo jste, s kým se přátelíte, co máte rádi, apod.
Jistě si každý dovede představit k čemu se toto dá využít. Cílená reklama, lidské zdroje pro velké společnosti, apod. Aplikací, které využívají Facebook API je dnes snad víc než jakéhokoli jiného softwaru. Jenže to se Facebooku až tolik nelíbilo. Ono by totiž mohlo dojít k tomu, že by někdo mohl získat příliš mnoho informací a vytvořit vlastní službu, která by se teoreticky mohla stát konkurencí pro služby Facebooku. A tak se Mark Zuckerberg, pod trapně výmluvnou větou: "Zlepšujeme bezpečnost", rozhodl, že přestanou poskytovat informace třetím stranám. A to do takové míry, že mnoho společností musí hledat jiný model svého podnikání či úplně skončit. Pokud se někdo domnívá, že lze dnes napsat aplikaci pro Facebook Chat, získat seznam přátel, apod, tak ho musím zklamat. Facebook veškeré toto API zrušil. V případě chatu to vyřešil tak, že ho transformoval do něčeho, co nazývají Messenger, který má vlastní ekosystém a pokud někdo chce využít Messenger, tak už nikoli jako vlastní službu, ale jako službu, která běží uvnitř Messengeru. V případě samotného Facebook API, které poskytovalo mnoho informací pro další služby, tak zde jste omezeni tak, že přestalo dávat smysl psát aplikace využívající jejich API.

Větší zlo

Hledat větší zlo mezi těmito molochy lze asi dost těžko. Nicméně, za mě je to určitě Facebook, protože v případě Googlu má člověk vždy možnost své aplikace dále provozovat či přepsat. V případě Facebooku máte prostě jednoduše smůlu. Facebook má jistě mnohem větší ambice pohltit internet a způsob, kterým se pustili do boje o prvenství je dost barbarské. Pokud chceš využívat Facebook, tak pouze uvnitř jejich světa, nikoli jinde. Doufám, že díky tomuto kroku se dostanou do stavu, kdy vznikne trend opustit tento ostrov a přejít zpět na propojený kontinent. Pokud se ovšem dřív neobjeví nová štika v řece....

Magické slovo REST

V posledních letech jsem se několikrát setkal s tím, že lidé použili toto magické slovo téměř všude, kde se jim to zrovna hodilo. Jenže kolik z nich vlastně ví, co samotný REST znamená a v čem jsou jeho výhody a nevýhody oproti SOAPu?

V první řadě je třeba zmínit, že díky míchání pojmů je dnes dost matoucí se bavit jedním dechem o webových službách, RESTu, SOAPu či WSDL. Takže, jak to vlastně je:

Webová služba je obecný název pro systém na interakci mezi dvěma stroji po síti. Pokud někdo mluví o webové službě, tak tím vůbec nespecifikuje, zda se jedná o SOAP či REST.

SOAP je protokol na výměnu dat pomocí XML. Nejčastější využití je přes HTTP protokol.

WSDL popisuje samotný SOAP. Tedy určuje jak vypadá daná webová SOAP služba.

REST/REST API je architektonický styl, který má jasná pravidla. Nejčastější použití je přes HTTP protokol a jako výměnný formát používá XML, JSON či vlastní formát.

RESTful je označení aplikací, které využívají REST API.

Když jsem se poprvé setkal s pojmem REST, tak jsem nechápal jaké jsou jeho výhody oproti klasickému SOAPu. Díky tomu, že jsem k návrhu aplikací přes REST API přistoupil již před mnoha lety, tak ono zjišťování mám dávno za sebou.

Jak už jsem zmínil, REST je architektonický styl, tedy předem určuje jakou architekturu bude mít mé API. Osobně toto považuji za jeden z největších přínosů tohoto návrhu. Stejně jako v objektově orientovaném programování se používá pojem zapouzdření a programování vůči rozhraní, tak i zde jsem dopředu omezován. Ano správně! Omezován. A to je právě ona výhoda. Není totiž nic horšího, než se prohrabovat cizím API a zjišťovat jakým způsobem autor navrhl klientské volání onoho API.

Uvedu příklad:

Představte si, že máte program, který poskytuje službu pro práci se zaměstnancem. Aplikace je sofistikovaná a nabízí takové věci jako je tvorba nového zaměstnance, editace či mazání. Pokud takovou službu budu volat, tak budu nejspíše hledat názvy jako: Create, Update, Delete. Jenže, co když se autor rozhodl, že půjde jinou cestou? Najednou uvidím metody jako: AddEmployee, Save, Update, DeleteObject, DropEmployee. Asi si každý dokáže představit, co poté nastává. Prohledávání zdrojových kódů, dokumentace, volání na mobil autorovi, apod. Architektura RESTu je předem dána. Takže pokud autor zná alespoň základy dizertační práce pána jménem Roy Fielding, tak ví, jakým způsobem poskytovat jednotlivé služby.

Díky tomu, že je REST nejčastěji využíván společně s HTTP protokolem, tak využívá metody tohoto protokolu k přesně daným účelům:

• GET - získání záznamu
• POST - vytvoření nového záznamu
• PUT - aktualizace záznamu
• DELETE - odstranění záznamu

HTTP protokol obsahuje mnoho dalších metod, nicméně ty nejsou tak často využívány jako výše zmíněné. Existuje ovšem ještě jedna metoda, která je také specifikována a dost často ignorována. Osobně nevím proč, protože její využití spatřuji jako víc než důležitou.

• PATCH - aktualizace záznamu, ale pouze toho, co opravdu chci

Opět uvedu příklad:

Mám složitý objekt, který reprezentuji přes REST API. Při aktualizaci pomocí metody PUT očekávám, že přijdou všechna data a na základě identifikátoru aktualizuji jednotlivé položky. Jenže, co když nechci nutit klienta mého API, aby posílal všechny informace? K tomuto účelu se výborně hodí daná HTTP metoda PATCH.

Další důležitou vlastností RESTu je bezstavovost. Je třeba mít stále na paměti, že každé volání REST API je nový život. Mezi klientem a serverem neexistuje nic takového jako předchozí stav. Existuje spoustu důvodů, proč toto pravidlo porušit, nicméně všechny důvody mají svá řešení a proto bezstavovost API by vždy mělo být něco jako desatero:

• 1. Bezstavovost
• 2. Bezstavovost
• .....

Pokud se Vám podaří zbavit se dinosaura jako je HTTP Session, tak najednou zjistíte jak je svět RESTu úžasný. Volání čehokoli, odkudkoli, kdykoli. Klientské aplikace se zaměří pouze na to co je skutečně důležité a to zpracování Vašich zdrojů. Také škálovatelnost se stane něčím, co nebude nemožný úkol.

Poslední věcí, kterou zde dnes zmíním je verzování.

Každý autor takového API automaticky předpokládá, že jeho systém bude žít věčně a počet konzumentů jeho rozhraní bude vzrůstat. Proto hned od začátku začne počítat s verzováním.

Jak verzovat REST API je popsáno na mnoha místech a v podstatě je tímto i standardizováno. Tedy do URL adresy budu vkládat něco jako /api/v1/zdroj. Ideální varianta. Tedy alespoň na první pohled. Jenže skutečně to vždy potřebujeme? Jak se vypořádáme s verzováním na úrovni samotného kódu? Co zpětná kompatibilita? Otázek, na které nikdo předem nezná odpověď je příliš mnoho. Něco mi mohou pokrýt testy, ale buďme upřímní. Skutečně nás testy spasí od všech problémů? Tak tedy ještě jednou. Opravdu potřebujete své API verzovat? Pokud ano, je třeba mít na paměti několik důležitých pravidel:

• Verzuji vždy celé API, nikdy ne jen jeho část
• Verzování jasně specifikuji buď v URL adrese či pomocí HTTP hlavičky
• Pokud jsem konzumentem svého API pouze já, snažím se verzím spíše vyhnout
• Udržuji zpětnou kompatibilitu jen do té úrovně, do které mi to dovolují zdroje, které pro vývoj mám. Krásně by se mi mohlo totiž stát, že víc času budu trávit řešením zpětných kompatibilit, než se věnovat skutečným problémům.

K verzování se jednou vyjádřil i samotný Roy Fielding. Ve zkratce napsal něco jako: "Verzujte své API pouze pokud je to skutečně nutné. Mnoho lidí totiž zbytečně jde s kanónem na vrabce. A pokud už verzování potřebujete, tak ho fyzicky oddělte. Tedy zdroje budou mít jinou adresu. Je to něco, jako když si představíte, že jste vytvořili nový web na nové adrese."

O RESTu by se dala napsat kniha. Témat, která se kolem tohoto slova točí je skutečně mnoho. V dnešní době se z RESTu stal v podstatě standard pro tvorbu Backend API. Však také vznik věcí jako je AngularJS, ASP.NET MVC, Spring Data REST, apod tomu jen nahrávají.

Příště se pokusím zmínit o tom, co znamená HATEOAS, jak si poradit s autentifikací a autorizací či jaké jsou nevýhody RESTu.