Přejít k navigační liště

Zdroják » Různé » REST API jako rozhraní desktopové aplikace

REST API jako rozhraní desktopové aplikace

Články Různé

Jedním z požadavků zákazníků na desktopový ekonomický systém WinStrom 10 bylo otevřené API. Původním zadáním rozhraní byla možnost importovat a exportovat data a provádět další operace. V tomto článku si ukážeme důvody, které nás vedly k implementaci technologií, které využívají čistě internetové servery, jako je Twitter či Google.

Nálepky:

Při výběru technologie, která by nám měla umožnit přístup k ekonomickému systému, jsme měli několik možností. Nicméně naše požadavky byly trošku specifické. Potřebovali jsme:

  • umožnit síťový přístup k rozhraní,
  • jeho funkčnost napříč podporovanými operačními systémy (Windows, Linux a Mac OS X),
  • možnost volání z různých programovacích jazyků.

Před realizací jsme dále kladli velký důraz na jednoduchost a intuitivnost. Ideálem bylo pro nás takové rozhraní, které nepotřebuje dokumentaci.

Co používá konkurence

Před samotnou realizací jsem se porozhlédli co nabízí konkurence. V podstatě všechna studovaná řešení provádí výměnu dat vlastním formátem postaveným na XML. Ke komunikaci využívají následující rozhraní:

  • COM/DCOM/Acti­veX/OLE: technologie, které jsou velmi používané ve světě Windows. Jak už jsem ale psal, naše rozhraní musí fungovat i na Linuxu a Mac OS X a navíc má do jednoduchosti daleko (z historických důvodů). Proto jsme je rovnou zavrhli.
  • Pouštění z příkazové řádky: celkem originální postup, kdy připravíme XML a spustíme program, který si data naimportuje. Nevýhodou tohoto řešení je, že neumožňuje síťový přístup, anebo jen velmi omezeně.
  • RMI: protože je naše aplikace napsaná v Javě, zvažovali jsme také použití protokolu RMI. Nicméně toto rozhraní má jednak problémy s průchodem přes NAT (tj. zde nechodí automaticky) a za druhé je použitelné jen z programovacího jazyka Java.
  • WebServices: poměrně silný kandidát, který je dnes hojně využíván napříč programovacími jazyky a platformami. Slabou stránkou tohoto rozhraní je jednoduchost.
  • REST API: zvažujeme-li webové služby a protokol HTTP, logicky musíme dojít i k rozhraní postavené na REST API (Representational State Transfer). To je postavené na webových technologiích (HTTP) a je velmi jednoduché na používání. Pro jeho prozkoumání a také vyvolání stačí uživateli běžný webový prohlížeč. Protokol HTTP umožňuje velký rozsah funkcí. Mimo jiné nabízí autorizaci, cachování, expiraci či vysokou škálovatelnost. Více informací o REST najdete v článku REST: architektura pro webové API.

Po důkladné analýze jsme se nakonec rozhodli pro REST API.

Problémy, které jsme museli překonat

Základem REST je protokol HTTP (i když mohou být i jiné). Proto jsme potřebovali HTTP server. Obvykle se používá webový server Apache, který pak přistupuje k aplikaci (např. z PHP aplikace). Nicméně my jsme tento přístup nemohli použít, protože bychom komplikovali proces instalace a dalšího nastavení. A tak nám zbyla jen jedna možnost: desktopová aplikace musí sama o sobě podporovat HTTP server.

Pro tyto účely jsme zvolili implementaci HTTP serveru Jetty. Jetty je velmi malý a rychlý HTTP server, který startuje velmi krátce, a tudíž nezpomaluje spuštění aplikace. Měli bychom upřesnit, že naše aplikace používá architekturu klient/server/SQL server, a proto je obsluha HTTP součástí našeho serveru. Tato kombinace je používána i jako jednouživatelská instalace, a tak jsme nechtěli nijak prodloužit start a paměťové zatížení.

Jak už bylo zmíněno, jako základ komunikace jsme použili XML. Pro zjednodušení práce s rozhraním REST API z JavaScriptu jsme přidali podporu formátu JSON. V našem případě provádíme automatickou konverzi z XML na JSON, a proto je struktura obou formátů shodná. Nakonec se ukázalo, že i v jazyce PHP je snazší pracovat s formátem JSON než s XML.

