Vlákno názorů k článku Nové standardy pro JSON od Filip Jirsák - Nebylo by jednodušší vydat nový standard JML, což...

To je trochu posunuté vnímání. Přijde mi to jako kritizovat UDP za to, že nezaručuje dodání rámce, že neumí navázat spojení a že nekontroluje správnost formátu HTTP požadavku. JSON byl na samém počátku chápán jako velmi low level záležitost. JSON je právě ten "odlehčený" formát. Pokud vám přijde příliš odlehčený, tak si vytvořte svůj vlastní formát. Hlavně mu ale dejte jiné jméno, protože jinak se řítíme do situace, kdy "JSON compatible" bude ukrutný bordel. Budete nahrávat JSON soubor do staré aplikace a ona ho nepobere. Nebo vezmete starý JSON soubor a zkusíte ho dát do nové aplikace a ona vás vykope pro "neodpovídající semantiku".

Přečti si prosím komentář, na který reaguji...

- Pokud má sloužit pro přenos dat z jednoho systému do druhého, tak je textový formát nevhodný - data se dají mnohem efektivněji zakódovat binárně.
- Když je to textový formát, tak to vypadá, jako by měl být psaný člověkem - tam ale zase chybí ty komentáře a je zbytečně složitý/neohrabaný. To už jsou vhodnější INI soubory, Java properties, YAML a další (i když taky mají svoje nevýhody oproti XML).
- Vraťme se ještě k propojení dvou systémů - rozhraní systému je potřeba jasně specifikovat, jinak to všechno plave na vodě a spojení nebude fungovat. Rozumné je si vybrat formát, který mi specifikaci rozhraní umožní/usnadní - ať už některý z binárních formátů nebo třeba to XML.

Těžko říct, proč se na webu tak rozšířil - asi je to tím, že se do něj snadno serializovaly objekty z JavaScriptu a pro načtení stačilo zavolat eval(), než že by to vycházelo z vlastností toho jazyka. A pak už se šířil jako mor. Rozhodně mi to nepřijde jako racionální promyšlené rozhodnutí - spíš krátkozraké rozhodnutí (počáteční snadnost použití), omyl.

nechapem preco by format musel riesit svoju binarnost a uspornost. Od tohu su ine vrstvy, ktore to vedia zarucit. Je celkom bezne, ze na webe sa content type application/json pri prenose autmaticky gzipuje na urovni webserveru. Vysledkom je binarny stream.

Je to format, ktory ma do istej miery sluzit aj ludom - preto sa medzi developermi tesi oblube, pretoze letmy pohlad nanho im da jasnu viziu o strukture dat. Netreba na to ziaden tool.

Je lahko implementovatelny a nie je tak rigidny ako xml. Na to co bezny developer pracujuci s medziaplikacnou komunikaciou potrebuje, je JSON idealny.

Rozhodnutia robi biznis a ak tlaci na IT aby razilo cestu: hlavne rychlo a co najlacnejsie - tak sa nemozes cudovat, ze JSON je v kurze. Je doba prepajania systemov a minimalne na tej low urovni (myslene ako male a nie velmi vyznamne systemy), je JSON presne to co je potrebne.

Běžný vývojář pracující s komunikací mezi aplikacemi potřebuje vědět například to, zda odesílaný a přijímaný dokument odpovídá dohodnutému rozhraní. To s JSONem nezjistí nijak.

Proč by to neměl zjistit?

Pro JSON existuje například JSON Schema.

Ad "Rozhodnutia robi biznis a ak tlaci na IT aby razilo cestu: hlavne rychlo a co najlacnejsie"

A právě proto se v byznyse používá XML a věci jako WS/SOAP/WSDL/XSD, protože autoři jednotlivých systémů se potřebují nějak domluvit a jasně a formálně si specifikovat rozhraní, aby pak mohl každou část systému dělat jiný dodavatel a přesto to bylo kompatibilní.

Ono ani to XSD/WSDL neni uplne vsemocny, schvalne si sahnete do svedomi a vzpomente si jakou uroven validace za vas XSD dela.

Tyhle validacni nastroje casto slibuji urcitou miru bezpeci, kterou ale nejsou schopne zajistit.

