O privire profundă asupra JSON vs. XML, Partea 3: XML și viitorul JSON

În partea 2 a acestui articol, am analizat mai îndeaproape JSON ca schimb de date și am evaluat punctele forte și punctele slabe ale aplicațiilor simple față de cele complexe. JSON se evidențiază drept cel mai concis, cel mai compact format care poate fi citit de om, dar simplitatea sa de bază poate duce la implicații nedorite atunci când este utilizat pentru cazuri de utilizare complexe. Cu JSON ca schimb de date, dezvoltatorii sunt lăsați pe cont propriu să implementeze funcționalitățile care lipsesc din JSON însuși, rezultând soluții cuplate și non-standard care încearcă să îndeplinească decalajul. Pentru soluțiile de întreprindere ferme în afirmarea funcționării fără erori, utilizarea JSON poate duce la modele nedorite care pot împiedica calitatea codului, stabilitatea și rezistența la viitoarele necunoscute ale sistemului. Oferă XML capabilități pentru a ajuta aplicațiile să reducă acest risc? Pot fi realizate aceleași funcționalități cu JSON? O privire mai atentă la XML ca schimb de date va dezvălui punctele sale forte în reducerea riscului software și va oferi dezvoltatorilor o mai bună înțelegere a tiparelor care ar putea ajuta la îmbunătățirea calității aplicațiilor lor.

În partea 3 a acestui articol, vom:

1. Explorați XML ca schimb de date și evaluați-i punctele forte în susținerea cerințelor complexe.
2. Discutați despre viitorul JSON și explorați soluții care aduc punctele forte ale XML la JSON pentru a le permite dezvoltatorilor să creeze software mai stabil și mai rezistent la erori și necunoscute viitoare.

XML este ușor etichetat ca alternativă complexă și verbosă la JSON. Site-ul web w3schools.com—o referință populară pentru standardele web—oferă doar 58 de cuvinte pe tema „De ce JSON este mai bun decât XML” ¹ . O astfel de evaluare simplistă a JSON vs. XML este înșelătoare, deoarece XML oferă mult mai mult decât un simplu schimb de date. De fapt, XML nu a fost conceput doar pentru schimbul de date, ci mai degrabă ca limbaj pentru a specifica limbaje de marcare personalizate pentru orice aplicație. Cu semantica sa strictă, XML a definit un standard pentru a afirma integritatea datelor documentelor XML, a oricărui sub-limbaj XML. Mulți dezvoltatori cred că „XML a eșuat și a fost înlocuit cu JSON”, dar acest lucru nu ar putea fi mai departe de adevăr. Inițial, XML a fost conceput pentru a fi utilizat pentru toate problemele de interoperabilitate a datelor și, până în prezent, rămâne „cel mai utilizat format din lume pentru reprezentarea și schimbul de informații”. ²

JSON este simplu, iar XML este puternic

În partea 2 a acestui articol, am explorat schimbul de date care implică contracte bazate pe consumatori (CDC), evoluția protocolului și validarea mesajelor. Cu JSON ca schimb de date, exemplul nostru – Banca Europeană – a fost provocat să ofere o soluție de atenuare a riscurilor pentru schimbul de date cu comercianții cu amănuntul. Banca a dorit modele de software care au dus la o cuplare scăzută, o încapsulare ridicată și o rezistență ridicată la necunoscutele viitoare. Cu JSON ca schimb de date, totuși, banca a fost prezentată cu modele care au rezultat în sensul opus: încapsulare scăzută, cuplare ridicată și o rezistență mai mică la necunoscutele viitoare.

Să revedem exemplul Băncii Europene și să înlocuim JSON ca format de schimb de date cu XML. Următoarele mesaje XML sunt echivalente cu mesajul JSON pentru fiecare tip de identificare de cont: SWIFT, IBAN și ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

