JSON چیست و چطور داده‌ها را در وب ساختاردهی می‌کند؟ راهنمای جامع و عملی

اولین باری که با یک پاسخ JSON از یک API مواجه شدم، به‌نظرم فقط یک فرمت متنی ساده آمد. اما وقتی فهمیدم همان چند خط، تفاوت بین یک API قابل کش و یک پاسخ درهم‌ریخته است، نگاهم عوض شد. JSON (JavaScript Object Notation) امروز ستون فقرات تبادل داده در وب است؛ از درخواست‌های یک اپلیکیشن موبایل گرفته تا ذخیره تنظیمات در فایل‌های پیکربندی، از پاسخ‌های REST API تا داده‌های تو‌در‌توی NoSQL. در این مقاله از نگاه کسی که سال‌ها با APIها، پایگاه‌های داده و سرویس‌های وب کار کرده، می‌خواهم هم مبانی JSON را باز کنم و هم نکاتی را بگویم که معمولاً در مستندات رسمی پیدا نمی‌شوند.

JSON دقیقاً چیست و از کجا آمد؟

JSON مخفف JavaScript Object Notation است؛ یک فرمت سبک برای تبادل داده که در سال ۲۰۰۱ توسط داگلاس کراکفورد معرفی شد. ایده اصلی ساده بود: به‌جای فرمت‌های پیچیده‌ای مثل XML که حجم زیادی از تگ‌های تکراری دارند، از ساختاری استفاده کنیم که هم برای انسان خوانا باشد و هم برای ماشین قابل‌تجزیه سریع. JSON در ابتدا زیرمجموعه‌ای از نحو زبان جاوااسکریپت بود، اما امروز یک استاندارد مستقل و زبان-خنثی است که تقریباً همه زبان‌های برنامه‌نویسی از آن پشتیبانی می‌کنند.

نکته‌ای که در تعریف رسمی کمتر به آن پرداخته می‌شود این است: JSON یک فرمت داده است، نه یک زبان برنامه‌نویسی. نمی‌توانید در آن حلقه بنویسید، شرط بگذارید یا تابع تعریف کنید. JSON فقط داده را توصیف می‌کند. این محدودیت عمدی، همان چیزی است که آن را امن و قابل پیش‌بینی می‌کند. اگر با مفاهیم پایه‌تر وب آشنایی ندارید، پیشنهاد می‌کنم ابتدا API چیست و چه کاربردهایی دارد را بخوانید تا جایگاه JSON در معماری ارتباطی روشن شود.

امروز JSON در جایگاه‌های متنوعی حضور دارد: پاسخ‌های REST API، فایل‌های پیکربندی مثل package.json و composer.json، ذخیره‌سازی داده در پایگاه‌های داده NoSQL مثل MongoDB، پیام‌های بین میکروسرویس‌ها، داده‌های ذخیره‌شده در localStorage مرورگر و حتی در فایل‌های manifest اپلیکیشن‌های موبایل. این گستردگی، نتیجه مستقیم سادگی و انعطاف JSON است.

JSON یک زبان مشترک است، نه یک زبان اختصاصی. همان‌قدر که انگلیسی زبان مشترک تجارت جهانی شد، JSON هم زبان مشترک داده در وب شد.

چرا JSON جای XML را گرفت؟

در دهه اول دهه ۲۰۰۰ میلادی، XML پادشاه تبادل داده بود. سرویس‌های SOAP، تنظیمات برنامه‌ها و حتی فایل‌های Office همگی از XML استفاده می‌کردند. اما XML یک مشکل اساسی داشت: پرحجم بودن. برای نشان دادن یک شیء ساده با دو فیلد، باید ده‌ها کاراکتر صرف باز و بسته کردن تگ‌ها می‌شد. در دنیای موبایل که پهنای باند و باتری محدود است، این حجم اضافه به یک بدهی فنی تبدیل می‌شد.

JSON این مشکل را با یک راه‌حل ساده حل کرد: حذف تگ‌های تکراری و استفاده از ساختاری که مستقیماً به ساختار داده در زبان‌های برنامه‌نویسی نگاشت می‌شود. یک object در JSON، در جاوااسکریپت هم object است، در پایتون dict و در PHP آرایه انجمنی. این نگاشت مستقیم، تجزیه را ساده و سریع می‌کند. اگر می‌خواهید بدانید XML امروز چه جایگاهی دارد، مقاله XML هنوز زنده است را ببینید.