BTW: traba takovy JaXB umi vygenerovat parser a objektovy model primo z XSD, ale v defaultu to nevaliduje ani pri cteni ani pri zapisu XML.

Ad "Ono ani to XSD/WSDL neni uplne vsemocny"

Všemocná a 100% blbuvzdorná není žádná technologie, ale i tak je to přínos - ušetří to podstatné množství chyb a nedorozumění, ušetří čas při implementaci - ten se pak dá věnovat byznys logice a její správnosti.

aj-tak to vacsinou v realite funguje tak, ze sa jeden system prisposobuje druhemu takze nie je ziadne autori sa dohodnu.
Navyse implementacia WS/SOAP/WSDL/XSD nie je tak jednoducha ako JSON, cize nie je ani tak lacna a teda pre biznis je to nepohodlne. Inak si neviem predstavit popularitu JSON - jedine ze by sa masovo ludia spravali iracionalne.
Osobne ak si mam vybrat data v xml alebo json, beriem json. Vacsina REST API ponuka jsontext verziu formatovanu pre cloveka. API byvaju zdokumentovane a clovek vie co moze a nemoze od toho ocakavat.
Ale kazdemu podla chuti - nikoho by som nenutil json pouzivat ak by nechcel a bolo by na vyber.

Ad „aj-tak to vacsinou v realite funguje tak, ze sa jeden system prisposobuje druhemu takze nie je ziadne autori sa dohodnu.“

Ano, jeden se obvykle přizpůsobuje druhému, protože ten je silnější/první a definuje rozhraní. Ale je rozdíl pokud se máš přizpůsobit něčemu, co je formálně a strojově čitelně specifikované a lze si z toho automaticky vygenerovat klientskou část a pak ji jen používat – a něco jiného je, když se máš přizpůsobovat metodou „pokus omyl“ něčemu, co je zdokumentované stylem: z tohoto URL si stáhněte nějaký JSON a koukněte se, co vám přišlo za data, a podle toho si to nějak naprogramujte. V lepším případě tam je dokumentace ve formě volného textu, která slovně popisuje, jaké struktury se tam dají čekat.

Ad „nie je tak jednoducha ako JSON, cize nie je ani tak lacna a teda pre biznis je to nepohodlne“

Jak se říká: nejsem tak bohatý, abych si mohl dovolit kupovat levné věci. U těch „jednoduchých“ řešení ti obvykle vzniká technologický dluh a nepěkně se ti to vrátí, nebo na to přijdeš brzy, že to jednoduše jen vypadá, ale je to šíleně pracné (zbouchat ručně nějaké klientské rozhraní, otestovat ho na všechno možné, ručně ho aktualizovat při změnách na straně poskytovatele služby…).

P.S. Co se týče rozšířenosti JSONu na webu – vidím tu dva faktory, které mu hrají do karet:
1) Velcí hráči definující API se nemusí s ničím párat, prostě vyblejí nějaké dokumenty, je celkem jedno jak, ostatní budou držet hubu a krok a nějak se podle toho zařídí, protože jim nic jiného nezbývá - jsou rádi, že nemusejí vykrádat data z nějakého nevalidního HTML a mají aspoň ten JSON, i když je nezdokumentovaný.
2) Na webu se dělá spousta krátkozrakých rozhodnutím a obecně se pracuje stylem: rychle to nějak zbastlit, vyfakturovat zákazníkovi a hurá na nový projekt. Weby se málokdy inovují, prostě se starý web zahodí a napíše se to úplně celé znova. U serióznějších podnikových aplikací je ten životní cyklus mnohem dělší, jádro se udržuje klidně deset a více let, pořád se to rozvíjí místo aby se neustále zahazovalo a psalo znova – zahodí se maximálně zastaralé UI nebo se sem tam přepíše nějaká ta komponenta.

Hlavní výhodou JSONu, jak už bylo řečeno, je jednoduchost.

chybí infrastruktura kolem, jako má XML (validace, transformace, dotazovací jazyk...)

Vytvářet speciální jazyky jako XSLT nebo XQuery je IMO špatný nápad. Lepší je obohatit stávající programovací jazyky o jejich schopnosti.

Takže DSL jsou nesmysl? To snad ne.