În ciuda pierderii imediate a eficienței numărului de octeți bruti, XML își justifică verbozitatea prin sprijinirea unui domeniu mai larg în jurul schimbului de date. Prin codificarea datelor cu JSON, am reușit să rezolvăm cerințele imediate ale schimbului de date, dar nimic care să accepte mai multe variante de mesaje sau validarea acestora. Pentru a aborda domeniul de aplicare al contractelor determinate de consumatori, dezvoltatorii ar trebui să implementeze cod personalizat care ar avea ca rezultat o cuplare logică între formatul mesajului, conținutul acestuia și implementarea funcțională pentru procesarea acestuia. Alternativ, dezvoltatorul ar putea alege să alcătuiască un puzzle dintr-o colecție de biblioteci și cadre pentru a îndeplini cerințele mai înalte. Ambele abordări au ca rezultat o ceapă de straturi deasupra schimbului de date care sunt cuplate direct la aplicație. Prin codificarea datelor cu XML, totuși, suntem capabili să rezolvăm o mulțime de cerințe fără cuplare.

Echivalentele mesajelor XML utilizează două caracteristici specifice ale standardului XML: spații de nume și tipuri de instanțe. Atributul xmlns="urn:bank:message" specifică spațiul de nume al mesajului, iar atributul "xsi:type" specifică tipul instanței acestuia, ca "swift" , "iban" sau "ach" . Aceste două atribute sunt standarde XML care permit unui procesor de mesaje să identifice tipul mesajului, precum și să dereferente schema care definește regulile de validare.

Schema XML reprezintă diferențierea cheie între JSON și XML. Cu o schemă, un dezvoltator poate încapsula definiția normativă a formatului de mesaj într-un mediu separat de aplicație și poate defini constrângeri de valoare, oferind reguli de validare impuse de procesoarele XML. Un exemplu de schemă pentru Banca Europeană (cu spațiu de namespace: xmlns="urn:bank:message" ), complet cu descriptori de tip și constrângeri de valoare, este următorul document de schemă XML (XSD):

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Această schemă XML este echivalentă din punct de vedere logic cu funcția isValid(message) din partea 2. La prima vedere, această schemă XML este considerabil mai pronunțată decât isValid(message) . Totuși, diferența fundamentală dintre cele două este că isValid(message) este cuplat la aplicație, iar schema XML nu. Schema XML este un limbaj pentru exprimarea constrângerilor referitoare la documentele XML și există mai multe limbaje de schemă diferite în uz pe scară largă, dintre care principalele sunt: ​​definițiile tipului de document (DTD), Relax-NG, Schematron și definițiile schemei XML W3C (XSD). ). ³ Pentru Banca Europeană, schema XML oferă o soluție cu risc redus pentru cerințele de nivel superior fără cuplare.

O schemă XML duce la un risc software mai mic. Cu XML, regulile de validare a mesajelor sunt exprimate într-un limbaj de schemă care este separat de aplicație și, prin urmare, nu este cuplat la aceasta. Deoarece schema XML este complet detașată de sistem, sensul logic al formatului mesajului și implementarea funcțională pentru procesarea acestuia sunt decuplate. Schema XML oferă Băncii Europene un strat încapsulat care este singurul responsabil pentru contextul de validare a mesajelor, variabilitate, versiuni și multe altele.

Schema XML reprezintă definiția normativă a contractului condus de consumator. Pentru Banca Europeană, aceasta oferă o abordare atenuată de risc pentru a reduce $\xi_0$ mai aproape de 0. Deoarece schema este decuplată de bancă și de comerciant, ambele părți o pot folosi pentru a valida și a pune în aplicare contractul.

De ce este schema XML atât de detaliată?

Specificația de schemă XML oferă un limbaj pentru dezvoltatori pentru a implementa modele structurale și logice utilizate pentru a defini și a constrânge toate părțile constitutive ale oricărui document XML. Cu o schemă XML, dezvoltatorii sunt capabili să încorporeze un sens mai profund în fiecare parte structurală și logică a unui document XML. De exemplu, schema XML permite următoarele:

1. Definirea constrângerilor de expresie regulată pentru șirurile constitutive,
2. Definirea intervalelor și a formatelor pentru numerele constituente,
3. Definirea elementelor constitutive și atributelor obligatorii și opționale,
4. Definirea cerințelor cheie și de referință într-un document și multe, multe altele.

Cu o schemă XML, un sistem se poate baza pe validatori XML generici pentru a afirma validitatea fiecărui mesaj de intrare, reducând intrinsec „spațiul de eroare” $\xi_0$ mai aproape de 0 și izolând automat logica de afaceri de intrările eronate.

Riscul dezvoltării viitoare