دلیل دوم محبوبیت JSON، پشتیبانی بومی جاوااسکریپت است. مرورگرها از سال ۲۰۰۹ متد JSON.parse() و JSON.stringify() را در هسته زبان قرار دادند. این یعنی هر توسعه‌دهنده وب، بدون نیاز به کتابخانه اضافی، می‌تواند با JSON کار کند. در مقابل، XML نیازمند parserهای سنگین‌تر مثل DOM یا SAX بود. این سادگی، مسیر را برای ظهور AJAX و بعدها Fetch API هموار کرد. برای آشنایی با Fetch API، مقاله Fetch API در جاوااسکریپت را پیشنهاد می‌کنم.

دلیل سوم، خوانایی برای انسان است. حتی کسی که برنامه‌نویس نیست، می‌تواند ساختار یک فایل JSON را درک کند. این ویژگی در زمان اشکال‌زدایی ارزش فوق‌العاده‌ای دارد؛ می‌توانید پاسخ یک API را در مرورگر ببینید و بدون ابزار خاصی بفهمید چه داده‌ای برگشته. XML هم خوانا است، اما تگ‌های تکراری، این خوانایی را کاهش می‌دهند.

JSON به این دلیل برنده نشد که قوی‌تر بود؛ برنده شد چون ساده‌تر بود و سادگی، در دنیای فناوری همیشه برنده است.

ساختار و نحو JSON: اشیاء، آرایه‌ها، مقادیر

JSON از دو ساختار اصلی تشکیل شده است: object و array. یک object مجموعه‌ای از جفت‌های کلید-مقدار است که با آکولاد {} احاطه شده و کلیدها همیشه رشته هستند. یک array فهرست مرتبی از مقادیر است که با کروشه [] احاطه شده. ترکیب این دو ساختار، به شما اجازه می‌دهد هر نوع داده‌ای را مدل کنید؛ از یک رکورد ساده کاربر تا ساختارهای تو‌در‌توی پیچیده.

بیایید یک نمونه واقعی را با هم ببینیم. فرض کنید یک API پاسخ کاربر را به این شکل برمی‌گرداند:

{
  "id": 123,
  "name": "Ali Rezaei",
  "email": "ali@example.com",
  "is_active": true,
  "created_at": "2025-03-15T10:30:00Z",
  "roles": ["admin", "editor"],
  "profile": {
    "age": 32,
    "city": "Tehran",
    "avatar_url": null
  },
  "last_login": null
}

در این مثال می‌بینید که JSON چگونه انواع مختلف داده را در خود جای می‌دهد: عدد (id)، رشته (name)، بولین (is_active)، آرایه (roles)، object تودرتو (profile) و null (last_login). این انعطاف، دلیل اصلی محبوبیت JSON در مدل‌سازی داده‌های واقعی است.

نکات نحوی که حتماً باید رعایت شوند: کلیدها همیشه در گیومه دوتایی هستند (نه تک)، مقادیر رشته‌ای در گیومه دوتایی قرار می‌گیرند، کاما بین اعضا مجاز است اما کاما انتهایی (trailing comma) مجاز نیست، و کامنت در JSON پشتیبانی نمی‌شود. این محدودیت‌ها عمدی هستند تا تجزیه‌کننده‌ها ساده و سریع بمانند. اگر می‌خواهید کامنت داشته باشید، باید از فرمت‌هایی مثل JSON5 یا JSONC استفاده کنید که استاندارد رسمی نیستند.

نگاشت JSON به ساختارهای برنامه‌نویسی

یکی از دلایل محبوبیت JSON، نگاشت مستقیم آن به ساختارهای داده در زبان‌های مختلف است. یک object در JSON معادل‌های زیر را در زبان‌های مختلف دارد: در جاوااسکریپت object، در پایتون dict، در PHP آرایه انجمنی، در Ruby Hash، در Java Map و در C# Dictionary. به همین شکل، array در JSON معادل Array در جاوااسکریپت، list در پایتون و List در Java است.

این نگاشت، کار برنامه‌نویس را ساده می‌کند اما خطر پنهانی هم دارد: تفاوت در نوع داده. مثلاً عدد در JSON می‌تواند صحیح یا اعشاری باشد، اما در بسیاری زبان‌ها این دو نوع کاملاً جدا هستند. برای مثال، در زبان‌هایی مثل PHP که از type juggling استفاده می‌کنند، عدد ۱۰۰ می‌تواند در یک لحظه integer و در لحظه دیگر string درک شود. اگر API شما به نوع داده دقیق حساس است، باید در مستندات ذکر کنید که هر عدد، از چه نوعی است. برای درک عمیق‌تر کار با داده‌های ساختاریافته در PHP، مقاله کار با آرایه‌ها در PHP را ببینید.

