JSON Schema แก้ปัญหาอะไรจริง ๆ
สรุปสำคัญ: Schema ควบคุมโครงสร้างและชนิดข้อมูล ไม่ใช่ความหมายทางธุรกิจ มันกันฟิลด์ที่หาย ชนิดผิด และ enum นอกช่วง แต่กฎอย่างยอดเงินต้องมากกว่าศูนย์ยังอยู่ที่โค้ด
สรุปสั้น ๆ: ให้ JSON Schema บังคับโครงสร้าง ชนิด ช่วงค่า และรูปแบบ ส่วนกฎข้ามฟิลด์ invariant ทางธุรกิจ และสถานะภายนอกให้อยู่ในโค้ด; ใช้กับ API สาธารณะและ payload ที่ใช้ร่วมกัน ไม่ใช่กับ service ภายในที่มีห้าฟิลด์
มันตอบคำถาม "ข้อมูลนี้มีรูปร่างถูกต้องไหม" ไม่ใช่ "ข้อมูลนี้สมเหตุสมผลไหม"
สิ่งที่ทำได้ดี
ความครบถ้วนของโครงสร้าง ฟิลด์ใดต้องมี และอนุญาตให้มีฟิลด์เกินหรือไม่ (required, additionalProperties)
ชนิดข้อมูล port เป็นตัวเลขหรือสตริง, tags เป็นอาร์เรย์หรือค่าเดี่ยว แค่นี้ก็กำจัดโค้ด defensive ได้มากในระบบหลายภาษา
ช่วงค่า enum, minimum/maximum, ความยาวสตริงและอาร์เรย์
รูปแบบ format สำหรับวันที่ email URI และ UUID พร้อม validator ที่บังคับใช้
การซ้อน ทุกชั้นของ object และอาร์เรย์มีข้อจำกัดของตัวเอง และ error บอก path ที่แม่นยำ
เอกสาร Schema คือสัญญา เปลี่ยนฟิลด์แล้ว diff แสดงขอบเขตผลกระทบ มันยังสร้าง type และ form ได้ นิยามเดียวจึงป้อนผู้ใช้หลายราย
สิ่งที่ทำไม่ได้
การพึ่งพาข้ามฟิลด์ "end ต้องอยู่หลัง start" เขียนได้ด้วย if/then/else แต่ผลลัพธ์ยาวและอ่านยากกว่าโค้ดสามบรรทัด
Invariant ทางธุรกิจ "สต็อกติดลบไม่ได้" ขึ้นกับสถานะภายนอก Schema เห็นแค่เอกสารเดียว
ความหมาย price: -100 ผ่าน {"type": "number"} ได้สมบูรณ์ ราคานี้ถูกต้องตามกฎหรือไม่อยู่นอกความรู้ของ Schema
การแบ่งงานที่ใช้ได้จริง
| ชั้น | เจ้าของ |
|---|---|
| ไวยากรณ์: เป็น JSON ที่ถูกต้องหรือไม่ | Parser |
| โครงสร้าง: ฟิลด์ ชนิด ช่วงค่า รูปแบบ | JSON Schema |
| ความหมาย: ข้ามฟิลด์ กฎธุรกิจ สถานะภายนอก | โค้ดแอปพลิเคชัน |
| ความปลอดภัย: ขนาด ความลึก rate | Gateway / middleware |
รวมทั้งหมดไว้ที่เดียวแล้ว Schema จะโตเป็นหลายร้อยบรรทัดพร้อม if/then ห้าชั้น ถึงจุดนั้นคนก็เลี่ยงไปทางอื่น
เมื่อไหร่ที่คุ้ม
- API สาธารณะที่ผู้ใช้ไม่รู้จัก
- หลาย service อ่าน payload เดียวกัน
- ระบบที่ขับด้วย config ซึ่งการพิมพ์ผิดต้องล้มเหลวทันที
- การสร้าง type หรือ form จากสัญญา
สำหรับ service ภายในเล็ก ๆ ห้าฟิลด์และ frontend หนึ่งตัว การเขียนเช็กเองดูแลเร็วกว่า การใส่ Schema ตรงนั้นคือการทำงานเชิงลบ
คำถามที่พบบ่อย
ควรตัดสินใจว่าจะนำ JSON Schema มาใช้หรือไม่อย่างไร?
ชั่งน้ำหนักผู้ใช้สาธารณะ หลาย service ที่อ่าน payload เดียวกัน และความจำเป็นในการสร้าง type หรือ form สำหรับ service ภายในเล็ก ๆ ห้าฟิลด์และ frontend หนึ่งตัว การเขียนเช็กเองดูแลเร็วกว่า
ทำไมกฎข้ามฟิลด์ถึงควรอยู่ในโค้ด?
"end ต้องอยู่หลัง start" ยัดลง if/then/else ได้ แต่ผลลัพธ์ยาวและอ่านยากกว่าโค้ดไม่กี่บรรทัด Schema ยังมองไม่เห็นสถานะภายนอกด้วย
Schema ควร validate ขนาด payload และความลึกของการซ้อนไหม?
ไม่ควร Schema อธิบายโครงสร้าง ไม่ใช่ขนาดหรือความลึก; ขีดจำกัดเหล่านั้นอยู่ในชั้น gateway หรือ middleware