JSON 2001'de tanıtıldığında yaygın beklenti belliydi: XML'in günleri sayılıydı. Yirmi yılı aşkın bir süre sonra sitemap dosyaları hâlâ XML ile yazılıyor, SOAP servisleri XML tabanlı çalışıyor, Android uygulama bildirimleri XML formatında saklanıyor. "Hangisi daha iyi?" sorusu yanlış sorudur. Doğru soru şudur: hangi bağlamda hangisi daha uygun?
Fark salt boyut ya da sözdizimi değil; her iki formatın farklı bağlamlarda sergilediği teknik davranış farkıdır. Kazananı ilan etmek yerine bu davranış farklarını somutlaştırmak daha yararlı.
Sözdizimi farkı ve neden önemli
Aynı veriyi her iki formatta yazmak farkı somutlaştırır. Bir kullanıcı kaydını düşünelim:
{
"kullanici": {
"ad": "Ahmet",
"yas": 32,
"roller": ["admin", "editor"]
}
}Aynı veri XML'de şöyle görünür:
<kullanici>
<ad>Ahmet</ad>
<yas>32</yas>
<roller>
<rol>admin</rol>
<rol>editor</rol>
</roller>
</kullanici>XML her değeri açılış ve kapanış etiketiyle sarıyor. Bu "gürültü" yalnızca görsel değil; gerçek bir boyut farkı üretiyor. JSON'da veri tipi doğrudan ifade edilir: 32 sayıdır, "Ahmet" string'dir, köşeli parantez dizidir. XML'de tüm değerler metin olarak saklanır; veri tipi yorumu alıcı tarafa bırakılır.
XML'in sözdizimi karmaşıklığı bir dezavantaj olarak görünse de attribute mekanizması sayesinde meta veri taşımayı kolaylaştırır:
<kullanici aktif="true" rol="admin">
<ad>Ahmet</ad>
</kullanici>JSON'da bu ayrımı modellemenin doğrudan bir yolu yoktur. Attribute'u ya iç içe nesneyle ya da ayrı bir alan olarak temsil etmek gerekir.
Boyut ve ağ maliyeti
JSON genellikle eşdeğer XML verisinin %30-50'si boyutundadır. Bu fark küçük payload'larda göz ardı edilebilirken yüzlerce kayıt döndüren API yanıtlarında ölçülebilir bir bant genişliği ve parse süresi farkı yaratır.
Sayıyı somutlaştırmak gerekirse: 10.000 ürün kaydı içeren bir katalog yanıtı JSON ile 800 KB iken XML ile 1.3 MB'ı geçebilir. CDN veya mobil bağlantı senaryolarında bu fark belirginleşir. Gzip sıkıştırma farkı bir miktar kapatır çünkü XML'in tekrarlayan etiket yapısı sıkıştırmaya daha kolay yenik düşer; ancak sıkıştırılmış boyutlarda bile JSON avantajını korur.
Parse maliyeti de boyut farkını destekler. Tarayıcılar ve Node.js dahil yaygın çalışma ortamları JSON'u native JSON.parse() ile işler; platformun C++ katmanı devreye girer, ek kütüphane gerekmez. XML için tablo farklıdır: DOM parser tüm belgeyi belleğe alır ve ağaç yapısı kurar; birkaç MB boyutundaki yanıtlarda bu bellek baskısı ölçülebilir hale gelir. SAX streaming ile belleği korur ancak olay tabanlı API yazım ve bakım maliyeti getirir. Küçük payload'larda bu fark pratik sonuç üretmez; 10.000+ kayıtlık katalog yanıtlarında bellek kullanımı kıyaslaması DOM parser aleyhine döner.
Payload boyutunu daha da küçültmek için gereksiz boşlukları kaldırmak gerektiğinde boyutu küçültmek amacıyla minify işlemi uygulanabilir; bu hem JSON hem XML için geçerlidir.
XML'in hâlâ geçerli olduğu alanlar
XML'in salt tarihsel bir format olduğu yanılgısı yaygındır. Bazı alanlar XML'e teknik nedenle bağımlıdır.
Sitemap: Google'ın sitemap protokolü XML tabanlıdır. JSON sitemap geçersizdir.
RSS ve Atom: Haber beslemeleri, podcast dağıtımı ve içerik aboneliği akışları bu iki XML formatı üzerinde çalışır.
SOAP web servisleri: Kurumsal sistemlerin büyük bölümü SOAP üzerinden iletişim kurar. SOAP zarfı tanımı gereği XML'dir.
Office Open XML: .docx, .xlsx, .pptx dosyaları ZIP içinde paketlenmiş XML belgelerinden oluşur.
SVG ve XHTML: Her ikisi de XML tabanlı biçimlerdir.
Android Manifest: Android uygulama yapılandırması AndroidManifest.xml dosyasında saklanır.
Bu listenin ortak noktası şudur: XML belge veya yapılandırma formatı olarak seçildiğinde yerini korur. REST API ve veri iletiminde ise tercih büyük ölçüde JSON'a kaymıştır.
Şema ve doğrulama: hangisi daha güçlü?
Veri yapısını tanımlamak ve gelen veriyi doğrulamak için her iki formatın kendi şema mekanizması vardır. XML Schema Definition (XSD) onlarca yıllık olgunlukla çok güçlüdür: veri tipi kısıtlamaları, namespace tanımları, karmaşık kalıtım yapıları ve birden fazla şema dosyasının birleşimi XSD ile mümkündür. Araç desteği geniş; WSDL tabanlı SOAP servislerinde şema doğrulama zorunlu bir katman olarak yerleşmiştir.
JSON Schema daha genç bir standarttır. Temel tip ve format kısıtlamalarını, required alanları, enum sabitlerini ve iç içe nesne yapılarını modelleyebilir. Ancak XSD'nin namespace desteği veya karmaşık kalıtım mekanizmaları JSON Schema'da yoktur ya da önemli ölçüde sınırlıdır.
Namespace çakışması XML'e özgü bir pratik sorundur. İki farklı sistemden gelen XML belgelerini birleştirirken aynı etiket adı farklı anlamlara gelebilir; xmlns: önekleriyle ayrıştırma zorunlu hale gelir. Büyük kurumsal entegrasyonlarda on farklı kaynaktan veri birleştiren bir pipeline'da namespace yönetimi başlı başına bir bakım yüküne dönüşür. JSON bu sorunu doğası gereği yaşamaz; nesne anahtarları bağlamsal olarak izole edilmiştir ve harici namespace referansına gerek duymaz.
Katı veri sözleşmesi gerektiren kurumsal entegrasyonlarda XML + XSD kombinasyonu hâlâ daha güvenilir bir temel sunar. Hareket hızı ve basitlik ön plandaysa JSON Schema yeterlidir. JSON yapılarını doğrulamak, biçimlendirmek veya hataları tespit etmek için yapıyı analiz eden bir araç kullanmak süreci hızlandırır.
Yorum satırı meselesi
JSON'un spesifikasyonunda yorum satırı yoktur. Bu tasarım kararı —Doug Crockford'un bilinçli bir seçimiydi— config dosyası kullanım senaryolarında ciddi bir sürtünme noktasına dönüşür. Örneğin package.json'a yorum eklemek geçersiz JSON üretir.
XML'de <!-- ... --> sözdizimi yerleşik ve geçerlidir. Karmaşık yapılandırma dosyalarında açıklama satırları bakım maliyetini düşürür; yeni geliştiricinin bağlamı dosyadan anlayabilmesi için zorunlu olabilir.
Pratik tabloya bakıldığında JSON config formatı olarak hâlâ yaygın: package.json, tsconfig.json, .eslintrc.json, launch.json gibi dosyalar milyonlarca projede JSON kullanıyor. Tooling ekosistemi bunu desteklediği için format değişmiyor; ama bu dosyalara yorum eklemek istediğinizde seçenekler kısıtlanır. VSCode gibi editörler jsonc (JSON with Comments) desteği sunuyor; ancak bu standart JSON değil, araç-özel bir uzantıdır. Standart JSON parser'lar jsonc dosyasını hata verir. Yorum gereksiniminiz varsa ve tooling'iniz zorunlu tutmuyorsa YAML daha az sürtünme üretir. JSON'u config dosyası olarak kullanmak teknik olarak mümkün, ancak yorum ihtiyacı arttıkça bakım maliyeti de artar.
Bu gerçek bir format sorunu değil; kullanım senaryosu uyumsuzluğudur. JSON veri iletimi için tasarlandı, config formatı olarak sonradan adapte edildi.
Seçim için pratik çerçeve
Format seçimini beş soruya indirgemek mümkündür:
| Senaryo | Öneri | Neden |
|---|---|---|
| Protokol zorunlu mu? (Sitemap, SOAP, RSS) | XML | Spesifikasyon dışına çıkma seçeneği yoktur; JSON sitemap geçersizdir |
| REST API | JSON | Browser native desteği, tarayıcı ve mobil istemci ekosistemi JSON bekler |
| Katı şema + namespace + kurumsal entegrasyon | XML + XSD | Onlarca yıllık araç olgunluğu ve WSDL tabanlı doğrulama katmanı |
| Mobil veya yüksek trafikli API | JSON | %30-50 boyut farkı ve native parse maliyeti avantajı |
| Config dosyası + yorum gereksinimi | YAML veya TOML | JSON yorum satırını spesifikasyon gereği desteklemez; jsonc standart dışıdır |
Mevcut sistemin formatını değiştirmek ayrı bir maliyet hesabı gerektirir. JSON API üretmek için XML tabanlı bir backend'i yeniden yazmak, yalnızca format tercihinden büyük bir mühendislik kararına dönüşür. JSON sözdiziminin çalışma mantığını anlamak, bu geçişin teknik riskini daha net görmeyi sağlar.
İki format bir arada var olmayı sürdürecek. Web API'leri JSON, belge tabanlı sistemler ve protokoller ise XML ekosistemiyle yaşamaya devam edecek. Önemli olan hangi formatin "kazandığını" bilmek değil; projenin bağlamına göre hangisinin daha az sorun ürettiğini doğru okumaktır.