İçeriğe geç
Toova
Tüm Araçlar

JSON vs YAML — Hangisi Ne Zaman Kullanılır

Toova

JSON ve YAML, yapılandırılmış verileri metin olarak temsil etmenin iki yoludur. Her ikisi de dizgileri, sayıları, boolean'ları, dizileri ve iç içe nesneleri destekler. Her ikisi de tüm programlama dilleri ve platformlarda yaygın olarak desteklenir. Yine de çok farklı ödünleşmeler yaparlar: JSON makine okunabilirliği ve ayrıştırma hızı için optimize edilirken, YAML insan okunabilirliği ve ifade edici yapılandırma için optimize edilir. Hangisine başvuracağınızı bilmek, API'ler için tasarlanmış bir yapılandırma formatını el yazısı yapılandırma dosyaları yazmak için kullanmaktan veya tersinden gelen sürtüşme türünü önler.

Bu kılavuz sözdizimi farklılıklarını, her formatın pratik güçlü ve zayıf yönlerini, formata bağlı gerçek dünya araç seçimlerini, performans değerlendirmelerini ve 2026 için net bir karar çerçevesini kapsar.

JSON: Genel Bakış

JSON (JavaScript Object Notation), 2000'lerin başında Douglas Crockford tarafından resmileştirildi ve RFC 8259 ve ECMA-404'te standartlaştırıldı. Tasarım hedefi, karmaşık bir ayrıştırıcı gerektirmeden herhangi bir programlama dili tarafından ayrıştırılabilen ve seri hale getirilebilen minimal, belirsizliği olmayan bir formattı.

JSON tam olarak altı veri türünü destekler: dizgiler (her zaman çift tırnaklı), sayılar, boolean'lar (true/false), null, nesneler (dizgi anahtarlı anahtar-değer eşlemeleri) ve diziler (sıralı listeler). Yorum yok, tarih türü yok, ikili tür yok, başvuru yok. Bu minimalizm kasıtlıdır: katı kurallar belirsizliği ortadan kaldırır ve ayrıştırıcıları basit ve hızlı yapar. 

{
  "name": "deploy-service",
  "version": "2.1.0",
  "environment": "production",
  "replicas": 3,
  "enabled": true,
  "tags": ["backend", "critical"],
  "resources": {
    "cpu": "500m",
    "memory": "512Mi"
  }
}

Her anahtar çift tırnak içinde tırnaklanmalıdır. Sondaki virgüller izin verilmez. Yorum yazmanın bir yolu yoktur. Dizgiler yeni satır karakterini kaçırmadan birden fazla satıra yayılamaz. Bu kısıtlamalar JSON'u elle yazmayı zorlaştırır ancak kodtan üretmeyi ve alıcı tarafta ayrıştırmayı önemsiz derecede kolay yapar.

YAML: Genel Bakış

YAML (YAML Bir İşaretleme Dili Değildir), 2001'de Clark Evans, Ingy dot Net ve Oren Ben-Kiki tarafından tasarlandı. JSON uyumluluğunu sağlayan 1.2 sürümü 2009'da sonlandırıldı. YAML'in tasarım hedefi, geliştiricilerin yeni bir sözdizimi öğrenmeden doğrudan metin düzenleyicilerde yazabilecekleri insan tarafından okunabilir bir veri formatıdır. Tam şartname yaml.org'da bulunur.

YAML, yapıyı ifade etmek için parantezler yerine girintilemeyi kullanır. Listeler tire kullanır. Anahtarlar varsayılan olarak tırnaksızdır. Yorumlar # ile başlar. Özel karakterler içermedikçe dizgiler tırnak gerektirmez. Çok satırlı dizgilerin özel blok skaler sözdizimi vardır. 

# Üretim için dağıtım yapılandırması
name: deploy-service
version: 2.1.0
environment: production
replicas: 3
enabled: true

tags:
  - backend
  - critical

resources:
  cpu: 500m
  memory: 512Mi

