JSON Schema আসলে কী সমাধান করে
সংক্ষেপে: Schema কাঠামো ও টাইপ নিয়ন্ত্রণ করে, ব্যবসায়িক অর্থ নয়। অনুপস্থিত ফিল্ড, ভুল টাইপ ও রেঞ্জের বাইরের এনাম আটকায়, অথচ "টাকা শূন্যের বেশি" ধরনের নিয়ম কোডে থাকে।
মূল কথা: JSON Schema কাঠামো, টাইপ, রেঞ্জ ও ফরম্যাট বলবৎ করুক, অথচ ক্রস-ফিল্ড নিয়ম, ব্যবসায়িক invariants ও বাহ্যিক অবস্থা কোডে থাকুক; পাবলিক API ও ভাগ করা পেললোডে এটি গ্রহণ করুন, পাঁচ ফিল্ডের অভ্যন্তরীণ সার্ভিসে নয়।
এটি "এই ডেটার আকৃতি ঠিক কি না" উত্তর দেয়, "এই ডেটা অর্থবহ কি না" নয়।
যা ভালো করে
কাঠামোগত সম্পূর্ণতা। কোন ফিল্ড থাকতেই হবে, বাড়তি অনুমোদিত কি না (required, additionalProperties)।
টাইপ। port সংখ্যা নাকি স্ট্রিং, tags অ্যারে নাকি স্কেলার। এটি একাই বহু-ভাষা সিস্টেমে অনেক ডিফেন্সিভ কোড সরিয়ে দেয়।
রেঞ্জ। enum, minimum/maximum, স্ট্রিং ও অ্যারে দৈর্ঘ্য।
ফরম্যাট। তারিখ, ইমেইল, URI ও UUID-র জন্য format, আর তা বলবৎ করা ভ্যালিডেটরসহ।
নেস্টিং। অবজেক্ট ও অ্যারের প্রতিটি স্তরের নিজস্ব বাধ্যবাধকতা, আর এররে নির্দিষ্ট পাথ।
ডকুমেন্টেশন। Schema-ই চুক্তি। ফিল্ড বদলালে ডিফ প্রভাবের পরিধি দেখায়। এটি টাইপ ও ফর্মও জেনারেট করে, তাই এক সংজ্ঞা কয়েক ভোক্তাকে খাওয়ায়।
যা করতে পারে না
ক্রস-ফিল্ড নির্ভরতা। "শেষ শুরুর পরে হতে হবে" if/then/else দিয়ে প্রকাশ করা যায়, কিন্তু ফল কোডের তিন লাইনের চেয়ে দীর্ঘ ও অপাঠ্য।
ব্যবসায়িক invariants। "স্টক ঋণাত্মক হতে পারে না" বাহ্যিক অবস্থার উপর নির্ভর করে। Schema একটি ডকুমেন্ট দেখে।
সেমান্টিক্স। price: -100 {"type": "number"} নিখুঁতভাবে পূরণ করে। এটি বৈধ দাম কি না Schema-র জ্ঞানের বাইরে।
একটি কার্যকর বিভাজন
| স্তর | মালিক |
|---|---|
| সিনট্যাক্স: বৈধ JSON কি | পার্সার |
| কাঠামো: ফিল্ড, টাইপ, রেঞ্জ, ফরম্যাট | JSON Schema |
| সেমান্টিক্স: ক্রস-ফিল্ড, ব্যবসায়িক নিয়ম, বাহ্যিক অবস্থা | অ্যাপ্লিকেশন কোড |
| নিরাপত্তা: আকার, গভীরতা, রেট | গেটওয়ে / মিডলওয়্যার |
এগুলো এক জায়গায় চেপে দিলে Schema শত শত লাইনে বাড়ে, পাঁচ স্তরের if/then নিয়ে। তখন মানুষ তা এড়িয়ে যায়।
কখন লাভজনক
- অজানা ভোক্তাযুক্ত পাবলিক API
- একই পেললোড পড়া একাধিক সার্ভিস
- কনফিগ-চালিত সিস্টেম যেখানে টাইপো দ্রুত ব্যর্থ হতে হবে
- চুক্তি থেকে টাইপ বা ফর্ম জেনারেশন
পাঁচ ফিল্ড ও এক ফ্রন্টএন্ডের ছোট অভ্যন্তরীণ সার্ভিসে হাতে লেখা চেক রক্ষণাবেক্ষণে দ্রুত। সেখানে Schema আনা ঋণাত্মক কাজ।
সাধারণ প্রশ্ন
JSON Schema গ্রহণ করব কি না কীভাবে ঠিক করব?
পাবলিক ভোক্তা, একই পেললোড পড়া একাধিক সার্ভিস, আর টাইপ বা ফর্ম জেনারেশনের প্রয়োজন বিবেচনা করুন। পাঁচ ফিল্ড ও এক ফ্রন্টএন্ডের ছোট অভ্যন্তরীণ সার্ভিসে হাতে লেখা চেক রক্ষণাবেক্ষণে দ্রুত।
ক্রস-ফিল্ড নিয়ম কোডে রাখা উচিত কেন?
"শেষ শুরুর পরে হতে হবে" if/then/else-এ চেপে ফেলা যায়, কিন্তু ফল কয়েক লাইন কোডের চেয়ে দীর্ঘ ও অপাঠ্য। Schema বাহ্যিক অবস্থাও দেখতে পারে না।
Schema কি পেললোড আকার ও নেস্টিং গভীরতা যাচাই করা উচিত?
না। Schema কাঠামো বর্ণনা করে, আকার বা গভীরতা নয়; সেই সীমা গেটওয়ে বা মিডলওয়্যার স্তরের।