JSON ve XML'e Derin Bir Bakış, Bölüm 3: XML ve JSON'un Geleceği

Bu makalenin 2. Bölümünde, veri alışverişi olarak JSON'a daha yakından baktık ve karmaşık uygulamalara karşı basit uygulamalar için güçlü ve zayıf yönlerini değerlendirdik. JSON, en özlü, en kompakt insan tarafından okunabilen format olarak öne çıkıyor, ancak temel basitliği, karmaşık kullanım durumları için kullanıldığında istenmeyen sonuçlara yol açabilir. Veri alışverişi olarak JSON ile geliştiriciler, JSON'un kendisinde olmayan işlevleri uygulamak için kendi başlarına bırakılır ve bu, boşluğu doldurmaya çalışan birleşik ve standart olmayan çözümlerle sonuçlanır. Hatasız çalışma iddiasında kararlı kurumsal çözümler için JSON kullanımı, sistemin kod kalitesini, kararlılığını ve gelecekteki bilinmeyenlere karşı direncini engelleyebilecek istenmeyen kalıplara neden olabilir. XML, uygulamaların bu riski azaltmasına yardımcı olacak yetenekler sunuyor mu? Aynı işlevler JSON ile elde edilebilir mi? Veri değişimi olarak XML'e daha yakından bakmak, yazılım riskini azaltmadaki güçlü yanlarını ortaya çıkaracak ve geliştiricilere uygulamalarının kalitesini artırmaya yardımcı olabilecek kalıpları daha iyi anlamalarını sağlayacaktır.

Bu makalenin 3. Bölümünde şunları yapacağız:

1. Veri alışverişi olarak XML'i keşfedin ve karmaşık gereksinimleri desteklemedeki güçlü yönlerini değerlendirin.
2. JSON'un geleceğini tartışın ve geliştiricilerin daha kararlı ve hatalara ve gelecekteki bilinmeyenlere karşı daha dirençli yazılımlar oluşturmasını sağlamak için XML'in güçlü yönlerini JSON'a getiren çözümleri keşfedin.

XML, JSON'un karmaşık ve ayrıntılı alternatifi olarak kolayca etiketlenir. Web standartları için popüler bir referans olan w3schools.com web sitesi, “JSON neden XML'den daha iyidir” ¹ konusunda yalnızca 58 kelime sunmaktadır. JSON'a karşı XML'in bu kadar basit bir değerlendirmesi yanıltıcıdır çünkü XML, veri alışverişinden çok daha fazlasını sağlar. Aslında, XML yalnızca veri alışverişi için değil, herhangi bir uygulama için özel biçimlendirme dilleri belirtmek için bir dil olarak tasarlanmıştır. XML, katı semantiğiyle, herhangi bir XML alt dilinin XML belgelerinin veri bütünlüğünü doğrulamak için bir standart tanımladı. Birçok geliştirici, "XML'nin başarısız olduğuna ve JSON ile değiştirildiğine" inanıyor, ancak bu gerçeklerden daha fazla olamazdı. Başlangıçta, XML'in tüm veri birlikte çalışabilirlik sorunları için kullanılması düşünülmüştü ve bu güne kadar "bilgiyi temsil etmek ve değiş tokuş etmek için dünyanın en yaygın kullanılan biçimi" olarak kaldı. ²

JSON Basittir ve XML Güçlüdür

