JSON যথেষ্ট ভিন্ন ভূমিকায় দেখা যায় যে এদের আলাদা করা উপযোগী: ফরম্যাট সবখানে একই, কিন্তু প্রতিটি ব্যবহারের ক্ষেত্র এর থেকে প্রকৃতভাবে কী চায় তা আলাদা, এবং একটিকে অন্যটির সাথে বিভ্রান্ত করা অজাচার সিদ্ধান্তের একটি সাধারণ উৎস।
REST API payloads
পরিমাণের দিক থেকে সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্র। একটি অনুরোধ বডি এবং একটি প্রতিক্রিয়া বডি প্রত্যেকই একটি JSON ডকুমেন্ট, Content-Type: application/json, একপাশে জেনারেট এবং অন্যপাশে খাওয়া হয় কোনো মানুষের মাঝখানে পড়া ছাড়া। এখানে কিছুই মন্তব্য বা হাতে-সম্পাদনা সুবিধার প্রয়োজন হয় না; যা প্রয়োজন একটি অস্পষ্ট ব্যাকরণ যা সব ভাষা একইভাবে পার্স করে, যা JSON-এর প্রকৃত শক্তি। একটি REST payload সেই আকারও যার জন্য JSON Schema Validator আছে: একটি API-এর চুক্তির বিরুদ্ধে একটি প্রতিক্রিয়া পরীক্ষা করুন, এবং ঠিক দেখুন কোন ফিল্ড এটি লঙ্ঘন করে এবং কেন, সেই বাগ প্রোডাকশন কোডে পৌঁছানোর আগে।
অ্যাপ্লিকেশন কনফিগারেশন
package.json, tsconfig.json, composer.json, এবং ডজন ডজন সরঞ্জাম কনফিগ এর বাইরে। এটি সেই একটি ব্যবহারের ক্ষেত্র যেখানে JSON-এর মন্তব্যের অনুপস্থিতি প্রকৃতভাবে কিছু খরচ করে: একটি সেটিং ব্যাখ্যা ছাড়া, কারণ ফরম্যাটে এটি রাখার জায়গা নেই। কিছু সরঞ্জাম এটিকে // comment কী দিয়ে কাটিয়ে ওঠে যেটি কেউ প্রোগ্রামেটিক্যালি পড়ে না, অন্যরা YAML বা একটি JSON সুপারসেট (JSON5, JSONC)-এ পরিবর্তন করে যা মন্তব্য ফিরিয়ে আনে। JSON vs YAML দেখুন পূর্ণ ট্রেড-অফের জন্য; সংক্ষিপ্ত সংস্করণ হলো হাতে-সম্পাদিত কনফিগ ফাইল প্রায়ই YAML-এর মন্তব্য থেকে উপকৃত হয়, যখন সরঞ্জাম দ্বারা সম্পূর্ণরূপে জেনারেট এবং খাওয়া কনফিগ সাধারণ JSON হিসাবে ঠিক থাকে।
NoSQL এবং ডকুমেন্ট ডাটাবেস
MongoDB ডকুমেন্টকে BSON হিসাবে সংরক্ষণ করে, একটি বাইনারি ফরম্যাট যা JSON-এর ডেটা মডেলের একটি সুপারসেট, এবং আপনি এটি কোয়েরি করলে JSON (বা JSON-সদৃশ শেল সিনট্যাক্স) ফিরিয়ে দেয়। CouchDB এবং অধিকাংশ ডকুমেন্ট স্টোর JSON সরাসরি গ্রহণ এবং ফিরিয়ে দেয়। এখানে আকর্ষণ কাঠামোগত: একটি ডকুমেন্ট ডাটাবেসের পুরো পিচ হলো তথ্য আপনার অ্যাপ্লিকেশন যে আকারে ইতিমধ্যে ব্যবহার করে সেই আকারে সংরক্ষণ করা, প্রথমে রো এবং ফরেইন কীতে নরমালাইজ করার বদলে, এবং JSON-এর অবজেক্ট-এন্ড-অ্যারে মডেল অধিকাংশ ভাষার নেটিভ টাইপের কাছাকাছি যে অনুবাদ প্রায় বিনামূল্যে।
লগ লাইন এবং স্ট্রিমিং ডেটা: NDJSON
একক JSON ডকুমেন্ট ভালোভাবে স্ট্রিম করে না: একটি পার্সারের সাধারণত মান উত্পাদন করার আগে পুরোটি প্রয়োজন, কারণ একটি ডকুমেন্ট কেবল তখনই বৈধ যখন এর চূড়ান্ত বন্ধ বন্ধনী আসে। Newline Delimited JSON (NDJSON) এটি সমাধান করে প্রতিটি লাইনকে তার নিজস্ব স্বাধীন, সম্পূর্ণ JSON মান করে, তাই একটি লগ পাইপলাইন, একটি Kafka টপিক, বা একটি বড় এক্সপোর্ট পুরো ফাইল মেমরিতে না রেখে একটি লাইন একবারে প্রসেস করা যায়। JSON to NDJSON Converter একটি JSON অ্যারেকে এই লাইন-প্রতি-রেকর্ড ফরম্যাটে এবং পিছনে পরিণত করে, একটি স্ট্রিমের জন্য রিকভারি সহ যাতে একটি খারাপ রেকর্ডের জন্য পুরো ফাইল ব্যর্থ না হয়।
ব্রাউজার স্টোরেজ
localStorage এবং sessionStorage কেবল স্ট্রিং সংরক্ষণ করে; কোনো কিছু কাঠামোগত JSON.stringify(value) হিসাবে যায় এবং JSON.parse(stored) হিসাবে বের হয়। এটিও সেখানে যেখানে সংখ্যার নির্ভুলতার সমস্যা যা JSON Data Types Explained কভার করে একটি প্রকৃত বাগে পরিণত হয়: ব্রাউজারের নিজস্ব JSON.parse-এর মাধ্যমে localStorage-এর মাধ্যমে একটি বড় পূর্ণসংখ্যা ID-র রাউন্ড-ট্রিপ চুপচাপে মান পরিবর্তন করতে পারে, যা ঠিক সেই ফেলিউর মোড যার জন্য এই সাইটের নিজস্ব সরঞ্জাম পুনরুত্পাদনের বদলে এড়াতে এবং রিপোর্ট করতে তৈরি।
আপনার নিজের ডেটা দিয়ে চেষ্টা করা
উপরে উল্লিখিত প্রতিটি সরঞ্জাম সম্পূর্ণরূপে আপনার ব্রাউজারে চলে: JSON Formatter, NDJSON converter, বা Schema Validator-এ পেস্ট করা কিছুই কোথাও আপলোড হয় না, যা ঠিক সেই প্রকৃত API প্রতিক্রিয়া এবং কনফিগ ফাইলের জন্য সবচেয়ে বেশি গুরুত্বপূর্ণ যার সম্পর্কে এই পৃষ্ঠটি।