انواع داده در JSON و محدودیت‌هایشان

JSON شش نوع داده دارد: string، number، boolean، null، object و array. همین سادگی، هم مزیت است و هم محدودیت. محدودیت اصلی این است که JSON مفهوم تاریخ، زمان، فایل باینری یا عدد با دقت بالا را به‌صورت بومی ندارد. هر کدام از این‌ها باید به یکی از شش نوع پایه نگاشت شوند.

رشته‌ها در JSON

رشته‌ها در JSON باید در گیومه دوتایی قرار بگیرند و از یونیکد پشتیبانی می‌کنند. کاراکترهای خاص مثل گیومه، بک‌اسلش و خط جدید باید escape شوند: "، \، . یک نکته مهم درباره فارسی: JSON به‌طور ذاتی از UTF-8 پشتیبانی می‌کند، پس متن فارسی به‌راحتی در آن ذخیره می‌شود. اما گاهی برای کاهش حجم یا جلوگیری از مشکلات encoding، متن‌ها را به صورت escape شده با u ذخیره می‌کنند؛ این کار برای فارسی توصیه نمی‌شود چون حجم را تا سه برابر افزایش می‌دهد.

اعداد در JSON

JSON بین عدد صحیح و اعشاری تفاوت نمی‌گذارد؛ هر دو number هستند. این سادگی، در زبان‌هایی که تفاوت دقیق دارند، می‌تواند مشکل‌ساز شود. برای مثال، اگر عدد بسیار بزرگ (مثل شناسه‌های ۶۴ بیتی) را در JSON ذخیره کنید و سپس در جاوااسکریپت (که عدد را به‌صورت double ذخیره می‌کند) تجزیه کنید، دقت را از دست می‌دهید. برای این نوع داده‌ها، بهتر است عدد را به‌صورت رشته ارسال کنید. همچنین JSON اعداد خاص مثل NaN و Infinity را پشتیبانی نمی‌کند؛ اگر چنین مقداری وجود داشته باشد، باید به null تبدیل شود یا با یک قرارداد خاص (مثل رشته "NaN") نمایش داده شود.

تاریخ و زمان در JSON

JSON تاریخ و زمان بومی ندارد. استاندارد دوفاکتو امروز، استفاده از فرمت ISO 8601 است: "2025-03-15T10:30:00Z". حرف Z در انتها یعنی UTC. اگر منطقه زمانی محلی است، به‌صورت "2025-03-15T10:30:00+03:30" نوشته می‌شود. توصیه اکید این است که همیشه از UTC استفاده کنید و تبدیل منطقه زمانی را در سمت کلاینت انجام دهید. ذخیره تاریخ به‌صورت timestamp عددی هم رایج است، اما خوانایی را کاهش می‌دهد. برای پروژه‌هایی که بین‌المللی هستند، ISO 8601 با UTC بهترین انتخاب است.

null در JSON

null یعنی نبود مقدار. تفاوت بین "field": null و نبود کامل فیلد، مهم است. اولی یعنی فیلد وجود دارد اما مقدارش خالی است؛ دومی یعنی فیلد وجود ندارد. در طراحی API، این تفاوت می‌تواند معناهای متفاوتی داشته باشد. مثلاً در PATCH، وقتی فیلد ارسال نمی‌شود یعنی تغییری اعمال نکن، و وقتی null ارسال می‌شود یعنی مقدار را پاک کن. رعایت این تمایز، نشانه API بالغ است. اگر با مفاهیم طراحی REST آشنایی ندارید، اصول طراحی REST API را مطالعه کنید.

JSON در برابر XML و YAML: کدام و کجا؟

هر سه فرمت JSON، XML و YAML برای تبادل یا ذخیره داده طراحی شده‌اند، اما هرکدام نقاط قوت و ضعف خاصی دارند. انتخاب بین آن‌ها به کاربرد، ابزار و تیم بستگی دارد.

معیار	JSON	XML	YAML
حجم	کم	زیاد	متوسط
خوانایی انسان	خوب	متوسط	عالی
پشتیبانی کامنت	خیر	بله	بله
داده ساختاریافته	محدود	کامل (attribute)	خوب
کاربرد اصلی	API، تنظیمات	مستندات، SOAP، RSS	تنظیمات DevOps
پیچیدگی تجزیه	کم	زیاد	متوسط (indent-sensitive)