Bu makalenin 2. Bölümünde, tüketici odaklı sözleşmeleri (CDC'ler), protokol gelişimini ve mesaj doğrulamasını içeren veri alışverişini araştırdık. Veri alışverişi olarak JSON ile, örneğimiz olan Avrupa Bankası, perakendecilerle veri alışverişi için riski azaltılmış bir çözüm sağlamakta zorlandı. Banka, düşük bağlantı, yüksek kapsülleme ve gelecekteki bilinmeyenlere karşı yüksek dayanıklılık ile sonuçlanan yazılım kalıplarını arzuladı. Bununla birlikte, veri alışverişi olarak JSON ile, bankaya bunun tersiyle sonuçlanan kalıplar sunuldu: düşük kapsülleme, yüksek birleştirme ve gelecekteki bilinmeyenlere karşı daha düşük esneklik.

Avrupa Bankası örneğini tekrar gözden geçirelim ve veri değişim formatı olarak JSON'u XML ile değiştirelim. Aşağıdaki XML mesajları, her hesap tanımlayıcı türü için JSON mesajına eşdeğerdir: SWIFT, IBAN ve 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>

Ham bayt sayısı verimliliğindeki ani kayba rağmen, XML, veri alışverişini çevreleyen daha geniş bir kapsamı destekleyerek ayrıntı düzeyini haklı çıkarır. Verileri JSON ile kodlayarak, veri alışverişinin acil gereksinimlerini çözebildik, ancak birden fazla mesaj varyantını veya bunların doğrulanmasını destekleyecek hiçbir şey olmadı. Tüketici odaklı sözleşmeleri çevreleyen kapsamı ele almak için geliştiricilerin, mesaj formatı, içeriği ve işlenmesi için işlevsel uygulama arasında mantıksal bağlantı ile sonuçlanacak özel kod uygulamaları gerekir. Alternatif olarak, geliştirici, daha yüksek gereksinimleri karşılamak için bir kitaplık ve çerçeve koleksiyonundan oluşan bir bulmacayı bir araya getirmeyi seçebilir. Her iki yaklaşım da, doğrudan uygulamaya bağlanan veri alışverişinin üzerinde bir katman soğanı ile sonuçlanır. Bununla birlikte, verileri XML ile kodlayarak, gereksinimlerin bir çok hareketini birleştirme olmadan çözebiliriz.

XML mesaj eşdeğerleri, XML standardının iki özel özelliğini kullanır: ad alanları ve örnek türleri. xmlns="urn:bank:message" özniteliği iletinin ad alanını belirtir ve "xsi:type" özniteliği, "swift" , "iban" veya "ach" olarak örnek türünü belirtir. Bu iki öznitelik, bir ileti işlemcisinin iletinin türünü tanımlamasına ve doğrulama kurallarını tanımlayan şemanın referansını kaldırmasına izin veren XML standartlarıdır.

XML şeması, JSON ve XML arasındaki temel farklılaştırıcıyı temsil eder. Bir şema ile geliştirici, mesaj formatının normatif tanımını uygulamadan ayrı bir ortama yerleştirebilir ve XML işlemcileri tarafından uygulanan doğrulama kurallarını sağlayan değer kısıtlamaları tanımlayabilir. Avrupa Bankası için ( namespace: xmlns="urn:bank:message" ), tür tanımlayıcıları ve değer kısıtlamalarıyla birlikte örnek bir şema, aşağıdaki XML şema belgesidir (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>

Bu XML şeması, Bölüm 2'deki isValid(message) işlevine mantıksal olarak eşdeğerdir. İlk bakışta, bu XML şeması, isValid(message) den çok daha ayrıntılıdır. Ancak ikisi arasındaki temel fark, isValid(message) öğesinin uygulamaya bağlı olması ve XML şemasının bağlı olmamasıdır. XML şeması, XML belgeleriyle ilgili kısıtlamaları ifade eden bir dildir ve yaygın olarak kullanılan birkaç farklı şema dili vardır, bunların başlıcaları: belge türü tanımları (DTD'ler), Relax-NG, Schematron ve W3C XML şema tanımları (XSD). ). ³ Avrupa Bankası için, XML şeması, bağlantı olmaksızın daha yüksek katman gereksinimleri için riski azaltılmış bir çözüm sağlar.

Bir XML şeması, daha düşük yazılım riski ile sonuçlanır. XML ile, mesajların doğrulanması için kurallar, uygulamadan kopuk ve dolayısıyla uygulamayla bağlantılı olmayan bir şema dilinde ifade edilir. XML şeması sistemden tamamen ayrıldığından, mesaj formatının mantıksal anlamı ve işlenmesi için işlevsel uygulama birbirinden ayrılmıştır. XML şeması, Avrupa Bankasına ileti doğrulama, değişkenlik, sürüm oluşturma ve daha pek çok bağlamdan tek başına sorumlu olan kapsüllenmiş bir katman sağlar.

XML şeması, tüketici odaklı sözleşmenin normatif tanımını temsil eder. Avrupa Bankası için bu, $\xi_0$'ı 0'a yaklaştırmak için riski azaltan bir yaklaşım sağlar. Şema bankadan ve perakendeciden ayrıldığından, her iki taraf da sözleşmeyi doğrulamak ve uygulamak için kullanabilir.