Sistemele pot utiliza caracteristici inerente ale specificației XML pentru a reduce riscul de dezvoltare a software-ului în viitor. Prin acordul asupra unui contract normativ sub forma unei scheme XML, sistemele definesc regulile și constrângerile pentru toate obiectele și proprietățile (elementele și atributele, pentru XML) care urmează să fie interschimbate. Ulterior, sistemele sunt capabile să utilizeze domeniul mai larg al specificațiilor XML pentru a aborda variabilitatea mesajelor, versiunea protocolului și validarea conținutului. De exemplu, spațiile de nume XML oferă mesaje XML cu informațiile necesare pentru:

1. Identificați versiunea mesajului.
2. Dereferirea schemei contractuale normative.
3. Validați corectitudinea unui document.

Cu o gamă largă de caracteristici și capabilități oferite de schema XML, majoritatea cerințelor complexe din jurul schimbului de date pot fi rezolvate cu XML însuși. La asta se referea Dr. Charles Goldfarb când a spus „[XML este] Sfântul Graal al computerelor”. ⁴

Schema XML ajută aplicațiile să fie rezistente la erori și maleabile la schimbările viitoare.

XML este o specificație acceptată pe scară largă și verificată în detaliu, cu nenumărate biblioteci disponibile pentru toate platformele pentru a ajuta la procesarea și validarea documentelor XML. Având XML ca format de schimb de date, un dezvoltator este capabil să rezolve cerințele imediate, precum și cele referitoare la contractele bazate pe consumatori, variabilitatea mesajelor, versiunea protocolului și validarea conținutului. XML permite unui dezvoltator să protejeze riscul cerințelor complexe și, mai important, al necunoscutelor viitoare.

XML este mult mai mult decât schimbul de date și poate fi folosit pentru a rezolva probleme mult mai mari decât cu JSON. Când este privit din această perspectivă, domeniul de aplicare al XML acoperă o mare parte din ceapă, prin care mai multe dintre straturile cepei sunt cuprinse în domeniul de aplicare al XML în sine.

Atunci când alegem cel mai bun format de schimb de date pentru o aplicație, este doar centrul cepei la care ne pasă sau este ceapa în întregime?

Diferențele fundamentale dintre JSON și XML

XML oferă mult mai mult decât schimbul de date și poate fi folosit pentru a rezolva probleme mult mai mari decât cu JSON. Domeniul de aplicare al cerințelor complexe din jurul schimbului de date este compatibil cu XML, permițând sistemelor să utilizeze biblioteci și cadre conforme cu un standard, decuplate de aplicație.

XML este o specificație care abordează domeniul de aplicare al cerințelor complexe prin proiectare și este un standard definit de W3C și susținut de toți furnizorii de software relevanți și platformele lingvistice. Folosind XML ca schimb de date, aplicațiile profită automat de o reducere sistematică a riscului software.

Viitorul JSON

JSON este incontestabil aici pentru a rămâne. Având JavaScript ca platformă de dezvoltare cea mai utilizată astăzi, JSON a devenit cel mai proeminent format de schimb de date. Pentru proiectele mici cu complexitate redusă, JSON se potrivește perfect. Dar, pe măsură ce ne străduim să creăm aplicații mai mari și mai bune pentru viitor, complexitatea generală a software-ului nostru este destinată să crească. Având ca exemplu capabilitățile puternice ale XML, mai multe grupuri s-au străduit să inventeze standarde similare pentru JSON.

Deficiența fundamentală a JSON este lipsa acestuia de a oferi un standard general pentru descrierea normativă a constituenților logici ai documentelor sale.

Schema JSON

În 2009, un grup a început schema JSON ⁵ , care este un vocabular pentru adnotarea și validarea documentelor JSON. Schema JSON folosește semantica JSON pentru a defini un set de reguli și constrângeri pentru elementele constitutive ale documentelor JSON și mai multe proiecte pe diverse platforme au implementat biblioteci care acceptă specificația schemei JSON. Deși nu este încă un standard oficial, proiectul de schemă JSON oferă o soluție pentru un domeniu de cerințe care este similar cu specificația schemei XML. Cu vocabularul schemei JSON, dezvoltatorii pot defini regulile și constrângerile logice și structurale ale documentelor JSON. Schema poate fi apoi utilizată pentru a ajuta la procesarea și validarea documentelor JSON cu biblioteci care sunt decuplate de aplicație, reducând astfel necesitatea ca codul neîncapsulat să fie amestecat în aplicație. Cu schema JSON, un dezvoltator poate alege JSON ca format pentru schimbul său de date și poate aborda, într-o manieră atenuată de riscuri, cerințele complexe care nu puteau fi adresate anterior doar cu JSON.