JSON در APIها و تبادل داده بین سرویس‌ها برنده قطعی است. سبکی، پشتیبانی گسترده و تجزیه سریع، آن را انتخاب اول کرده. XML در برخی حوزه‌های خاص مثل مستندات سازمانی، RSS، SOAP و format‌های office همچنان زنده است، چون امکان تعریف schema سختگیرانه‌تر (XSD) و attribute در آن وجود دارد. YAML در دنیای DevOps و فایل‌های تنظیمات مثل Kubernetes، Docker Compose و GitHub Actions غالب است، چون خوانایی بالاتری دارد و کامنت را پشتیبانی می‌کند. برای مقایسه کامل YAML، YAML را ساده یاد بگیرید را پیشنهاد می‌کنم.

نکته عملی: گاهی انتخاب بر اساس ابزار موجود تعیین می‌شود، نه فقط ویژگی‌های فرمت. اگر تیم شما با یک ابزار خاص DevOps کار می‌کند، YAML منطقی‌تر است. اگر با APIهای قدیمی سازمانی سروکار دارید، XML همچنان گزینه اصلی است. در پروژه‌های جدید وب، JSON تقریباً همیشه انتخاب اول است.

فرمت درست، فرمتی است که تیم شما با آن راحت‌تر کار می‌کند، نه فرمتی که در مقاله‌ها تحسین می‌شود.

نقش JSON در REST API و ارتباطات وب

JSON امروز زبان پیش‌فرض اکثر REST APIهاست. وقتی یک اپلیکیشن موبایل به سرور درخواست می‌فرستد، بدنه درخواست و پاسخ معمولاً JSON است. این انتخاب دلایل فنی محکمی دارد. اول، مرورگرها و کلاینت‌ها به‌صورت بومی JSON را می‌فهمند و نیازی به کتابخانه اضافی نیست. دوم، حجم کم آن در مقایسه با XML، برای اپلیکیشن‌های موبایل که با پهنای باند محدود کار می‌کنند، حیاتی است. سوم، نگاشت مستقیم آن به ساختارهای داده، کار توسعه‌دهنده را ساده می‌کند.

در یک REST API مدرن، هدر Content-Type باید حتماً application/json باشد و بدنه هم JSON معتبر. کلاینت نیز باید انتظار خود را از طریق هدر Accept اعلام کند. این توافق، بخشی از مفهوم Content Negotiation است که در طراحی اصولی API رعایت می‌شود. اگر در حال ساختن API هستید، توصیه می‌کنم مقاله REST API چیست را بخوانید تا تفاوت‌های آن با سایر سبک‌های API مثل GraphQL و RPC را ببینید.

در پاسخ‌های API، ساختار JSON معمولاً از یک قرارداد پیروی می‌کند. برخی APIها داده را مستقیم برمی‌گردانند: {"id": 1, "name": "..."}. برخی دیگر آن را در یک wrapper قرار می‌دهند: {"data": {...}, "meta": {...}}. انتخاب بین این دو، معمولاً به پیچیدگی API بستگی دارد. اگر از ابتدا wrapper را انتخاب کنید، بعداً اضافه کردن متادیتا ساده‌تر است. اگر آن را انتخاب نکنید، پاسخ‌ها تمیزتر و سبک‌تر خواهند بود. در نهایت ثبات مهم‌تر از انتخاب است: در همه endpointها یک رویکرد را رعایت کنید.

GraphQL و JSON

GraphQL، رقیب مدرن REST، هم از JSON استفاده می‌کند اما با فلسفه‌ای متفاوت. در GraphQL، کلاینت خودش مشخص می‌کند چه فیلدهایی را می‌خواهد و پاسخ دقیقاً همان فیلدها را برمی‌گرداند. این رویکرد، مشکل over-fetching را در REST حل می‌کند. اگر درباره تفاوت این دو سبک مطمئن نیستید، تفاوت REST و GraphQL را ببینید. هر دو، در نهایت داده را در قالب JSON منتقل می‌کنند؛ تفاوت در نحوه درخواست و پاسخ‌دهی است.

کار با JSON در جاوااسکریپت، PHP، پایتون و سایر زبان‌ها

JSON در جاوااسکریپت بومی است. دو متد اصلی JSON.parse() برای تبدیل رشته به object و JSON.stringify() برای تبدیل object به رشته. یک نکته ظریف: JSON.stringify() به‌صورت پیش‌فرض توابع و مقادیر undefined را حذف می‌کند و همچنین ارجاع‌های حلقوی را رد می‌کند. برای سفارشی‌سازی رفتار، می‌توانید یک تابع به‌عنوان پارامتر دوم بدهید.