XML Şeması Neden Bu Kadar Ayrıntılı?

XML şema belirtimi, geliştiricilere, herhangi bir XML belgesinin tüm bileşenlerini tanımlamak ve sınırlamak için kullanılan yapısal ve mantıksal kalıpları uygulamak için bir dil sağlar. Bir XML şemasıyla geliştiriciler, bir XML belgesinin her yapısal ve mantıksal parçasına daha derin anlamlar yerleştirebilirler. Örneğin, XML şeması şunlara izin verir:

1. Oluşturucu dizeler için düzenli ifade kısıtlamalarının tanımı,
2. Bileşen sayıları için aralıkların ve biçimlerin tanımı,
3. Gerekli ve isteğe bağlı kurucu unsurların ve niteliklerin tanımı,
4. Bir belgedeki temel ve referans gereksinimlerin tanımı ve çok, çok daha fazlası.

Bir XML şemasıyla, bir sistem, her bir girdi mesajının geçerliliğini doğrulamak için genel XML doğrulayıcılarına güvenebilir, bu da "hata alanını" $\xi_0$'ı 0'a yaklaştırarak ve iş mantığını otomatik olarak hatalı girdilerden yalıtarak.

Gelecekteki Gelişim Riski

Sistemler, gelecekteki geliştirme yazılım riskini azaltmak için XML belirtiminin doğal özelliklerini kullanabilir. Sistemler, bir XML şeması biçiminde normatif bir sözleşme üzerinde anlaşmaya vararak, değiş tokuş edilecek tüm nesneler ve özellikler (öğeler ve nitelikler, XML için) için kuralları ve kısıtlamaları tanımlar. Sistemler bundan sonra, mesaj değişkenliğini, protokol versiyonlarını ve içerik doğrulamasını ele almak için XML spesifikasyonunun daha geniş kapsamından faydalanabilir. Örneğin, XML ad alanları, XML mesajlarına aşağıdakiler için gerekli bilgileri sağlar:

1. Mesajın sürümünü tanımlayın.
2. Normatif sözleşme şemasına başvurun.
3. Bir belgenin doğruluğunu onaylayın.

XML şemasının sunduğu geniş kapsamlı özellik ve yeteneklerle, veri alışverişini çevreleyen karmaşık gereksinimlerin çoğu XML'in kendisi ile çözülebilir. Bu, Dr. Charles Goldfarb'ın "[XML] bilgi işlemin kutsal kâsesidir" derken kastettiği şeydi. ⁴

XML şeması, uygulamaların hatalara karşı dirençli olmasına ve gelecekteki değişikliklere karşı esnek olmasına yardımcı olur.

XML, XML belgelerinin işlenmesine ve doğrulanmasına yardımcı olmak için tüm platformlar için mevcut sayısız kitaplığa sahip, geniş çapta kabul görmüş ve baştan sona incelenmiş bir belirtimdir. Veri değişim formatı olarak XML ile bir geliştirici, tüketici odaklı sözleşmeler, mesaj değişkenliği, protokol versiyonlama ve içerik doğrulama ile ilgili acil gereksinimlerin yanı sıra çözebilir. XML, bir geliştiricinin karmaşık gereksinimler ve daha da önemlisi gelecekteki bilinmeyenler riskinden korunmasını sağlar.

XML, veri alışverişinden çok daha fazlasıdır ve JSON'dan çok daha büyük sorunları çözmek için kullanılabilir. Bu perspektiften bakıldığında, XML'in kapsamı soğanın daha büyük bir bölümünü kapsar, bu sayede soğanın birkaç katmanı XML'in kendi kapsamında yer alır.

Bir uygulama için en iyi veri alışverişi formatını seçerken, soğanın sadece merkezini mi önemsiyoruz yoksa soğanın tamamı mı?

JSON ve XML Arasındaki Temel Farklılıklar

XML, veri alışverişinden çok daha fazlasını sunar ve JSON'dan çok daha büyük sorunları çözmek için kullanılabilir. Veri alışverişini çevreleyen karmaşık gereksinimlerin kapsamı, sistemlerin uygulamadan ayrılmış, bir standarda uygun kitaplıkları ve çerçeveleri kullanmasına olanak tanıyan XML tarafından barındırılır.