YAML'de ifade edilen aynı veri yapısı önemli ölçüde daha kısa ve daha okunabilirdir — özellikle yorumlar veya iç içe listeler içerdiğinde. Ödün, YAML'in ayrıştırıcısının önemli ölçüde daha fazla karmaşıklığı ele alması gerektiğidir: girintileme duyarlılığı, aynı türü ifade etmenin birden fazla yolu, çapalar, takma adlar, birleştirme anahtarları ve belirsiz boolean yorumunun tarihsel mirası.

Yan Yana Sözdizimi Karşılaştırması

Çok satırlı dizgiler

Çok satırlı dizgiler, yapılandırma dosyaları için YAML'in en açık avantajlarından biridir. YAML iki blok skaler stilini sağlar: literal (|) yeni satırları tam olarak korur ve katlanmış (>) uzun düzyazı için satırları boşluklarla birleştirir. 

# YAML: çok satırlı dizgi yazmanın birden fazla yolu
# Literal blok (yeni satırları korur)
description: |
  Bu birinci satırdır.
  Bu ikinci satırdır.
  Sonda yeni satırlı son satır.

# Katlanmış blok (yeni satırlar boşluk olur, uzun düzyazı için iyi)
summary: >
  Bu uzun paragraf birden fazla
  satırda yazılmıştır ancak tek bir
  boşlukla ayrılmış dizgiye birleştirilecektir.

# JSON'da yeni satırları kaçırmanız gerekir
# "description": "Bu birinci satırdır.
Bu ikinci satırdır.
Son satır."

Çapalar ve takma adlar

YAML çapaları (&) ve takma adlar (*) bir değişkene benzer şekilde, bir değeri bir kez tanımlamanıza ve birden fazla yerde başvurmanıza olanak tanır. Birleştirme anahtarı (<<) bir eşlemenin içeriğini başka birine birleştirir ve bir tür miras sağlar. 

# YAML çapaları ve takma adları çoğaltmayı azaltır
defaults: &defaults
  timeout: 30
  retries: 3
  log_level: info

development:
  <<: *defaults   # defaults'u birleştir
  log_level: debug

staging:
  <<: *defaults
  timeout: 60

production:
  <<: *defaults

JSON'un eşdeğeri yoktur. JSON'da, tekrarlayan yapılandırma çoğaltılmalı, bir şablonlama katmanı tarafından ele alınmalı veya tüketen uygulamanın mantığı tarafından yönetilmelidir. YAML çapaları insan tarafından bakılan yapılandırmalar için güçlüdür ancak dosyaları kuralla tanışık olmayan okuyucular için anlamayı zorlaştırabilir.

Güçlü ve Zayıf Yönler

JSON güçlü yönler

  • Belirsizliği olmayan ayrıştırma — gramer tek bir sayfada belirtilebilecek kadar basittir. Her ayrıştırıcı belirli bir girdi için aynı sonucu üretir.
  • Hız — JSON ayrıştırıcıları var olan en hızlı metin ayrıştırıcıları arasındadır. V8, JSON'u JavaScript'in kendisinin yürüttüğünden önemli ölçüde daha hızlı ayrıştırır.
  • Yerel JavaScript desteği — JSON.parse() ve JSON.stringify() her JavaScript çalışma zamanına yerleşiktir. Hiçbir bağımlılık gerekmez.
  • Evrensel araçlar — her API istemcisi, veritabanı ve veri hattı JSON'u yerel olarak konuşur. Fiili API formatıdır.
  • Girintileme duyarlılığı yok — boşluk anlam için önemsizdir, bu da JSON'u düzenleyiciler, işletim sistemleri ve araçlar arasındaki biçimlendirme farklarına karşı sağlam yapar.