const user = {
  name: "Ali",
  age: 32,
  greet: function() { return "hi"; }
};

// greet حذف می‌شود
const json = JSON.stringify(user);
// نتیجه: {"name":"Ali","age":32}

// تجزیه با مدیریت خطا
try {
  const parsed = JSON.parse(json);
} catch (e) {
  console.error("Invalid JSON:", e.message);
}

در PHP، توابع json_encode() و json_decode() ستون فقرات کار با JSON هستند. یکی از مشکلات رایج در PHP، کاراکترهای غیر UTF-8 است. اگر داده ورودی دارای انکودینگ اشتباه باشد، json_encode() مقدار false برمی‌گرداند و اگر خطا را مدیریت نکنید، داده بی‌صدا گم می‌شود. توصیه من همیشه استفاده از پرچم JSON_UNESCAPED_UNICODE برای متن فارسی و بررسی خطا با json_last_error() است.

// PHP
$data = ["name" => "علی", "age" => 32];
$json = json_encode($data, JSON_UNESCAPED_UNICODE);

if ($json === false) {
    error_log("JSON error: " . json_last_error_msg());
}

$decoded = json_decode($json, true); // true برای آرایه، false برای object

در پایتون، ماژول بومی json همین نقش را دارد. توابع json.dumps() و json.loads() برای تبدیل بین dict و رشته. یک نکته مهم: در پایتون، json.dumps() روی dict با کلیدهای غیر رشته‌ای مثل int، خطا نمی‌دهد اما در تبدیل، آن‌ها را به رشته تبدیل می‌کند. همچنین پارامتر ensure_ascii=False برای نمایش مستقیم کاراکترهای یونیکد مثل فارسی استفاده می‌شود.

# Python
import json

data = {"name": "علی", "age": 32}
json_str = json.dumps(data, ensure_ascii=False)

# با مدیریت خطا
try:
    parsed = json.loads(json_str)
except json.JSONDecodeError as e:
    print(f"Invalid JSON: {e}")

در زبان‌های typed مثل Java و C#، معمولاً از کتابخانه‌های تخصصی مثل Jackson و Gson (Java) یا System.Text.Json و Newtonsoft.Json (C#) استفاده می‌شود. این کتابخانه‌ها امکان نگاشت JSON به کلاس‌های typed را فراهم می‌کنند که هم خوانایی و هم ایمنی نوع را بالا می‌برد. انتخاب کتابخانه مناسب، بسته به پروژه و ترجیحات تیم انجام می‌شود.

JSON در وردپرس: از REST API تا wp_options

وردپرس از نسخه ۴.۷ یک REST API کامل در هسته خود دارد که پاسخ‌هایش JSON است. این یعنی هر توسعه‌دهنده وردپرس، بدون نصب هیچ افزونه‌ای، می‌تواند با یک GET ساده به /wp-json/wp/v2/posts، فهرست نوشته‌ها را به‌صورت JSON دریافت کند. اگر با این قابلیت آشنایی ندارید، مقاله API در وردپرس نقطه شروع خوبی است. همچنین برای کاربردهای عملی، آموزش استفاده از REST API در وردپرس را ببینید.

در سطح داخلی، وردپرس از JSON برای ذخیره تنظیمات پیچیده در جدول wp_options استفاده می‌کند. مثلاً وقتی یک افزونه تنظیمات چند‌سطحی را ذخیره می‌کند، معمولاً آن‌ها را به JSON تبدیل و در یک ردیف واحد ذخیره می‌کند. این رویکرد دو مزیت دارد: تعداد ردیف‌های جدول options کم می‌ماند و خواندن آن تنظیمات در یک کوئری انجام می‌شود. اما نقطه ضعف هم دارد: اگر آن JSON بزرگ شود، هر بار که وردپرس آن گزینه را بارگذاری می‌کند، هزینه پردازش را می‌پردازید. برای داده‌های بزرگ، استفاده از جدول اختصاصی بهتر از JSON در options است.

در سطح قالب و افزونه، wp_localize_script() و wp_add_inline_script() امکان انتقال داده از PHP به جاوااسکریپت را فراهم می‌کنند. این داده‌ها معمولاً به‌صورت JSON در صفحه تزریق می‌شوند. یک نکته امنیتی مهم: اگر داده حساسی مثل توکن یا کلید را به این روش منتقل کنید، در View Source صفحه قابل مشاهده است. همیشه بررسی کنید که چه داده‌ای به سمت کلاینت می‌فرستید.