XML, tasarım yoluyla karmaşık gereksinimlerin kapsamını ele alan bir belirtimdir ve W3C tarafından tanımlanan ve tüm ilgili yazılım satıcıları ve dil platformları tarafından desteklenen bir standarttır. XML'i veri alışverişi olarak kullanarak, uygulamalar yazılım riskinin sistematik olarak azaltılmasından otomatik olarak yararlanır.

JSON'un Geleceği

JSON inkar edilemez bir şekilde burada kalacak. JavaScript'in günümüzde en yaygın kullanılan geliştirme platformu olmasıyla birlikte JSON, en belirgin veri değişim formatı haline geldi. Düşük karmaşıklığa sahip küçük projeler için JSON mükemmel bir seçimdir. Ancak gelecek için daha büyük ve daha iyi uygulamalar yaratmaya çalıştıkça, yazılımımızın genel karmaşıklığı artmaya mahkumdur. Örnek olarak XML'in güçlü yetenekleriyle, birkaç grup JSON için benzer standartlar icat etmeye çalıştı.

JSON'un temel eksikliği, belgelerinin mantıksal bileşenlerinin normatif açıklaması için genel bir standart sağlamadaki eksikliğidir.

JSON Şeması

2009'da bir grup, JSON belgelerine açıklama eklemek ve doğrulamak için bir kelime hazinesi olan JSON şeması ^5'i başlattı. JSON şeması, JSON belgelerinin bileşenleri için bir dizi kural ve kısıtlamayı tanımlamak için JSON semantiğini kullanır ve çeşitli platformlardaki birçok proje, JSON şema belirtimini destekleyen kitaplıklar uygulamıştır. Henüz resmi bir standart olmasa da, JSON şema projesi, XML şema belirtimine benzer bir gereksinim kapsamına çözüm sağlar. JSON şema sözlüğü ile geliştiriciler, JSON belgelerinin mantıksal ve yapısal kurallarını ve kısıtlamalarını tanımlayabilir. Şema daha sonra uygulamadan ayrılmış kitaplıklarla JSON belgelerinin işlenmesine ve doğrulanmasına yardımcı olmak için kullanılabilir, böylece kapsüllenmemiş kodun uygulamada karıştırılması ihtiyacını azaltır. JSON şemasıyla, bir geliştirici, veri alışverişinin formatı olarak JSON'u seçebilir ve riski azaltılmış bir şekilde, daha önce yalnızca JSON ile ele alınamayan karmaşık gereksinimlere hitap edebilir.

JSON şema projesi bir topluluk çalışmasıdır ve on yıllık revizyondan sonra JSON şemaları için geçerli belirtim olarak kalır. Henüz bir standart olmamasına rağmen, JSON şema projesinin popülaritesi böyle bir çözüme olan ilginin seviyesini gösteriyor. Kavramsal olarak, JSON şeması belirtimi XML şemasına benzer, ancak ikisinin karşılaştırılması modelleri, yetenekleri ve anlambilimi arasındaki farkları ortaya çıkarır. Örneğin, dil, JSON değer türlerinin sınırlarını sınırlamak için çok çeşitli özellikler tanımlasa da, sayısız özniteliği, kendi kendine çelişen şema tanımlarının ifadesine izin verir.

Örneğin, aşağıdaki alıntı, üç özelliği içeren bir "object" tipini tanımlar: "number" , "street_name" ve "street_type" .

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

Bir "object" türünün tanımı, biri "minProperties" olan ek kısıtlamaları kabul eder. Yukarıdaki "object" türü tanımını bir "minProperties": "4" ile değiştirerek tanım anlamsız hale gelir, çünkü nesne için yalnızca üç özellik açıkça tanımlanmıştır.

JSON şeması, birçoğu JSON belgelerini etkili bir şekilde sınırlamak için gerekli olan ve çoğu birbiriyle örtüşen oldukça büyük ve çok sayıda kısıtlama özelliğine sahiptir. Anlam bakımından örtüşen kısıtlama özellikleriyle, JSON şema sözlüğü iki zorluk ailesi sunar:

1. Geniş kelime dağarcığı ve semantiğindeki olağandışı veya alışılmamış nüanslar nedeniyle geliştiricilerden daha yüksek bir öğrenme eğrisi gerektirir.
2. Doğrulama kitaplıklarının uygulaması daha zordur, bu da gri alanları farklı şekilde uygulayan ve tutarsız uygulamalara neden olan çözümlere yol açar.

