koko json menee minulta c koodarilta yli. enkoodataan data johonkin tilaa vievään json-merkkijonoformaattiin ja vastaanottaja dekoodaa sen? sen sijaan että siirrettäisiin data suoraan raakamuodossa. tuohan syö ihan sikana aikaa ja resursseja! esim electronissa kaikki data siirtyy jsonina. turhaa varmaan ihmetellä miksi työpöytäsovellukset nykyään raskaita!!
jsonin overhead
Anonyymi
7208
0Äänestä
Muut lukivat myös
Ketjusta on poistettu 1 sääntöjenvastainen viesti.
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 7
Vanhimmat
Json on erinomaisuutta. Joku XML on siihen nähden yhtä helvettiä. Eli Json on erinomainen tapa välittää ja tallentaa tietoa, koska se on sellaisenaan luettavissa.
Esimerkiksi JavaScriptin objektiksi muunnos käy helposti
json = '{"nimi":"Kalevi", "ikä":62, "auto":null}';
objekti = JSON.Parse(json);
Sen jälkeen objektiin voi viitata tavalliseen tapaan
nimi = objekti.nimi;
tai
nimi = objekti["nimi"];
JavaScript-objekti muutetaan vastaavasti Json-merkkijonoksi
json = JSON.stringify(objekti);
NoSQL-tietokannoista esimerkiksi MongoDB tallentaa tiedot Jsonin kaltaisessa muodossa, joten sitä on helppo käyttää yhdessä Jsonin kanssa.
Ei se mielestäni paljoa eroa XML, kuten muunkaan kuvauskielen tulkkaamisesta...
Onkos Jsoniin skeemaa tehtävissä, että tietää sen olevan validia?
Json itsessään on pelkkä stringi, mutta siihen on olemassa schema-viritelmä validoimista varten.
https://restfulapi.net/json-schema/
Meinaako aloittaja "raakamuodolla" esimerkiksi binääristä esitystapaa?
Jossain evästeissä ei voi siirtää kuin merkkijonomuotoista dataa. Voihan sinne tietysti vaikka base64-koodattuakin tunkea, mutta menee koko idea järkevästä tiedonsiirrosta, jos ei nimenomaan ole tarkoitus siirtää binääriä tietoa, esimerkiksi kuvaa.
Evästeissä siirrellään yleensä käyttäjän autentikointiin liittyviä tietoja (tokeneita jne.), ja REST-rajapinnassa muuta dataa, joka sekin on usein json-muotoista, pl. binäärit.
Olen Php:lla tuottanut ja lukenut jopa 50-80 megan json-dataa, hyvin on onnistunut.
Delphillä esim. lkjson toimii, joskin on kankea.
Tosin ensimmäiseksi jos lataan netistä jonkun muun tekemän JSON tai XML -parserin Delphille, niin muokkaan koodia itse: käytän hyväksi Delphin Default Property -ominaisuutta.
Se mahdollistaa ns. ketjuviittaukset kun jokainen JSON tai XML -ilmentymä voi palauttaa toisen ilmentymän - ja vasta viimeisen ilmentymän perään voi sitten kirjoittaa:
.AsInteger
.AsString
.AsDouble
.AsBoolean
jne.
haittana on se, että koska Delphi on vahvasti tyypitetty kieli - jos arvaat tyypin väärin -> poikkeus.
ehkä se pitäisi koodata:
Element := RootElement['Period'];
if Element.OkAsInteger then N := Element.AsInteger else begin
// Element ei ole tyyppiä, jota voisi käsitellä kokonaislukuna.
end;
Toisena harmina: nuo web -maailman kotkotukset [XML, JSON] ovat dynaamisesti tyypitettyjä - ja myös sellaisia, että aina on riski viitata olemattomaan olioon ketjutettaessa.
Kumpi sitten parempi - sekö että ketjutus tällöin aiheuttaa poikkeuksen - vai sekö, että olisi ohjelman alussa luotu NullElement vailla sisältöä - ja sensijaan että virheellinen viittaus palauttaisi NIL, se palauttaisikin NullElement.
kehitysvaiheessa pitäisi ehkä olla 2 ohjelmaa: se mitä olet kehittämässä, ja toinen, millä näkisi graafisessa muodossa puurakenteena XML tai JSON -sisällön - ja mihin tahansa elementtiin klikattaessa saisi automaattisesti generoidun polun ko. elementtiin.