JSON zayıf yönler

  • Yorum yok — bir yapılandırma değerini satır içinde açıklayamazsınız. Bu, el yazısı dosyalar için önemli bir acı noktasıdır.
  • İnsanlar için ayrıntılı — tüm anahtarlar tırnaklanmalı, virgüller her öğeyi ayırmalı ve parantezler her nesneyi ve diziyi çevrelemelidir.
  • Sondaki virgül hataları — son dizi veya nesne öğesinden sonraki sondaki virgüller geçersizdir ve elle düzenlerken eklemesi kolay ayrıştırma hatalarına neden olur.
  • Çok satırlı dizgi yok — gömülü yeni satırları olan bir dizgiyi temsil etmek \n kaçırma gerektirir, bu da SQL sorguları veya shell betikleri gibi şeyleri gömmeyi acılı yapar.
  • Tarih türü yok — tarihler dizgilerdir. Kurallar değişir (ISO 8601, Unix zaman damgaları, özel formatlar) ve uygulama tarafından ele alınmalıdır.

YAML güçlü yönler

  • Yorumlar — # yorum sözdizimi, YAML'i satır içi belgeleme gerektiren yapılandırma dosyaları için belirgin seçim yapar.
  • Okunabilirlik — daha az sözdizimsel gürültü. Tırnaksız anahtarlar, virgüller yok, insanların ana hatları yazma şeklini yansıtan girintileme tabanlı yapı.
  • Çok satırlı dizgiler — literal ve katlanmış blok skalerler uzun dizgileri kaçırma olmadan zarif bir şekilde ele alır.
  • Çapalar ve birleştirme anahtarları — büyük yapılandırma dosyalarındaki çoğaltmayı azaltır.
  • Zengin tür sistemi — YAML ayrıştırıcıları açık tür açıklamaları olmadan değer formatından türleri çıkarır (dizgiler, tamsayılar, ondalıklar, boolean'lar, null, zaman damgaları).

YAML zayıf yönler

  • Karmaşıklık — tam YAML şartnamesi çok büyüktür. Uç durumlar boldur: Norveç sorunu, örtük tür dönüştürme sürprizleri, sekme-vs-boşluk duyarlılığı.
  • Yavaş ayrıştırma — YAML ayrıştırıcıları gramerin karmaşıklığı nedeniyle JSON ayrıştırıcılarından önemli ölçüde daha yavaştır.
  • Girintileme hataları — tek bir hizalı olmayan satır, ayrıştırma hatası üretmeden belgenin anlamını değiştirir ve fark etmesi zor ince hatalar yaratır.
  • Norveç sorunu — YAML 1.1'de, çıplak NO boolean false olarak ayrıştırır. Ülke kodları, kısaltmalar ve birçok İngilizce sözcük YAML 1.1 ayrıştırıcılarında (hâlâ yaygın) beklenmedik boolean yorumlarına sahiptir.
  • Tutarsız ayrıştırıcı davranışı — farklı dillerin YAML ayrıştırıcıları şartnamenin farklı alt kümelerini veya farklı sürümlerini uygular, taşınabilirlik sorunlarına yol açar.

JSON Ne Zaman Kullanılır

API yanıtları ve istekleri

JSON, REST API'leri için evrensel formattır. Her HTTP istemci kütüphanesi onu yerel olarak seri hale getirebilir ve seri durumdan çıkarabilir. API ölçeğinde ayrıştırma hızı önemlidir ve JSON'un belirsiz olmayan grameri, her istemcinin ve sunucunun aynı veriyi özdeş şekilde ayrıştırması anlamına gelir. GraphQL yanıtları JSON'dur. OpenAPI/Swagger tanımları JSON'dur (YAML de kabul edilir). Bir API tasarlıyorsanız, JSON'u varsayılan olarak seçin. 

{
  "user": {
    "id": 42,
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "createdAt": "2026-01-15T10:30:00Z"
  }
}

Kod tarafından üretilen yapılandırma

Bir program yapılandırma ürettiğinde — bağımlılık kilit dosyaları üreten bir derleme aracı, bir proje manifestosu üreten bir çerçeve, sağlama toplamlarını kaydeden bir dağıtım aracı — JSON doğru formattır. Çıktının elle yazılması gerekmez, yoruma gerek yoktur ve JSON'un belirsiz olmayan grameri tüketen kodun tam olarak üretilen şeyi ayrıştırmasını sağlar. package.json, tsconfig.json, package-lock.json ve composer.json'un hepsi bu desenin örnekleridir.

Hizmetler arası veri değişimi

İki hizmetin veri alışverişi yapması gerektiğinde — mesaj kuyrukları, webhook'lar, olay akışları — JSON'un hızı, evrenselliği ve belirsizliği olmaması onu doğru seçim yapar. YAML'in faydaları (yorumlar, çok satırlı dizgiler) otomatik veri hatlarında alakasızdır. Hata ayıklama sırasında yükleri incelemek için JSON Formatter'ı ve bir yükü belgeleme amacıyla insan tarafından okunabilir hale getirmeniz gerekiyorsa JSON to YAML dönüştürücüyü kullanın.

Veritabanlarında depolama

PostgreSQL, MongoDB, MySQL ve yapılandırılmış veri depolayan çoğu veritabanı bunu JSON veya JSON uyumlu formatlarda yapar. YAML herhangi bir büyük veritabanında desteklenen bir depolama formatı değildir. Bir veritabanında yapılandırma veya yapılandırılmış veri depoluyorsanız, JSON kullanın.

YAML Ne Zaman Kullanılır

Altyapı ve dağıtım yapılandırması

Kubernetes manifestleri, Helm grafikleri, Docker Compose dosyaları ve Ansible playbook'larının hepsi YAML kullanır. Bu dosyalar insanlar tarafından yazılır ve incelenir, genellikle açıklayıcı yorumlar içerir ve kaynak kümelerini açıklamak için YAML'in okunabilir liste sözdiziminden yararlanır. Birden fazla konteyner, hacim bağlantısı ve ortam değişkeni olan bir Kubernetes Deployment'i YAML'de JSON'dan önemli ölçüde daha kolay okunur.

CI/CD ardışık düzen tanımları

GitHub Actions, GitLab CI, CircleCI ve Bitbucket Pipelines'ın hepsi ardışık düzen tanımları için YAML kullanır. Ardışık düzen yapılandırmaları insanlar tarafından yazılır, sıkça yorumlanır ve YAML'in okunabilir sözdiziminden yararlanan çok adımlı mantık içerir. 

# GitHub Actions iş akışı — YAML doğal uyum
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Testleri çalıştır
        run: npm test

Uygulama yapılandırma dosyaları

Django ayarları (django-configurations aracılığıyla), Ruby on Rails database.yml, Gatsby yapılandırması ve diğer birçok çerçeve yapılandırmaları için YAML kullanır. Geliştiricilerin bir yapılandırma dosyasını kodun yanında okuması ve anlaması gerektiğinde, YAML'in yorumlar ve çok satırlı açıklamalar içerme yeteneği bilişsel yükü azaltır.

Belgeleme verileri

Jekyll, Hugo ve Eleventy gibi statik site üreteçleri içerik dosyalarında YAML ön maddesi kullanır. YAML meta verilerinin ve Markdown gövde içeriğinin kombinasyonu yaygındır çünkü YAML'in okunabilir anahtar-değer sözdizimi bir metin belgesinin üstüne doğal olarak uyar. JSON ön maddesi vardır ancak nadiren tercih edilir.

Performans

Veri işleme hatları için, seri hale getirme kıyaslamaları sürekli olarak JSON'un eşdeğer veri için YAML'den 5-10 kat daha hızlı ayrıştırıldığını gösterir. 1 MB'lık bir dosyada V8 JSON.parse() çağrısı birkaç milisaniyede tamamlanır. Eşdeğer YAML ayrıştırması onlarca milisaniye sürer. Saniyede binlerce istek işleyen bir web sunucusu için bu fark önemlidir. Başlangıçta bir kez bir yapılandırma dosyası okuyan bir CLI aracı için değildir.

Performans birincil endişenizse ve yüksek verimli bir veri formatı için JSON ve YAML arasında seçim yapıyorsanız, JSON sorgusuz kazanır. Daha hızlı ayrıştırmaya ihtiyacınız varsa, hizmetler arası iletişim için MessagePack veya Protocol Buffers gibi ikili formatları düşünün.

Güvenlik Değerlendirmeleri

YAML ayrıştırıcıları JSON ayrıştırıcılarından daha karmaşıktır ve daha büyük bir saldırı yüzeyine sahiptir. En önemli risk YAML seri durumdan çıkarma yoluyla rastgele kod yürütmedir. Python'un PyYAML'inde (safe_load varsayılan olarak zorunlu kılınmadan önce), varsayılan yaml.load() fonksiyonu ile güvenilmeyen YAML yüklemek YAML'e gömülü rastgele Python kodunu yürütebilirdi. PHP ve Ruby YAML ayrıştırıcılarının benzer güvenlik açıkları olmuştur.

Kural: güvenilmeyen YAML'i ayrıştırırken her zaman güvenli yükleme kullanın. Python'da, Loader argümanı olmadan yaml.load() değil, yaml.safe_load() kullanın. Java'da, izin verilen türleri kısıtlamak için yapıcıyı yapılandırın. Ruby'de, YAML.load() yerine YAML.safe_load() kullanın.

JSON ayrıştırıcılarının bu güvenlik açığı yoktur çünkü JSON'un tür sisteminin yürütülebilir değerler kavramı yoktur. Bir JSON ayrıştırıcısı yalnızca dizgiler, sayılar, boolean'lar, null, diziler ve nesneler üretebilir — asla kod. Güvenilmeyen kullanıcı verisini işlemek için, JSON ayrıştırmak doğal olarak daha güvenlidir.

JSON ile YAML Arasında Dönüştürme

Formatlar en yaygın veri türleri için anlamsal olarak uyumludur. Veri YAML'a özgü özellikleri (çapalar, özel türler, blok skalerler) kullanmadığında aralarında dönüştürmek basittir. API yanıtlarını veya kilit dosyalarını belgeleme veya hata ayıklama için okunabilir YAML'a dönüştürmek için JSON to YAML dönüştürücüsünü kullanın. YAML yapılandırmayı JSON yerel araçlara veya API'lere beslemek için YAML to JSON dönüştürücüsünü kullanın. Her iki araç da tarayıcıda çalışır — verileriniz cihazınızdan asla çıkmaz.

JSON Formatter, dönüşümden önce JSON yapısını incelemek ve doğrulamak için kullanışlıdır. Formatlar arasında sık hareket eden yapılandırmayla çalışıyorsanız — örneğin, bir API çağrısı için seri hale getirilmesi gereken Kubernetes manifestleri — her iki dönüştürücüyü de yer imlerinde tutmak zaman kazandırır.

Karar Çerçevesi

  • Bir REST API yanıtı veya isteği mi yazıyorsunuz? JSON.
  • Kubernetes, Docker Compose veya Ansible'ı mı yapılandırıyorsunuz? YAML.
  • Bir CI/CD ardışık düzeni mi yazıyorsunuz? YAML.
  • Bir veritabanında veri mi depoluyorsunuz? JSON.
  • Yorumlarla insan tarafından düzenlenebilir bir yapılandırma dosyası mı yazıyorsunuz? YAML.
  • Yapılandırmayı kodtan programatik olarak mı üretiyorsunuz? JSON.
  • Güvenilmeyen kullanıcı girdisini mi işliyorsunuz? JSON (daha güvenli ayrıştırıcı).
  • Yüksek verimli veri hattı mı? JSON (veya ikili format).
  • Zaten tutarlı bir şekilde bir format kullanan bir proje mi? Mevcut kuralla eşleşin.

Şüpheniz olduğunda, en önemli faktör dosyayı okuyacak ve yazacak insanlardır. Dosya esas olarak makine tarafından üretilir ve makine tarafından tüketilirse, JSON'un basitliği kazanır. İnsanlar onu okuyacak, düzenleyecek ve netliğini önemseyecekse, YAML'in ifade ediciliği ek ayrıştırıcı karmaşıklığına değer.