Proiectul de schemă JSON este un efort al comunității și, după un deceniu de revizuiri, este specificația predominantă pentru schemele JSON. Deși nu este încă un standard, popularitatea proiectului de schemă JSON indică nivelul de interes pentru o astfel de soluție. Din punct de vedere conceptual, specificația schemei JSON seamănă cu schema XML, dar o comparație a celor două dezvăluie diferențe între modelele, capacitățile și semantica lor. De exemplu, deși limbajul definește o gamă largă de proprietăți pentru a constrânge limitele tipurilor de valori JSON, numeroasele sale atribute permit exprimarea definițiilor schemelor care se contrazic.

De exemplu, următorul fragment definește un tip de "object" care conține trei proprietăți: "number" , "street_name" și "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

Definiția unui tip "object" acceptă constrângeri suplimentare, dintre care una este "minProperties" . Prin modificarea definiției de tip "object" de mai sus cu "minProperties": "4" , definiția devine fără sens, deoarece doar trei proprietăți sunt definite în mod explicit pentru obiect.

Schema JSON are un număr considerabil de mare și larg de proprietăți de constrângere, dintre care multe sunt esențiale pentru a limita în mod eficient documentele JSON și multe dintre ele se suprapun unele cu altele. Cu proprietăți de constrângere care se suprapun în sens, vocabularul schemei JSON prezintă două familii de provocări:

1. Necesită o curbă de învățare mai mare de la dezvoltatori, datorită vocabularului larg și a nuanțelor neobișnuite sau neconvenționale din semantică.
2. Este mai dificil de implementat pentru bibliotecile de validare, ceea ce duce la soluții care implementează zonele gri în mod diferit, rezultând implementări inconsistente.

Limbajul de schemă XML nu este în sine complet liber de a permite exprimarea definițiilor care se contrazic, dar ele sunt mult mai puține și limitate. De fapt, specificația schemei XML a fost dezvoltată cu o atenție deosebită atât pentru ușurința de utilizare pentru dezvoltatori, cât și pentru bibliotecile care implementează specificația. În plus, proiectul de schemă JSON definește doar specificația limbajului de schemă, dar există multe proiecte comunitare care implementează această specificație.

Validatorul de schemă JSON ⁶ este un proiect popular care implementează un validator de schemă JSON pentru platforma Java. Prin integrarea acestei biblioteci într-o aplicație Java, aplicația este capabilă să afirme conformitatea tuturor documentelor JSON interschimbate. Alte implementări ale specificației schemei JSON sunt disponibile pentru o varietate de platforme.

Pentru Banca Europeană, să folosim schema JSON pentru a implementa o schemă pentru mesajele JSON cu identificatori de cont.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Această schemă JSON definește cele 3 tipuri de obiecte: "swift" , "iban" și "ach" . Specifică modele de expresie regulată pentru a afirma că informațiile despre cont nu sunt nevalide și declară "type" și "code" drept proprietăți necesare pentru fiecare tip, în plus față de "routing" ca proprietate necesară pentru tipul "ach" . Cu această schemă JSON, Banca Europeană își poate valida intrarea JSON pentru a afirma că conținutul mesajului este corect pentru fiecare interacțiune.

Schema JSON aduce multe capacități de XML în JSON, dar este încă o lucrare în curs. Deși este o soluție excelentă care poate fi folosită pentru a acoperi riscul software, specificația schemei JSON nu este perfectă. Datorită evoluției informale a limbajului său, limbajul a evoluat într-o direcție care omite caracteristici importante și conține modele de expresie structurale și logice care sunt confuze și neconvenționale. De exemplu, limbajului de schemă îi lipsește capacitatea de a defini tipuri abstracte, ceea ce îi poate determina pe dezvoltatori să implementeze soluții alternative care au ca rezultat un risc software asociat propriu. ⁷

Proiectul de schemă JSON a adus o bogăție neprețuită de contribuții la conceptele din spatele unui limbaj de schemă pentru JSON. În ciuda deficiențelor în claritatea semanticii sale, limbajul de schemă JSON este o soluție versatilă care aduce multe capabilități ale XML la JSON.