Protože rozhraní podporuje více formátů, využíváme podpory protokolu HTTP pro automatickou domluvu formátu pomocí hlavičky Accept. Když chce uživatel rozhraní soubor ve formátu XML, použije hlavičku: Accept: application/xml. Narazili jsme ovšem na problém: některé prohlížeče (např. ten v mobilech s Androidem) jako první uvádějí, že chtějí XML, a přitom myslí XHTML. Proto jsme museli vytvořit filtr, který pokud najde mezi požadovanými formáty text/html, tak jej zařadí na začátek. Stejně tak pokud prohlížeč pošle jen Accept: */* (tj. přijímám všechny formáty), posíláme implicitně HTML verzi. Pokud tedy chcete XML či JSON, je nejlepší uvést do hlavičky Accept jen tento formát. Protože dnešní prohlížeče uživateli neumožňují snadno ovlivnit tuto hlavičku, museli jsme navíc přidat podporu pro domluvu formátu dle přípony. Uživatel může použít URL GET /c/moje_firma/faktura-vydana.json, získat výstup ve formátu JSON a přitom nepotřebuje další nástroje.

Struktura URL

I když už aplikace podporuje protokol HTTP, jsme stále na začátku. Nyní musíme navrhnout strukturu URL, kterou bude naše aplikace používat. My jsme potřebovali standardní CRUD (Create/Read/Up­date/Delete) strukturu:

  • Výpis objektů: GET /c/moje_firma/faktura-vydana
  • Přečtení objektu: GET /c/moje_firma/faktura-vydana/1
  • Založení objektu: PUT /c/moje_firma/faktura-vydana
  • Změna objektu: PUT /c/moje_firma/faktura-vydana/1

U výpisu objektů potřebujeme zpracovávat další případy:

  • stránkování: ?limit=10&start=10
  • informace o počtu objektů kvůli stránkování: ?add-row-count=true přidá do generovaného dokumentu informace o počtu objektů
  • řazení: ?order=nazev případně vzestupně ( ?order=nazev@A) a sestupně ( ?order=nazev@D)
  • filtrace: vytvořili jsme jednoduchý filtrační jazyk s možností and/or, závorkování a podmínek: (datSplat < now() and uzivatel = me())

Winstrom

Výstupní formáty

Kromě již zmíněných XML, JSON a HTML jsme přidali podporu pro další formáty. Prioritou pro nás byl export do formátu PDF či do e-faktury ISDOC. Následně, kvůli integraci s dalšími aplikacemi, vznikl export do e-vizitky vCard a kalendáře iCal. Díky tomu si uživatelé mohou ve svém kalendáři zobrazit splatnosti neuhrazených faktur. Protože se jedná jen o výstupní formát, lze na něj aplikovat funkce pro výpis objektů jako je filtrace či řazení.

PDF

Identifikace objektů

Každému objektu (faktuře, kontaktu atd.) je vždy systémem přidělen jednoznačný číselný identifikátor. Ten je používán jako součást URL. Abychom si zjednodušili práci, používáme jako identifikátory i další symboly:

  • vnitřní ID, přidělované ekonomickým systémem: /c/moje_firma/adresar/1
  • kód firmy: /c/moje_firma/adresar/code:FIRMA
  • DIČ firmy: /c/moje_firma/adresar/vatid:CZ28019920
  • čárový kód EAN: /c/moje_firma/adresar/ean:8594040311025

Tyto identifikátory lze použít jako součást URL i jako součást importovaného XML (např. odkaz na firmu v adresáři nebo zboží v katalogu).

Přidali jsme také podporu tzv. externích ID, které umožňuje uložit identifikátor dalšího systému přímo k objektu v ekonomickém systému. Mapování mezi systémy tak může být přímo ve WinStromu. Externí ID je ve formě: ext:FAKTURACNI1:123, kde FAKTURACNI1 je identifikátor dalšího systému.

Aby nedocházelo ke vzniku duplicitního obsahu (stejný objekt pod různými typy identifikátorů), je při použití jiného než vnitřního ID použito HTTP přesměrování (302 Permanently Moved).

Aktualizace a validace

Programátorské rozhraní musí umožňovat nejen vytvoření objektu, ale i jeho změnu, nebo jen změnu jeho části (atributu). Pokud je uveden atribut (např. název firmy), dojde k jeho přepsání. Pokud není, ke změně nedojde a zůstane nastavena původní hodnota. Pokud chceme hodnotu vynulovat, uvedeme prázdný atribut.

To samé jsme aplikovali i na podobjekty (např. položky faktury). Podobjekty lze měnit, přidávat a mazat.

Neméně důležitou kapitolou je validace. Když přes rozhraní odešleme data do systému, chceme získat seznam validačních chyb nebo varování. Protože se některé položky umí automaticky vypočítat, může uživatel rozhraní chtít odeslat data na server, nechat zvalidovat a přijmout zpátky přepočtená. Pro tyto účely slouží testovací režim. Ten se zapíná parametrem ?dry-run=true. V takovém případě se data neukládají, ale jsou vrácena v takovém stavu, v jakém by byla uložena.

Zvyklosti v REST API

Při vývoji rozhraní jsme zkoušeli komunikovat s aplikacemi psanými v různých frameworcích a jazycích. Při těchto pokusech jsem naráželi na to, že REST je architektonický styl a nedefinuje žádný typy použití, jako je stránkování či filtrace. Z těchto důvodů každý nástroj očekává jiné parametry či data v jiném formátu.

Ukázkou může být typický požadavek z naší aplikace:

GET /c/moje_firma/faktura-vydana/(dic='CZ123456')
<winstrom version="1.0">
    <faktura-vydana>
        <id>1</id>
    </faktura-vydana>
</winstrom>

A v Ruby On Rails:

GET /c/moje_firma/faktury-vydane?dic=CZ123456
<faktury-vydane>
    <faktura-vydana>
        <id>1</id>
    </faktura-vydana>
</faktury-vydane>

Na předchozím příkladu je vidět, že ta samá věc může mít různé reprezentace. Problém jsme vyřešili tak, že se vždy snažíme podporovat více variant (např. různé URL, různé způsoby řazení, …). V těch případech, kdy to nejde, umožňujeme přepnutí režimu pomocí  ?mode=ruby.

Automatická dokumentace

Jedním z požadavků, které jsem na začátku uvedl, byla i jednoduchost použití pro vývojáře. Snažili jsme se vše vytvořit tak, aby základní vývojářská dokumentace byla vždy součástí produktu. Proto do všech generovaných XML dokumentů automaticky doplňujeme i komentáře o názvu položky, jejím typu, délce a seznamu povolených hodnot. Abychom generované dokumenty zbytečně nenafukovali, doplňujeme tuto informaci jen u prvního objektu. Pokud uživatel rozhraní dostane vygenerovaný XML, ihned vidí, co která položka znamená.

V jednoduchosti použití rozhraní jsme zašli ještě dále, a tak jsme do aplikace přidali možnost přepnout si stránky do vývojářského režimu. Díky tomu místo výpisu faktur dostaneme informaci o tom, co daná stránka zobrazuje, jaké je zapnuté stránkování a zda případně jaký je aplikován filtr. Je také možné si přepnout na seznam položek, kde je o každé položce zobrazeno mnohem více informací. Tyto informace je opět možné zobrazit ve formátu HTML, XML a JSON.

Budoucnost

Už jsme se zmínili o možnosti exportovat data do formátu iCal. Možností, které toto rozhraní přináší, je ovšem mnohem více. Mohli bychom si na iGoogle zobrazovat prodeje za poslední měsíc, v mapách zobrazovat prodeje pro jednotlivé oblasti a nebo jen seznam zákazníků v okolí nějakého místa kam se právě chystáme.

Všechny tyto možnosti nyní ale naráží na velký problém. Tím je autorizace přístupu. Standardně je používána HTTP autorizace (tedy jméno a heslo). Nicméně pokud bych chtěl Google kalendáři umožnit přístup k mým datům, narazím na problémy. I kdyby Google uměl přistupovat k zabezpečeným datům, otázka zní, zda bychom mu to vůbec chtěli umožnit. Kvůli takovéto drobnosti bychom mu vlastně umožnili kompletní přístup k celému systému (používal by náš účet). Když nad tímto problémem zapřemýšlíte, hned vás napadne: ale tohle už jsem přeci řešil u Facebooku a Twitteru. Zde také jednotlivým aplikacím povoluji přístup k datům a přitom jim nemusím předávat jméno a heslo. Proto bychom chtěli implementovat zabezpečení pomocí OAuth.

Do budoucna se chystáme dále rozšířit možnosti rozhraní a podpořit vývojáře, kteří jej budou používat. Chceme vytvořit ukázkové aplikace, které budou demonstrovat možnosti.

Komentáře

Subscribe
Upozornit na
guest
74 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jens.cz

Neměl byt tento článek být uveden jako „Komerční sdělení“, když to to víceméně reklama na komerční software WinStorm? Popis REST API lze určitě udělat i jinak …

Martin Malý

Toto není popis REST API, popis je odkázán v článku.

asi to jinak nejde

Ono to asi nejde popisovat neco bez prikladu. Takhle to neni od teoretika, ale z praxe.

A dnes se to nosi se predvadet. Napr. clanky pana Kravala o OOP a OOA na me posledni dobou delaji dojem, ze puvodne klasik pise clanky proto, aby v nich trikrat upozornil na sva skoleni, mimochodem dobra.

---

Tohle je opravdu reklama. Melo by to byt oznaceno jako PR clanek.

Zorg

Podobné výkřiky mě nepřestávají udivovat. Je reklama/není reklama má jediné kritérium – jestli si vydání článku někdo zaplatil. Zbytek je čistě na posouzení redakce, která v tomhle případě zvolila podstatně zajímavější alternativu z reálného světa místo příkladů typu „přidáváme REST k našemu blogísku“.

Martin Malý

Dodám: Nejen zajímavější, ale i poměrně unikátní.

q

neni. Patrick Zandl na lupe rekl ze neni .. tak neni :) Ja si taky myslim ze je, ale nemame sanci to prosadit. Kdyz se zeptam Zandla na to jak se taky takto muzeme jako firma nenapadne prezentovat s nasi znackou, dostanu komercni nabidku produktu iinfo. Tak asi tak :) Je mi z toho na bliti a davam projektum iinfa velke minus. abclinuxu mi prijde fakt zajimavejsi.

Martin Malý

Děkuji za nabídku. Váš článek o tom, jak jste ve svém komerčním produktu použili nějakou podobnou techniku (třeba OpenID, OAuth, nerelační databázi nebo webové rozhraní) spolu s popisem zvažovaných alternativ, rozhodování a implementace, by byl jistě zajímavý. Pošlete ho, prosím, na mail redakce@zdrojak.cz Děkuji.
Tak asi tak.

Prezdivky nikdy nebyly

No pokud bych ho psal podobnou formou, asi by se vam zde v diskuzi objevovaly podobne prispevky o tom ze to nekteri citi jako PR (nejsem sam). Kdybych na to mel vice casu a nebo ten cas zaplacen, proc ne. Nikde ale neni jistota, ze to zverejnite a ze muj cas nevyjde v nivec. Navic uz publikuji jinde.

Martin Malý

V tom případě mi není jasné, na co si stěžujete…

Přezdívka dvojtečka

Já na nic. Mě je to jedno. Já reagoval na to, že je to neoznačené PR a že u takových článků dostane většinou autor komerční nabídku iinfa za zveřejnění takového PR. Vy jste mi pak řekl ať tedy sám něco napíšu a já ale nepíšu protože píšu jinde a nemám na root čas.. No to ještě neznamená, že si nemůžu zaklet, že na lupě, na zdrojáku se propaguje komerce a není označena jako komerce… Šmarja vždyť je to jedno .. Já už si na nic nestěžuji:) Já jen řekl svůj názor a tím to končí :) Přeji pěkný den.

cgi

14:28 – 14:54 – i za takovou dobu se dá napsat celkem slušný „PR článek“ a diskutování zde také není placené… Příjemný den i Vám.

davidmach14

Díky autorovi mám řadu cenných poznatků z praxe, které v brzké době ve své firmě využiji. REST totiž zvažujeme ze stejných důvodů, které jsou uvedeny v článku. Málokterá firma dokáže psát o zajímavých věcech z vlastní kuchyně!

alblaho

Článek se mi líbil, v prvé řadě je to o technologii, teprve v druhé je to trochu reklama. No problem. díky.

Lael Ophir

Dojemná naivita :)

Martin

Tohle by se za Hassmana nestalo! Už chápu, proč jste ho odsud vykopli! Abyste mohli zanést jeho kvalitní magazín PR články, skrytou reklamou a Microsoftem. Už se těším na ten stodílný článek o .NET a super výhodách Windows Serverů!

Prezdivky nejsou

Pripadate mi trosku jako Radovan Kalu*za, akorat jste zamestnanec, mate kontakty na iinfo a pisete PR. Nevim, piste ale nezaujate a nepreferujte jeden produkt. Pak to nevyzni jako PR ale jako skutecny popis REST API. Vy jste skutecne nepochopil stejne jako redakce rozdil mezi clankem ktery preferuje jeden jediny produkt (protoze jste zamestnanec dodavatele daneho produktu, tak vas asi i chapu, mozna mate neco ve smlouve jak mate jednat navenek) a ktery nezaujate popisuje rozhrani. Mejte se hezky :) Doufam ze nenapisete i na abicko.. to uz by bylo trosku moc.. Zamoreni internetu winstormem.

PS: hehehe .. :) Ka*luza je na rootu zakazane slovo:) Nejde s tim odeslat prispevek :))))))) lol hehe .. skaceme do Kaluze a cakame vodu .. :) to uz jde .. dobry :)))

Přezdívka nikdy povinná nebude.... :)

tak preci jen je to PRko :))) Nebo ze by jste byl skutecne tak žádaný, všechny redakce se ptali jen vas a žádaly vás o článek a neexistovalo v ČR cokoliv jiného než winstorm ? :)) Tomu nevěřím :) Ale dobrá tedy :)

Tomáš

Martine, tak tuhle Vaši reakci nechápu. S největší pravděpodobností nepotřebujete kvalitní účetní program pro Linux, protože tím WinStrom opravdu je. A že je zároveň i pro majoritní OS je pochopitelná vlastnost, bez které by vůbec nebyl. Prodej linuxových verzí by firmu jistě neuživil.
Za tuhle snahu jsem jim pořád vděčný, protože bez nich bych nemohl s čistým svědomím provozovat svoji živnost (virtualizace nebo Wine sice taky fungují, ale jsou to pořád jenom „berličky“).

Martin Malý

Je vidět, že komunita Strážců Tradičních Hodnot nespí! Jen škoda, že se místo komentáře se spikleneckou teorií nezmůže na celý článek o něčem zajímavém ze světa OpenSource…

Přezdívky na rootu

nezlobte se, jeste jeden koment.. winstorm je OpenSource? Muzu se nekde prosim podivat do zdroje? Diky…

Martin Malý

Není to opensource. Na Zdrojáku si na „hodný opensource“ a „zlou komerci“ nehrajeme. Až nějaký vývojář opensource programů napíše podobný článek, zveřejníme ho naprosto stejně.

Prezdivky jednoduse povinne nejsou

No a ted mi uprime reknete, kdyz uz jste psal o OpenSource, nebylo by lepsi sva ucetni data sverit skutecne OpenSource aplikaci? No vidite .. a winstorm neni opensource ale komerce. Pak tedy „…celý článek o něčem zajímavém ze světa ClosedSource“ :) a ja myslel ze jsem na zdrojak.cz :)) Tady bych fakt opensource cekal.

Pravděpodobně neumíte pořádně číst, psal jsem o tom, že se dotyčný komentátor rozohňoval proti Microsoftu, a dodal jsem, že je „jen škoda, že se místo komentáře se spikleneckou teorií nezmůže na celý článek o něčem zajímavém ze světa OpenSource…“ (když už mu tak vadí closed source). Je vám to už jasnější?

Ano, jsme na Zdrojáku. Zdroják je magazín o (převážně webovém) programování a technikách spojených s webem. Takže sem patří jak ASP.NET či Flex, tak třeba Django. Promiňte, ale dělení světa na „opensource“ a „komerci“ je mi cizí, a na Zdroják nepatří.

Prezdivka je blbost

Samozrejme, ze neumim cist, jsem analfabet a je mi to uz jasne jak sklo :)

Tomas

Hranice PR versus odborný článek je subjektivní. Tento článek u mě padá do kategorie odborných článků. Podle mého vnímání PR články většinou vychvalují produkt bez jakéhokoliv srovnání či konkrétních faktů. Tento článek je na rozdíl od PR nabitý konkrétními informacemi a navíc z praxe. Článek dokonce hovoří i o možných problémech. Informaci o vlastních problémech v PR článku rozhodně nenajdete.

To že se mluví o komerčním produktu přece nedělá z článku PR. Např. Qt lib můžete mít pod komerční licencí, a automaticky to neznamená že se články o Qt jsou PR.

Martine, smiřte se s tím, že komerční produkty tu jsou a budou a ne všichni chtějí komerční produkty ignorovat. Myslím, že by bylo hodně škoda, kdyby nebyly takové články na zdrojáku zveřejňovány.

+1 autorovi – článek je velmi inspirativní, díky

Martin Malý

Použití REST API u desktopové aplikace je poměrně unikátní, natož u aplikace tohoto typu. Takže téma mi připadalo velmi dobré, stejně tak jako vysvětlení procesu vybírání vhodného typu rozhraní a popis implementace. Můj požadavek na autora byl jasný: „Nechci, aby to byla reklama na produkt!“ Jméno produktu jsem nakonec připustil, ostatně zaznělo i ve zprávičce, která vyšla zde i na Rootu (a na dalších serverech), ale v jiných ohledech jde především o článek, který popisuje proces výběru architektury, sumarizuje výhody jednotlivých řešení a ukazuje, že REST nemusí být jen „čistě webová“ záležitost. Což je pro mne důležitější než to, že v něm zaznělo jméno komerčního produktu.

A to, že v článku někteří lehkoocí čtenáři uvidí primárně PR nebo reklamu, mi připadá jako přiměřená daň za to, že článek popisuje celkem pěkně implementaci REST do desktopového SW.

Ped

Zajimave ze kdyz se tady objevi spravicka o novem Firefoxu, wine nebo archlinuxu a gentoo, tak tam vykriky ze jde o PR neni videt… :D
A to nemluvim o tom ze jejich informacni hodnota je casto nizsi nez u tohto clanku.

jan.letko

Presne, popis novych vlastnosti Firefoxu nie je PR ??? Asi nie, lebo ho nepisal nikto zainteresovany (napr. z Mozilla Foundation), ale toto uz PR je, pokial je to z dielne priamo zainteresovaneho cloveka. Ale tato forma PR mi nevadi, pokial ma informacnu hodnotu.

Hranica kde zacina PR a kde konci je tenka.

Dakujem za clanok, podla mna to nie je PR a clanok ma informacnu hodnotu.

Jens.cz

WinStrom je vyhradne komerecni software s uzavrenym zdrojovym kodem vyvijeny jednou konkretni firmou za ucelem zisku.

Firefox je vyhradne nekomerecni software s otevrenym zdrojovym kodem vyvijeny vyhradne k distribuci zdarma pod svobodnou licenci za spolucasti prispevatelu z komerecni i nekomerecni oblasti.

Opravdu nevidite ten rozdil?

Nemam nic proti tomu, ze nekdo vyvyji software za ucelem zisku, sam delam to same a v tom rozhodne problem nemam. Informacni hodnota clanku muze byt klidne excelentni, ale stale je to jen reklama pana „vedouci vyvojare“ a „jeho produktu“. O tom lze jen tezko polemizovat. Redakce ROOTu si zaslouzi odmenu nebo alespon minimalne nekolik licenci na WinStrom zdarma :)

Martin Malý

A vy v tom nějaký rozdíl vidíte? Vy se domníváte, že článek od vývojáře komerční aplikace je PR a reklama, zatímco článek na totéž téma od vývojáře aplikace nekomerční bude regulerní a v pořádku? Pokud ano, tak není o čem diskutovat…

jan.letko

Vidim ten rozdiel, takto som sa na to nepozeral, nakolko sme v sekcii ZDROJAK a tu sa divam na technologie (programovanie), nie na komercny produkt vs. nekomercny produkt.

Martin Malý

Přesně tak. Článek je v podstatě případová studie, v níž autor ukazuje, jak postupovali při implementaci otevřeného API, jaké možnosti zvažovali, proč vybrali „webový“ REST pro víceméně desktopovou aplikaci, jaké problémy a jaké výhody to přineslo a jak tuto architekturu API implementovali. To bylo rozhodující při zvažování, zda článek vydat nebo nevydat, nikoli to, jestli ho psal vývojář komerčního SW.

Ped

Redakce ROOTu ma presne takovou odmenu jakou si vyjedna, t.j. je to jejich problem.
A podle mne je soudite prilis jednostranne, ROOT nemusi jen hledat financni prostredky na provoz serveru, taky musi i zabezpecit dostatek hodnotnych clanku pro sve ctenare, aby se z nej nestal archiv starych clanku.
Nemyslim ze by seriozni a relevantni informace pro vyvojare museli nutne oznacovat jako placene PR a zadat po autorech platbu – jen proto ze autorem informaci je nekdo kdo pracuje na komercnim produktu a mimo jine si dela danym clankem reklamu. Bylo by na povazenou kdyby se ted na rootu zacali zdarma objevovat spravicky o kazdem updatu Winstrom ktere pro vyvojare skoro zadnou hodnotu nemaji, ale porad je to vec redakce, snad umi pocitat a vi co je pro ne dobre.

Mimochodem, myslite ze Mozilla Foundation nema zadne prijmy a zije jen z daru? Myslite ze PR Firefoxu vznika spontanne bokem o pauzach mezi kodovanim a delaji ho samotni vyvojari Firefoxu? Myslite ze M.F. do PR Firefoxu neinvestuje sve zdroje (lidi, technologie, penize)? Tak zijete v jinem svete.

Martin Malý

WinStrom jako ekonomický SW je zcela mimo zaměření Roota i Zdrojáku, takže zprávičky o jejich nových verzích se zde skutečně objevovat nebudou. Tento článek zde vyšel proto, že popisuje použití techniky, která na Root i Zdroják patří (REST), navíc poměrně neobvyklým způsobem (v primárně desktopové aplikaci), a velmi pěkně ilustroval, že použití takové techniky není v „uzavřeném SW“ nejen nemožné, ale někdy i výhodné (a navíc i vysvětlil důvody, proč vybrali právě REST). Howgh.

A pokřik o PR a komerci byl očekávatelný, někteří lidé holt vidí svět takto fundamentalisticky.

Jaro

Ja som zasa komerčný programátor v Jave a pre mňa mal tento článok prínos. Je mi prd jedno, koľko „reklamovosti“ v ňom bolo, rozhodne je užitočnejší ako článok typu: a teraz si spravíme fórum v PHP. Privítal by som viac takýchto užitočnejších článkov z praxe.

Ivan Nový

Firefox je komerční produkt, protože usiluje o podíl na trhu, konkuruje komerčním produktům. To, že je zadarmo nerozhoduje. IE je taky zadarmo. Něco jako nekomerční produkt neexistuje. Vývojáři OpenSource jsou placeni za tento vývoj renomé, které tímto získají. Vývoj OpenSource je PR vývojáře.

Michal Augustýn

Pěkný článek. Oceňuji, že autor prozradil něco málo z kuchyně, kde se vaří komerční produkt.

Po přeečtení úvodních odstavců mě napadá, že by se mi líbil článek, který stručně představil a porovnal různé způsoby (chcete-li protokoly) komunikace mezi aplikacemi – web-services, rmi, http rest, MS Dynamic Data, … Dnes je toho hodně, různě se to překrývá, něco je podmnožinou něčeho jiného…takže nějaký článek, který by vnesl řád do tohoto chaosu, hm? :)

uf

A jak ma asi clovek zobecnit svuj problem na Hello World ?

Ja se take chystam pouzit RESTove rozhrani z desktopu na aplikacni server. Myslim, ze k tomu svet speje – mam jedno rozhrani a je jedno, cim tam lezu.

Diky hosi, jeste si to prectu.

karmi

Díky za reálnou case-study z nasazení REST API, jsem rád, že ne všichni se u nás bojí jít s kůží na trh a psát o tom, jak co udělali a proč.

Líbí se mi, jak vystavujete množství URL na jeden resource (včetně 302 přsměrování), moc se mi líbí trik s dry-run a samozřejmě zmínka o OAuth jako řešení problémů s autorizací přístupu k API od třetích stran. Vypadá to, že vaše API je jedno z mála, které jsou _skutečně_ RESTful a ne jen „pošleme si nějaké XML přes HTTP“ (jako to typicky dělá např. Flickr).

Mám jeden dotaz: v článku zmiňujete, v jaké struktuře resource publikují Ruby On Rails – jak využíváte Ruby nebo Rails?

karmi

Diky, tou „podporou“ pro Ruby On Rails myslíte kompatibilitu s ActiveResource?

backup

jak uz to v zivote chodi, vznikne nejaky obor a soucasne s tim se nekdo ukecne a rekne, ze to je budoucnost. A neuplyne ani 20 let a mame zde fakulty informatiky, ktere musi mit napln. Tak zacnou introventi vymyslet integalakticke blbosti a prohlasovat je za standard a budoucnost. Primicha se k tomu nekolik desitek zkratek a je vystarano – pisou se o tom clanky, produkuji bakalarske prace, pronasi se prednasky na konferencich a pod. A na konci se toho chytne firma, ktera dela ucetnictvi a implementuje to – a pritom chtel uzivatel jen vedet, kolik ma urcity zakaznik na pohledavkach.

Vseobecne rozhrani je nesmysl, v zadnem jinem oboru se neco takoveho nedeje. Informatika si mysli, ze pro ni to neplati, nebot operuje nad nehmotnymi objekty, ale to je velky omyl.

uf

Myslenky zajimave a tak to opravdu chodi. Jeste jste zapomnel, ze nazvy technologii a zkratky jsou vetsinou OBCHODNI kec – podporujeme BFLM, Astru, Jizni Angolu atd. Kdo to nenapise, tak nic neumi. Stejne se nakonec ukaze, ze se toho jen dotkli a chce to jen par zakazniku (napada me treba Java v SQL serveru, i kdyz bych pro ni mel take pouziti).

Na druhou stranu ITaci (myslim lidi, co to delaj, ne co to ridej) se snazi vzdy vymyslet neco lepsiho, sikovnejsiho, elegantnejsiho, uspornejsiho… Hej?

Kvík

Na tom je hodně pravdy

Petr

Děkuji za zajímavý článek.
Zajímá mě, zda používáte pro RESTful rozhraní nějakou knihovnu a v případě že ano, tak jakou. Já mám dobré zkušenosti s knihovnou Jersey.
Dále jsem si v článku všiml plánu na využití OAuth. Této technologii moc nerozumím, ale mám z ní pocit že se jedná spíše o autorizační službu vhodnou pro integraci různých aplikací a její přínos pro Váš produkt si neumím představit.
Jakým způsobem máte nyní řešenou autorizaci? Řešil jsem podobný problém. Implementoval jsem POST metodu pro kontext /login která vrací v cookie session id. To předávám při následných REST voláních. Takže moje aplikace není čistě „stateless“. Jsou i jiné možnosti?

karmi

To, že nějak autorizujete klienta pomocí tokenu, neznamená, že nejste „stateless“. „Stateless“ znamená, že se na serveru neudržuje „state“ / „stav“ resource – např. v server side session –, typicky například „obsah košíku“.

Pro mnoho případů lze využít i „normální“ a „dřevěnou“ HTTP-Auth + SSL (jak to dělá třeba výše zmíněný ActiveResource). Nebo zmíněný OAuth etc.

karmi

Pardon, zapomněl jsem vložit odkaz: http://www.infoq.com/…introduction#…

Petr

Mě knihovna Jersey naopak nadchla. Zkoumal jsem verzi 1.1EA.
https://jersey.dev.java.net/…r-guide.html
Líbí se mi hlavně „routování“ entit a metod, parsrování parametrů ale především automatické transformace mezi JSON (případně XML) strukturami a Java objekty.
Nemám ale žádné zkušenosti z komerčního projektu. Kdyby to bylo na mě, tak tuto knihovnu vyberu. Přijde mi, že vlastně ani nijaké další alternativy nejsou. Framework Spring 3.0 slibuje REST podporu. Springy neumí automatické transformace mezi JSON(XML) notací a Java objekty. Také se mi nelíbí, že když chci využít podporu pro REST ze Springu, musím používat celý framework.

skrat

pekny clanok, ale ta cestina v XML ma dostala. stavim sa ze aj zdrojaky mate v cestine. mne to pride velmi odpudive a kontraproduktivne pouzivat iny jazyk nez EN v zdrojovych suboroch a musim sa priznat, lokalizovane XML vidim prvy krat. pride mi to ako hulanizmus

Jirka Hradil

Petře, hezký článek, díky za něj.

2 kecy o reklamním článku: nepřestávájí mě udivovat sdělení nějakých s.áčů, zda to je/není reklama. Vývoj podobného systému stojí hafo peněz a autor má můj respekt, že se podělil s komunitou. Vy to neplatíte, ale lízáte smetanu, tak kde je problém? :)

uf

Opravdu pekny clanek a pro me prinosny i pro budouci planovani.

Hlavne uz prestante odpovidat na nervozy. Ja jsem na PR vysazeny dost silne, ale tady mi to prislo normalni. A pak, tu trochu reklamy si za namahu vse usporadat a sepsat zaslouzi.

Dnes ze sebe lidi delaji klasika nebo umelce jen proto, ze se snadno publikuje. Zacinaji se mnozit clanky, ktere jsou vytahem manualu, tutorialu nebo knihy. Ale uvedomte si, ze i to da praci. Sam mam pripravenou serii tutorialu v sufliku (teda flashiku), ale budu to muset predelat, protoze uz jsem zase o krok dal. A dalo to fakt praci a cas.

uf

Jeste me zaujala zminka o cestine ve zdrojacich. Pokud nejsem OpenSource, mezinarodni firma nebo nepredpokladam, ze se v tom bude hrabat cizinec, nechapu, proc by nemohly byt metody a promenne cesky (teda bez interpunkce, jsem ze stare skoly). A co KOMENTARE ?

Mozna, ze nekomu dela potize psat cesky, jak jsem si tady vsiml (tim nemyslim autora dotazu o cestine).

uf

Nez to nekdo pripise: Ja totiz neumim komentare z problemove domeny prelozit do anglictiny.

Karel

Vaše připomínka je založena na tom, že „pokud vím, že“. U komerčního SW je takové rozhodnutí velmi překvapivé, protože ukazuje, co si vedení firmy myslí o tom, kde jejich SW bude za pár let.

Ped

„Pokud nejsem OpenSource, mezinarodni firma nebo nepredpokladam, ze se v tom bude hrabat cizinec“

U SW tohle nefunguje. Bud pracujete na kvalitnim SW, ktery nakonec skonci pod kridly mezinarodni firmy nebo na nem bude pracovat i cizinec, nebo delate na necem co bude za par let mrtve. Taky nektere firmy v ramci agonie (nebo zmeny strategie) pusti svuj SW jako open source.

Pro priklady ze zivota neni potreba chodit moc daleko, treba „602“ a NetBeans.
Asi nejzajimavejsi prikladem by bylo najit ceske zdrojaky ktere jsou ted uspesnym open source nebo je vlastni a aktivne vyviji zahranicni firma. A nebo vydrzeli vic nez 10 let ve stavu jaky popisujete, t.j. cestina jim neublizila. Mozna neco takoveho existuje, ale myslim ze Cestina vyvoju SW nakonec z obchodniho hlediska ve velke vetsine pripadu znacne uskodi, hlavne v horizontu 5–20 let a je to IMO spatne obchodni rozhodnuti. Ani v komentari.

Cestina pri popisu dat je myslim trochu jiny pripad, tam bych nesoudil az tak prikre a zbrkle. Kdyz jsou data dokonce primo vazane na ceske zneni zakonu, tak to ma zjevne vyhody. Presto nevyhody popsane vyse u samotnych zdrojaku zustavaji, takze to bude pokazde slozita volba.

paranoiq

děkuji autorovi za článek a martinovi malému za jeho zveřejnění. článek je o to cennější, že se zabývá skutečným problémem a ne, jak už někdo napsal výše, „implementací REST do vašeho blogísku“

těm co v diskuzi hýkají na téma PR bych rád vzkázal, ať se zamyslí nad tím jaký je průnik cílové skupiny PR článků o účetním softwaru a cílové skupiny zdrojáku :]

uf

Dodneska nechapu, jak se u RESTful (tedy u bezestavove) komunikace resi to, ze jsem jako uzivatel prihlaseny. Snad jen pokazde jinym hashem se specialni kontrolou? Uf

uf

Snad jen vytvorit pro kazdy odkaz hash, ktery bude platny rekneme hodinu.

Jan Pejša

zajímala by mne podrobněji HTTP autorizace a jak řešíte obecný bezpečnostní problém CSRF?

xurfa

A proč rovnou nepoužívat protokol postavený na WebDAV? Což je de-facto „REST“ + možnost vylistovat seznam objektů + možnost číst/nastavovat atributy objektů (PROPFIND/PROPSET). A když by to bylo málo, dá se udělat „REPORT“ šitý na míru; případně se dají použít další věci jako je zamykání, verzování, atd, atd.

Viz třeba jak vypadá GroupDAV a podobné protokoly…

pk

ze by to proste znamenalo pro tvurce aplikace vice prace bez meritelneho prinosu pro platici uzivatele? ;)

michalekz

Nedá mi to nepřipojit krátkou poznámku k této podnětné diskuzi.

Až se pan Zandl a spol. rozhodne na nátlak čtenářů podobné články neotiskovat, velice rádi jejich autory vezmeme pod svá křídla a rádi založíme – vedle Světa hardware, TV Freaku a spol. – nový magazín, který bude plný takovýchto „PR článků“. A věřím, že bude hodně čtený.

Osobně považuji tyto články – v podstatě „případové studie“ – za přínosnější oproti článkům typu „Hello World“. Proč? Neříkají jen – „možná by to takto šlo“. Ony říkají „Jde to i takto, u nás to máme vyzkoušeno“.

Co se týče PRka/reklamy s tím spojeného: opravdu si někdo myslíte, že nějakému finančnímu řediteli prodáte pár Winstromů navíc jen kvůli tomu, že Zdroják uveřejní článek o REST API použitém jako rozhraní desktopové aplikace? To snad ne..

A předem raději prohlašuji, že nikoho z Winstromu neznám a majetkovou spoluúčast neplánuji :-)

Kamil

Díky za hezký článek, málokdo se odhodlá odhalit něco z vlastní kuchyně. Chtěl bych se zeptat, jakým způsobem řešíte zabezpečení (identifikaci a autorizaci uživatele + integritu přenášených dat). Nějakým způsobem jednotlivé požadavky podepisujete?
Kamil Zm.

Uf

Taky bych se primlouval

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.