در وردپرس، JSON همه‌جا هست؛ حتی جایی که انتظارش را ندارید. یاد گرفتن کار با آن، شما را از یک کاربر وردپرس به یک توسعه‌دهنده واقعی تبدیل می‌کند.

امنیت JSON: تهدیدهایی که نادیده گرفته می‌شوند

JSON به‌خودی‌خود امن است، چون هیچ کدی را اجرا نمی‌کند. اما شیوه استفاده از آن می‌تواند حفره امنیتی ایجاد کند. یکی از معروف‌ترین این حفره‌ها، JSON Hijacking است. در گذشته، مرورگرها اجازه می‌دادند کد جاوااسکریپت به‌صورت <script src="api.example.com/data"> بارگذاری شود و پاسخ JSON را به‌عنوان کد تفسیر کند. این مشکل با استانداردهای مدرن مرورگرها و الزام CORS تا حد زیادی حل شده، اما اگر API شما CORS را درست تنظیم نکرده باشد، همچنان در معرض خطر است.

تهدید دوم، Prototype Pollution در جاوااسکریپت است. اگر یک API داده JSON دریافتی را مستقیماً در کتابخانه‌های ادغام عمیق (deep merge) استفاده کند، ممکن است مهاجم بتواند از طریق کلید __proto__ یا constructor، prototype object را آلوده کند و رفتار کل برنامه را تغییر دهد. این حمله به‌ویژه در Node.js و اپلیکیشن‌های SPA خطرناک است. راه‌حل، اعتبارسنجی و sanitization ورودی با schema و عدم استفاده از deep merge بدون فیلتر کلیدهای حساس است.

تهدید سوم، انفجار حجم (Billion Laughs و نسخه JSON آن) است. یک payload بزرگ یا ساختار تو‌در‌توی بسیار عمیق می‌تواند سرور را در مرحله تجزیه از پا دربیاورد. راه‌حل، تعیین سقف حجم payload و محدود کردن عمق ساختار JSON قبل از تجزیه است. تهدید چهارم، XSS از طریق JSON است. اگر داده JSON که حاوی کاراکترهای HTML است، مستقیماً در صفحه تزریق شود، می‌تواند باعث XSS شود. همیشه هنگام درج داده در DOM، از متدهای امن مثل textContent استفاده کنید یا داده را از طریق escape مناسب پاک کنید.

بهترین شیوه‌های امنیتی JSON

سه اصل کلی را در همه پروژه‌ها رعایت می‌کنم: اول، همیشه Content-Type را در پاسخ application/json تنظیم کنید. این کار جلوی تفسیر نادرست پاسخ را می‌گیرد. دوم، CORS را صریحاً تنظیم کنید؛ هرگز Access-Control-Allow-Origin: * را روی APIهای حساس قرار ندهید. سوم، داده حساس را در URL یا در فیلدهای قابل حدس قرار ندهید؛ چون URLها در لاگ‌ها ثبت می‌شوند و می‌توانند لو بروند. اگر با REST API کار می‌کنید، مقاله راهنمای احراز هویت در REST API نکات تکمیلی دارد.

عملکرد JSON: بهینه‌سازی حجم و پردازش

عملکرد JSON دو وجه دارد: حجم داده منتقل‌شده و زمان پردازش در سرور یا کلاینت. در سمت حجم، سه تکنیک اصلی وجود دارد: minification (حذف فاصله و خط جدید)، compression (gzip یا brotli) و انتخاب دقیق فیلدها (فقط فیلدهای موردنیاز را برگردانید). ترکیب این سه، می‌تواند حجم پاسخ را تا ۹۰ درصد کاهش دهد.

در سمت پردازش، هزینه تجزیه JSON به حجم و عمق آن بستگی دارد. تجزیه یک JSON بزرگ که ۵۰۰ کیلوبایت حجم دارد، در جاوااسکریپت حدود ۱۰ تا ۲۰ میلی‌ثانیه طول می‌کشد. اگر اپلیکیشن شما در هر ثانیه چند صد درخواست دریافت می‌کند، این عدد قابل توجه می‌شود. راه‌حل، کاهش حجم پاسخ با صفحه‌بندی و انتخاب فیلد است. اگر پاسخ API شما به‌طور مداوم بالای ۱۰۰ کیلوبایت است، احتمالاً مشکلی در طراحی دارید. برای مطالعه بیشتر درباره بهینه‌سازی، بهینه‌سازی عملکرد REST API را ببینید.