Pentru o privire mai atentă asupra specificației schemei JSON, consultați Înțelegerea schemei JSON.

JSONx

În 2014, un alt grup a început proiectul JSONx, care folosește direct XML pentru a oferi o soluție la fel de puternică pentru JSON. Proiectul JSONx a fost creat special pentru întreprindere și definește limbajul de definire a schemei JSON (JSD), care este modelat îndeaproape cu specificația schemei XML. Folosind schema XML ca model, JSD definește modele structurale și logice care se aseamănă mult cu limbajul de definire a schemei XML.

Pentru exemplul Băncii Europene, să folosim limbajul JSD pentru a implementa o schemă pentru mesajele JSON cu identificatori de cont.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

La prima vedere, schema JSD este similară ca expresie cu schema JSON. O diferență este însă semantica concisă a JSD-ului în comparație cu schema JSON. Specific acestui exemplu, JSD plasează proprietatea "use": "required" în definiția care este specificată, în timp ce schema JSON asociază această proprietate cu obiectul părinte, solicitând ca numele valorilor să se potrivească cu numele definiției proprietății. Constrângerea "use": "required" este specificată doar pe proprietatea "code" a obiectului "swift" și omisă din celelalte deoarece "use": "required" este valoarea implicită. Limbajul JSD a fost conceput ținând cont de toate aceste nuanțe și oferă o soluție curată și intuitivă pentru exprimarea schemelor JSON.

De la început, o proprietate distinctivă a proiectului JSONx este intenția sa principală de a oferi claritate și utilitate dezvoltatorilor. Pentru a realiza acest lucru, o caracteristică puternică a JSD este convertibilitatea sa în JSDx - limbajul JSD poate fi exprimat în fișiere JSON, precum și în fișiere XML. Ambele formulare sunt traducibile unu-la-unu și oferă dezvoltatorilor posibilitatea de a utiliza instrumente avansate de editare XML pentru a ajuta la crearea documentelor JSD care să fie validate în direct și fără erori.

Schema JSD de mai sus poate fi exprimată în următoarea formă JSDx:

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

Forma JSDx a JSD-ului este puternică deoarece oferă o specificație clară, cu autovalidare și cu riscuri reduse pentru definirea schemelor JSON.

Limbajul JSD este conceput pentru a răspunde preocupărilor legate de definițiile care se contrazic și se bazează pe modele standard pentru exprimarea constrângerilor. Proiectate în strânsă asemănare cu limbajul XML Schema Definition (XSD), declarațiile de tip JSD și definițiile constrângerilor seamănă foarte mult cu structurile echivalente din XML. Specificația JSD(x) oferă o soluție completă pentru definirea constrângerilor structurale și logice și se auto-descrie - oferind o definiție normativă a limbajului JSD(x) exprimată în limbajul JSD(x). Pentru o privire mai atentă asupra specificației JSD(x), consultați JSON Schema Definition Language.

Pe lângă limbajul JSD(x), proiectul JSONx oferă implementări de referință ale procesoarelor și validatorilor JSD(x), precum și un API de legare a clasei și un generator de cod pentru platforma Java. Cu API-ul și generatorul de legare, un dezvoltator poate folosi o schemă JSD(x) pentru a genera automat clase pentru definițiile obiectelor din schema dorită, care poate fi folosită pentru a analiza și a clasifica documente JSON care sunt conforme cu schema. Clasele generate oferă o legătură puternică între schemă și platforma Java, reprezentând utilizarea, constrângerile și relațiile specificate în schemă. Cu legături puternic tipizate la schemă, aplicația reduce și mai mult riscul software legat de modificările viitoare care ar putea duce la incompatibilități.

Folosind compilatorul Java, legăturile puternic tipizate identifică incompatibilitățile cu erorile de compilare, reducând efectiv riscul erorilor legate de procesarea mesajelor aproape de zero. Acest model de inginerie le permite dezvoltatorilor să implementeze modificări și să rezolve incompatibilitățile rapid și cu încredere, fără a fi nevoiți să se bazeze pe timpul de execuție pentru a găsi erori sau cazuri de eșec – și mai ales nefiind nevoiți să se bazeze pe utilizatorii să se împiedice de erori înșiși. API-ul de legare este implementat cu adnotări Java, ceea ce permite oricărei clase să fie legată la o schemă JSD(x) cu tipuri puternice, dar într-o manieră ușoară. Capacitățile de legare și generare de cod puternic tipizate ale JSONx acceptă întregul domeniu de aplicare al specificației JSD(x), concepute special pentru a îndeplini standardele înalte pentru soluțiile de întreprindere.