Co se týče obohacování existujících jazyků - tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší. IMHO je vhodnější mít víc specializovaných jazyků a vždy vědět, v jakém kontextu se pohybuji (např. teď píši deklarativní dotaz vs. teď píši proceduru).

Takže DSL jsou nesmysl?

Když bych mohl totéž napsat v jazyce, v němž programuji celou aplikaci a bylo to kratší, jednodušší a běželo to rychleji, tak je DSL nesmysl.

tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší.

Musí se to udělat rozumně. Ten jazyk by mohl být jednodušší než Java 8.

Dalsi moznosti je pouzit jazyk, ktery ma tak volnou syntaxi, ze dokaze JSON primo zchroupat :) (napr. Lisp anebo Perl) - Ok to dost prehnal, ale pravda je, ze jednoduchost JSON ocenite, kdyz pouzijete nejaky funkcionalni programovaci jazyk.

Ve staticky typovane imperativni Jave je vam JSON k nicemu. Javista spis oceni ze mu JAXB vygeneruje objektovy model primo z XSD.

Ano, v dynamických jazycích se dá takhle hezky "prasit", ale to nemá nic společného s použitým formátem dat -- např. v PHP lze díky SimpleXML tímto způsobem pracovat s XML daty. (jestli je tento způsob práce vhodný nebo ne, to je zase na jinou debatu)

> Co se týče obohacování existujících jazyků - tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší.

Skvělý popis, proč lidi tak rychle zavrhli XML a začali používat JSON.

Jeden odmítá speciální jazyky typu XQuery, XPath, XSLT a radši by to nacpal do jednoho obecného jazyka, který bude umět všechno; druhý zase odmítá XML, protože toho umí moc. Je zajímavé, jak si každý najde nějaký důvod, proč nenávidět XML :-) XML sice nabízí hodně možností, ale dává to dohromady smysl a většinu z toho používám a považuji za užitečné. JSON je tak "jednoduchý" že nenabízí vlastně nic, ani komentáře, ale zase tak složitý, že musím psát názvy klíčů do uvozovek a otravovat se s čárkami, středníky, závorkami... JSON mi přijde jako kombinace těch horších vlastností různých formátů. I takové INI soubory (resp. některá jejich specifikace/odrůda) jsou asi lepší. Nebo mnohé jiné formáty (YAML atd.).

Jeden odmítá speciální jazyky typu XQuery, XPath, XSLT a radši by to nacpal do jednoho obecného jazyka, který bude umět všechno

Jednak, jak už jsem naznačil výše, to nutně neznamená, že by ten jazyk musel být složitý.

A navíc není lepší nevymýšlet kolo™ a použít hotovou technologii (rozuměj existující programovací jazyky)?

ale zase tak složitý, že musím psát názvy klíčů do uvozovek a otravovat se s čárkami, středníky, závorkami

Tímto je naopak jednoduchý - specifikace i implementace.

je zajímavé, jak si každý najde nějaký důvod, proč nenávidět XML

Rozlišuji XML a specializovaný programovací jazyk pro práci s XML.

> Je zajímavé, jak si každý najde nějaký důvod, proč nenávidět XML :-)

mě teda příde ještě víc zajímavý, že se pod článkem o JSON tohle řeší

hateři xml tenhle flame IMHO nezačli

trochu ti to porovnání upravim:

Řeší se to tu ze stejného důvodu, jako by se existence raketoplánu řešila pod článkem o hobby úpravách škody 120.

tam by ovšem škodovkáři asi hned řekli: strčte si raketolán do prdele, tady se řeší škodovky

Aha, takže raketoplán se běžně používá pro přepravu osob z jednoho města do druhého? A běžně si ho pořizují i normální lidé a malé firmy?

používá snad někdo čtverce s kulatejma rohama jako alternativu ke kolu?

JSON hateři se tu snaží vnutit ostatním, že mají k dispozici XML, tak ať ho koukají používat

na to se dá říct jen: NASRAT, je to moje volba, když chce někdo řešit něco kolem JSONu, tak ať to řeší, co je komu kurva do toho?

na další tvoje levný lží nehodlam reagovat, vim co si zač, nazdar