Streaming JSON

برای پاسخ‌های بسیار بزرگ، تجزیه کامل JSON در حافظه کارایی ندارد. برخی کتابخانه‌ها امکان streaming JSON را فراهم می‌کنند که در آن داده به‌صورت تکه‌تکه خوانده و پردازش می‌شود. در Node.js، کتابخانه‌هایی مثل stream-json این کار را ممکن می‌کنند. در پایتون، ijson همین نقش را دارد. اما streaming پیچیدگی بیشتری دارد و فقط برای سناریوهای خاص توصیه می‌شود. در بیشتر موارد، صفحه‌بندی و تقسیم پاسخ به چند درخواست کوچک، راه‌حل بهتری است.

JSON و کش

پاسخ‌های JSON که تغییر نمی‌کنند، باید کش شوند. لایه کش می‌تواند مرورگر، CDN، Redis یا حافظه سرور باشد. برای APIهای عمومی، هدر Cache-Control: public, max-age=3600 یک ساعت کش را فعال می‌کند. برای داده‌های کاربری، باید Cache-Control: private استفاده شود و کش CDN غیرفعال باشد. اگر با ETag کار کنید، کلاینت می‌تواند با If-None-Match بررسی کند که آیا نسخه جدیدی وجود دارد یا نه. این تکنیک، به‌ویژه برای داده‌های بزرگ، پهنای باند زیادی صرفه‌جویی می‌کند.

سرعت JSON، نتیجه طراحی دقیق است، نه فقط ابزار سریع. یک پاسخ بد طراحی شده را هیچ ابزاری سریع نمی‌کند.

آینده JSON و جایگاه آن در وب مدرن

JSON بیش از دو دهه است که استاندارد دوفاکتوی تبادل داده در وب است و به‌نظر نمی‌رسد در آینده نزدیک جایگزین شود. اما تحولات در حال وقوع هستند. یکی از مهم‌ترین‌ها، JSON Schema است؛ یک استاندارد برای توصیف ساختار JSON که امکان اعتبارسنجی داده را فراهم می‌کند. استفاده از JSON Schema در APIها روزبه‌روز بیشتر می‌شود، چون مستندسازی و اعتبارسنجی خودکار را ممکن می‌کند.

تحول دوم، ظهور فرمت‌های دودویی جایگزین مثل MessagePack و CBOR است. این فرمت‌ها داده‌های ساختاریافته را در حجم کمتر و با سرعت بالاتر منتقل می‌کنند. اما خوانا نبودن برای انسان، و نیاز به ابزار خاص برای تجزیه، باعث شده که عمدتاً در سناریوهای خاص مثل IoT و میکروسرویس‌های پرترافیک استفاده شوند. برای اکثر کاربردهای وب، JSON همچنان انتخاب اول است.

تحول سوم، گسترش JSON در حوزه‌های جدید مثل پایگاه‌های داده NoSQL است. PostgreSQL از نوع داده jsonb پشتیبانی می‌کند که امکان کوئری مستقیم روی داده JSON را فراهم می‌کند. MongoDB به‌طور کامل بر اساس مدل سند JSON ساخته شده. این روند نشان می‌دهد JSON از یک فرمت تبادل، به یک مدل ذخیره‌سازی تبدیل شده است. برای توسعه‌دهندگان وردپرس، این یعنی داده‌های پیچیده را می‌توان بدون جداول متعدد ذخیره و مدیریت کرد.

پرسش‌های پرتکرار درباره JSON

آیا JSON فقط در جاوااسکریپت استفاده می‌شود؟
نه. اسم آن از جاوااسکریپت آمده اما امروز تقریباً همه زبان‌های برنامه‌نویسی از JSON پشتیبانی بومی یا کتابخانه‌ای دارند. JSON یک استاندارد مستقل است و در پایتون، PHP، Java، C#، Ruby، Go و سایر زبان‌ها به شکل گسترده استفاده می‌شود.

چرا JSON کامنت را پشتیبانی نمی‌کند؟
داگلاس کراکفورد عمداً کامنت را از JSON حذف کرد تا تجزیه‌کننده‌ها ساده بمانند و داده‌ها فقط داده باشند، بدون دستورات. اگر به کامنت نیاز دارید، فرمت‌های غیررسمی مثل JSON5 یا JSONC را در نظر بگیرید که در محیط توسعه ابزارهایی مثل VS Code و TypeScript استفاده می‌شوند.