XML şema dili, kendisiyle çelişen tanımların ifadesine izin vermekten tamamen özgür değildir, ancak bunlar çok daha az ve sınırlıdır. Aslında, XML şema belirtimi, hem geliştiriciler için hem de belirtimi uygulayan kitaplıklar için kullanım kolaylığına yakından dikkat edilerek geliştirilmiştir. Ayrıca, JSON şema projesi yalnızca şema dilinin belirtimini tanımlar, ancak bu belirtimi uygulayan birçok topluluk projesi vardır.

JSON şema doğrulayıcı ⁶ , Java platformu için bir JSON şema doğrulayıcı uygulayan popüler bir projedir. Bu kitaplığı bir Java uygulamasına entegre ederek uygulama, değiş tokuş edilen tüm JSON belgelerinin uygunluğunu iddia edebilir. JSON şema belirtiminin diğer uygulamaları, çeşitli platformlar için mevcuttur.

Avrupa Bankası için, hesap tanımlayıcıları olan JSON mesajları için bir şema uygulamak üzere JSON şemasını kullanalım.

 { "$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"] } } } }

Bu JSON şeması 3 nesne türünü tanımlar: "swift" , "iban" ve "ach" . Hesap bilgilerinin geçersiz olmadığını belirtmek için düzenli ifade kalıplarını belirtir ve "ach" türü için gerekli bir özellik olarak "routing" ye ek olarak "type" ve "code" u her tür için gerekli özellikler olarak bildirir. Bu JSON şemasıyla, Avrupa Bankası, mesaj içeriğinin her etkileşim için doğru olduğunu iddia etmek için JSON girişini doğrulayabilir.

JSON şeması, XML'in birçok özelliğini JSON'a getirir, ancak bu hala devam eden bir çalışmadır. Yazılım riskinden korunmak için kullanılabilecek harika bir çözüm olsa da, JSON şema belirtimi mükemmel değildir. Dilinin gayri resmi evrimi nedeniyle, dil, tartışmasız önemli özellikleri atlayan ve kafa karıştırıcı ve alışılmadık yapısal ve mantıksal ifade kalıpları içeren bir yönde gelişmiştir. Örneğin, şema dilinde soyut türleri tanımlama yeteneği eksiktir, bu da geliştiricilerin kendi ilişkili bir yazılım riskine yol açan karmaşık geçici çözümleri uygulamalarına yol açabilir. ⁷

JSON şema projesi, JSON için bir şema dilinin arkasındaki kavramlara paha biçilmez bir zenginlik kattı. Semantiğinin netliğindeki eksikliklere rağmen, JSON şema dili, XML'in birçok özelliğini JSON'a getiren çok yönlü bir çözümdür.

JSON şeması belirtimine daha yakından bakmak için JSON Şemasını Anlama bölümüne bakın.

JSONx

2014'te başka bir grup, JSON için eşit derecede güçlü bir çözüm sağlamak üzere doğrudan XML'den yararlanan JSONx projesini başlattı. JSONx projesi, kuruluş için özel olarak oluşturulmuştur ve XML şema belirtimine yakın olarak modellenen JSON şema tanımlama (JSD) dilini tanımlar. Model olarak XML şemasını kullanan JSD, XML şema tanımlama diline yakın benzerlik gösteren yapısal ve mantıksal kalıpları tanımlar.