Cadrul JSONx a fost creat pentru soluții de întreprindere și oferă un standard înalt de calitate și utilitate pentru sisteme complexe, precum și ușurință de utilizare și validare a erorilor de editare pentru dezvoltatori.

Motorul de legare JSD(x), procesorul și validatorul raportează o acoperire de testare de 87%, permițând dezvoltatorilor Java să integreze cu încredere cadrul pentru a lega schemele JSD(x) la aplicațiile lor Java și pentru a codifica, decoda și valida documentele JSON. Pentru o privire mai atentă asupra cadrului JSONx pentru Java, consultați Cadrul JSONx pentru Java.

Concluzie

Cu o privire mai profundă asupra istoriei web și a tendințelor software din ultimii ani, putem observa o relație strânsă între proliferarea JavaScript și popularitatea JSON. Multe articole și postări de blog oferă o perspectivă limitată atunci când se compară JSON și XML, determinând cititorii să considere XML ca fiind învechit și lăsând pe mulți să nu conștientizeze capabilitățile puternice care îi pot ajuta să-și îmbunătățească arhitectura software-ului, rezistența software-ului lor la schimbare și calitatea generală și stabilitatea software-ului în ansamblu. Cu o evaluare mai profundă a punctelor tari și punctelor slabe ale fiecărui standard, dezvoltatorii pot fi împuterniciți să ia decizii mai bune pentru proiectele lor.

La fel ca „catastrofa de divergență” cu HTML care a dus la inventarea XML, un efect similar este realizat în bazele de cod complexe care se bazează pe JSON pentru schimbul de date. Specificația JSON nu încapsulează funcționalitățile imediate din jurul schimbului de date, ceea ce poate duce la fragmentarea logicii în straturile superioare ale aplicației. Cu XML, totuși, dezvoltatorii sunt capabili să împingă complexitatea din jurul schimbului de date către straturile inferioare ale aplicației, rezultând capacitatea de a detecta erori mai devreme în ciclul de viață al aplicației. În special pentru limbajele compilate, în combinație cu un cadru de legare, arhitecturile care se bazează pe legarea XML pot reduce potențialul erorilor legate de date aproape de zero. Pentru întreprindere, aceste capabilități puternice de reducere sistematică a riscului software sunt cele care fac din XML „Sfântul Graal al computerelor”.

JSON este aici pentru a rămâne, iar mai multe proiecte câștigă avânt pentru a oferi capabilitățile puternice ale XML către JSON. Proiectul de schemă JSON oferă o specificație de schemă dezvoltată de comunitate, care a crescut organic pentru a sprijini o gamă largă de atribute și modele declarative pentru a descrie și constrânge documentele JSON. Proiectul JSONx oferă un limbaj de schemă la nivel de întreprindere, care este proiectat în strânsă asemănare cu limbajul de definire a schemei XML și oferă atât formate JSON, cât și formate XML pentru specificarea documentelor de schemă JSON. Cu aceste specificații și cadre, dezvoltatorii sunt capabili să reducă riscul software legat de cerințele de nivel superior din jurul schimbului de date, cum ar fi contractele bazate pe consumatori, versiunea de protocol, validarea conținutului și multe altele.

Caracteristicile avansate ale XML au fost concepute pentru a atenua riscul software legat de limbajele de marcare. Cazurile de utilizare cu JSON nu sunt diferite, iar un limbaj de schemă este o soluție testată în timp și dovedită pentru a acoperi în mod sistematic gama largă de riscuri software legate de schimbul de date.

Referințe

1. JSON vs. XML (w3schools.com, decembrie 2016)

2. Succesul mondial care este XML (W3C, iulie 2018)

3. W3C - Ce este o schemă XML? (W3C, octombrie 2009)

4. Internetul: o enciclopedie istorică. Cronologie, volumul 3, p. 130 (ABC-CLIO, 2005)

5. Schema JSON (iulie 2008)

6. Validator de schemă JSON (GitHub)

7. JsonSchema și SubClassing (Horne, martie 2016)