آیا JSON می‌تواند داده باینری ذخیره کند؟
به‌صورت بومی نه. برای انتقال فایل باینری، باید آن را به Base64 تبدیل کنید یا از فرمت‌های دیگر مثل multipart/form-data استفاده کنید. Base64 حجم داده را حدود ۳۳ درصد افزایش می‌دهد، پس برای فایل‌های بزرگ منطقی نیست.

تفاوت JSON و JavaScript Object چیست؟
هر JSON معتبر، یک JavaScript Object معتبر است اما برعکس آن نه. JavaScript Object می‌تواند شامل تابع، undefined، Date و سایر مقادیر خاص باشد که JSON از آن‌ها پشتیبانی نمی‌کند. همچنین کلیدهای JavaScript Object می‌توانند بدون گیومه باشند، اما در JSON باید حتماً در گیومه دوتایی باشند.

چگونه یک فایل JSON بزرگ را در PHP یا پایتون بخوانم؟
اگر فایل بزرگ است، خواندن کامل آن در حافظه ممکن است باعث خطای memory limit شود. در این حالت از خواندن streaming استفاده کنید. در PHP، کتابخانه‌هایی مثل halaxa/json-machine و در پایتون ijson این کار را ممکن می‌کنند. برای فایل‌های تا چند مگابایت، خواندن کامل مشکلی ندارد.

JSON Schema چیست و چه کاربردی دارد؟
JSON Schema یک استاندارد برای توصیف ساختار JSON است؛ یعنی مشخص می‌کند چه فیلدهایی باید باشند، چه نوعی دارند و چه محدودیت‌هایی دارند. از آن برای اعتبارسنجی ورودی API، تولید مستندات خودکار و حتی تولید کد استفاده می‌شود. ابزارهایی مثل Ajv در جاوااسکریپت و Opis در PHP از JSON Schema پشتیبانی می‌کنند.

آیا JSON از فارسی پشتیبانی می‌کند؟
بله. JSON به‌طور ذاتی از UTF-8 پشتیبانی می‌کند و متن فارسی بدون مشکل ذخیره و منتقل می‌شود. تنها نکته این است که در برخی زبان‌ها مثل PHP باید پرچم JSON_UNESCAPED_UNICODE را فعال کنید تا کاراکترهای فارسی به‌صورت uXXXX escape نشوند.

چرا گاهی JSON.parse خطا می‌دهد؟
رایج‌ترین دلایل: کاما انتهایی، گیومه تک به‌جای دوتایی، کامنت، NaN یا Infinity، کاراکترهای کنترلی بدون escape. همیشه قبل از تجزیه، اعتبار JSON را بررسی کنید. ابزارهایی مثل JSONLint و یا پنل Network در DevTools مرورگر برای اشکال‌زدایی بسیار مفیدند.

حرف آخر: چرا تسلط بر JSON یک مهارت پایه است

JSON در ابتدا یک فرمت ساده به‌نظر می‌رسید، اما امروز به یکی از ستون‌های اساسی وب تبدیل شده. اگر شما یک توسعه‌دهنده وب، مهندس DevOps، مدیر محصول یا حتی یک تحلیلگر داده هستید، تسلط بر JSON یک مهارت پایه است، نه یک گزینه. از خواندن پاسخ یک API تا طراحی ساختار داده در پایگاه‌های NoSQL، از نوشتن فایل تنظیمات تا انتقال داده بین میکروسرویس‌ها، JSON همه‌جا هست.

در این مقاله سعی کردم هم مبانی را روشن کنم و هم نکات عملی که کمتر جایی مطرح می‌شوند. اگر یک نکته اصلی از این مقاله با خودتان ببرید، این باشد: JSON یک ابزار ساده است که با طراحی درست می‌تواند قدرتمند شود و با طراحی غلط، به یک بدهی فنی پنهان تبدیل شود. انتخاب نوع داده درست، تعیین محدودیت حجم، توجه به امنیت و برنامه‌ریزی برای کش، همه این‌ها تصمیم‌هایی هستند که از همان روز اول باید گرفته شوند.

اگر در پروژه‌ای با مشکل خاصی در کار با JSON مواجه شده‌اید یا ترفند یا ابزاری می‌شناسید که در این مقاله نبود، تجربه‌تان را به اشتراک بگذارید. هر نکته‌ای که از میدان واقعی بیاید، برای خواننده بعدی ارزشمندتر از ده صفحه مستندات رسمی است.