Avrupa Bankası örneğinde, hesap tanımlayıcıları olan JSON mesajları için bir şema uygulamak üzere JSD dilini kullanalım.

 { "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 } } } }

İlk bakışta, JSD şeması, ifade olarak JSON şemasına benzer. Ancak bir fark, JSD'nin JSON şemasına kıyasla kısa semantiğidir. Bu örneğe özel olarak, JSD "use": "required" özelliğini belirtilen tanıma yerleştirirken, JSON şeması bu özelliği üst nesneyle ilişkilendirerek değerlerin adının özellik tanımının adıyla eşleşmesini gerektirir. "use": "required" kısıtlaması yalnızca "swift" nesnesinin "code" özelliğinde belirtilir ve varsayılan değer "use": "required" olduğundan diğerlerinden çıkarılır. JSD dili, bu tür tüm nüanslar göz önünde bulundurularak tasarlanmıştır ve JSON şemalarının ifadesi için temiz ve sezgisel bir çözüm sunar.

Başlangıçtan itibaren, JSONx projesinin ayırt edici bir özelliği, geliştiricilere netlik ve fayda sağlamak için birincil amacıdır. Bunu başarmak için JSD'nin güçlü bir özelliği, JSDx'e dönüştürülebilir olmasıdır; JSD dili, XML dosyalarında olduğu kadar JSON dosyalarında da ifade edilebilir. Her iki form da bire bir çevrilebilir ve geliştiricilere, canlı olarak doğrulanacak ve hatasız olacak şekilde JSD belgelerinin oluşturulmasına yardımcı olmak için gelişmiş XML düzenleme araçlarını kullanma yeteneği sağlar.

Yukarıdaki JSD şeması, aşağıdaki JSDx biçiminde ifade edilebilir:

 <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>

JSD'nin JSDx formu güçlüdür çünkü JSON şemalarını tanımlamak için açık, kendi kendini doğrulayan ve riski azaltılmış bir belirtim sağlar.

JSD dili, kendi içinde çelişen tanımların endişelerini gidermek için tasarlanmıştır ve kısıtlamaların ifadesi için standart kalıplara dayanır. XML şema tanımlama (XSD) diline çok benzer şekilde tasarlanan JSD tipi bildirimler ve kısıtlama tanımları, XML'deki eşdeğer yapılara çok benzer. JSD(x) belirtimi, yapısal ve mantıksal kısıtlamaların tanımı için eksiksiz bir çözüm sağlar ve kendi kendini açıklar—JSD(x) dilinde ifade edilen JSD(x) dilinin normatif bir tanımını sağlar. JSD(x) belirtimine daha yakından bakmak için JSON Schema Definition Language bölümüne bakın.

JSD(x) diline ek olarak, JSONx projesi, Java platformu için bir sınıf bağlama API'si ve kod oluşturucunun yanı sıra JSD(x) işlemcilerinin ve doğrulayıcılarının referans uygulamalarını sağlar. Bağlama API'si ve oluşturucu ile bir geliştirici, istenen şemadaki nesne tanımları için otomatik olarak sınıflar oluşturmak üzere bir JSD(x) şeması kullanabilir; bu şemaya uyan JSON belgelerini ayrıştırmak ve sıralamak için kullanılabilir. Oluşturulan sınıflar, şema ile Java platformu arasında, şemada belirtilen kullanımı, kısıtlamaları ve ilişkileri temsil eden güçlü bir şekilde yazılmış bir bağlama sağlar. Şemaya güçlü bir şekilde yazılan bağlamalarla uygulama, uyumsuzluklara neden olabilecek gelecekteki değişikliklerle ilgili yazılım riskini daha da azaltır.

Java'nın derleyicisinden yararlanarak, güçlü bir şekilde yazılan bağlamalar, derleme zamanı hatalarıyla uyumsuzlukları tam olarak belirleyerek mesaj işlemeyle ilgili hata riskini sıfıra yakın bir şekilde azaltır. Bu mühendislik modeli, geliştiricilerin, hataları veya başarısızlık durumlarını bulmak için çalışma zamanına güvenmek zorunda kalmadan ve özellikle de hataların kendilerine rastlamak için kullanıcılara güvenmek zorunda kalmadan, değişiklikleri uygulamasına ve uyumsuzlukları hızlı ve güvenli bir şekilde çözmesine olanak tanır. Bağlama API'si, herhangi bir sınıfın güçlü türlerle ancak hafif bir şekilde bir JSD(x) şemasına bağlanmasına izin veren Java ek açıklamalarıyla uygulanır. JSONx'in kesin olarak belirlenmiş bağlama ve kod oluşturma yetenekleri, kurumsal çözümler için yüksek standartları karşılamak üzere özel olarak tasarlanmış JSD(x) belirtiminin tam kapsamını destekler.

JSONx çerçevesi, kurumsal çözümler için oluşturulmuştur ve karmaşık sistemler için yüksek bir kalite standardı ve faydanın yanı sıra geliştiriciler için kullanım kolaylığı ve düzenleme zamanı hata doğrulaması sunar.

JSD(x) bağlama motoru, işlemci ve doğrulayıcı %87 test kapsamı bildirerek Java geliştiricilerinin JSD(x) şemalarını Java uygulamalarına bağlamak ve JSON belgelerini kodlamak, kodunu çözmek ve doğrulamak için çerçeveyi güvenle entegre etmelerine olanak tanır. Java için JSONx çerçevesine daha yakından bakmak için Java için JSONx Çerçevesine bakın.

Çözüm

Web'in tarihine ve son yıllardaki yazılım trendlerine daha derin bir bakışla, JavaScript'in yaygınlaşması ile JSON'un popülaritesi arasında yakın bir ilişki görebiliriz. Pek çok makale ve blog gönderisi, JSON ve XML'i karşılaştırırken sınırlı bir bakış açısı sunar, bu da okuyucuları XML'i modası geçmiş olarak indirim yapmaya yönlendirir ve birçoğunu yazılımlarının mimarisini, yazılımlarının değişime karşı direncini ve genel kalite ve genel kaliteyi iyileştirmelerine yardımcı olabilecek güçlü yeteneklerden habersiz bırakır. Yazılımın bir bütün olarak kararlılığı. Her standardın güçlü ve zayıf yönlerine ilişkin daha derin bir değerlendirmeyle geliştiriciler, projeleri için daha iyi kararlar alma yetkisine sahip olabilir.

XML'in icadına yol açan HTML ile "farklılık felaketi" gibi, benzer bir etki, veri alışverişi için JSON'a dayanan karmaşık kod tabanlarında gerçekleşir. JSON belirtimi, uygulamanın üst katmanlarında mantığın parçalanmasına yol açabilecek veri alışverişini çevreleyen acil işlevleri kapsamaz. Bununla birlikte, geliştiriciler XML ile, veri alışverişini çevreleyen karmaşıklığı uygulamanın alt katmanlarına taşıyarak, uygulamanın yaşam döngüsünde hataları daha erken yakalama becerisiyle sonuçlanabilir. Özellikle derlenmiş diller için, bir bağlama çerçevesiyle birlikte, XML bağlamaya dayanan mimariler, verilerle ilgili hata olasılığını sıfıra yakın azaltabilir. Kuruluş için, XML'i "bilgi işlemin kutsal kasesi" yapan, yazılım riskinin sistematik olarak azaltılmasındaki bu güçlü yeteneklerdir.

JSON kalıcıdır ve XML'in güçlü özelliklerini JSON'a sunmak için birkaç proje ivme kazanıyor. JSON şema projesi, JSON belgelerini tanımlamak ve sınırlamak için çok çeşitli öznitelikleri ve bildirim kalıplarını desteklemek için organik olarak büyüyen, topluluk tarafından geliştirilmiş bir şema belirtimi sunar. JSONx projesi, XML şema tanımlama diline çok benzer şekilde tasarlanmış kurumsal düzeyde bir şema dili sunar ve JSON şema belgelerinin belirtimi için hem JSON hem de XML biçimleri sunar. Bu spesifikasyonlar ve çerçeveler ile geliştiriciler, tüketici odaklı sözleşmeler, protokol versiyonlama, içerik doğrulama ve daha fazlası gibi veri alışverişini çevreleyen üst düzey gereksinimlerle ilgili yazılım riskini azaltabilir.

XML'in gelişmiş özellikleri, biçimlendirme dilleriyle ilgili yazılım riskini azaltmak için tasarlanmıştır. JSON ile kullanım durumları farklı değildir ve şema dili, veri alışverişini çevreleyen çok çeşitli yazılım risklerinden sistematik olarak korunmak için zaman içinde test edilmiş ve kanıtlanmış bir çözümdür.

Referanslar

1. JSON ve XML (w3schools.com, Aralık 2016)

2. Dünya Çapında Başarı Olan XML (W3C, Temmuz 2018)

3. W3C - XML ​​Şeması Nedir? (W3C, Ekim, 2009)

4. İnternet: Tarihsel Bir Ansiklopedi. Kronoloji, Cilt 3, s. 130 (ABC-CLIO, 2005)

5. JSON Şeması (Temmuz 2008)

6. JSON Şema Doğrulayıcı (GitHub)

7. JsonSchema ve Alt Sınıflandırma (Horne, Mart 2016)