מה JSON Schema באמת פותר
שורה תחתונה: Schema שולט במבנה ובטיפוסים, לא במשמעות עסקית. הוא עוצר שדות חסרים, טיפוסים שגויים ו-enums מחוץ לטווח, בעוד שכללים כמו סכום גדול מאפס נשארים בקוד.
שורה תחתונה: תנו ל-JSON Schema לכפות מבנה, טיפוסים, טווחים ופורמטים, בעוד שכללים חוצי-שדות, אינווריאנטים עסקיים ומצב חיצוני נשארים בקוד; אמצו אותו ל-API ציבוריים ול-payloads משותפים, לא לשירות פנימי עם חמישה שדות.
הוא עונה על "האם הנתונים מעוצבים נכון", לא על "האם הנתונים הגיוניים".
מה הוא עושה היטב
שלמות מבנית. אילו שדות חייבים להתקיים, והאם מותרים נוספים (required, additionalProperties).
טיפוסים. port כמספר או מחרוזת, tags כמערך או כערך בודד. זה לבדו מסיר הרבה קוד הגנתי במערכות מרובות-שפות.
טווחים. enum, minimum/maximum, אורך מחרוזת ומערך.
פורמטים. format לתאריכים, אימייל, URIs ו-UUIDs, עם מאמתים שכופים אותם.
קינון. כל רמה של אובייקטים ומערכים מקבלת אילוצים משלה, והשגיאות נושאות נתיב מדויק.
תיעוד. ה-Schema הוא החוזה. שנו שדה וה-diff מראה את רדיוס ההשפעה. הוא גם מייצר טיפוסים וטפסים, כך שהגדרה אחת מזינה כמה צרכנים.
מה הוא לא יכול לעשות
תלויות חוצי-שדות. "סיום חייב להיות אחרי התחלה" אפשר לבטא עם if/then/else, אבל התוצאה ארוכה וקשה לקריאה יותר משלוש שורות קוד.
אינווריאנטים עסקיים. "המלאי לא יכול להיות שלילי" תלוי במצב חיצוני. Schema רואה מסמך אחד.
סמנטיקה. price: -100 מספק {"type": "number"} באופן מושלם. האם זה מחיר חוקי נמצא מחוץ לידע של ה-Schema.
חלוקה שאפשר לעבוד איתה
| שכבה | בעל האחריות |
|---|---|
| תחביר: האם זה JSON תקין | מפרס |
| מבנה: שדות, טיפוסים, טווחים, פורמטים | JSON Schema |
| סמנטיקה: חוצי-שדות, כללים עסקיים, מצב חיצוני | קוד האפליקציה |
| בטיחות: גודל, עומק, קצב | Gateway / middleware |
כווצו את אלה למקום אחד וה-Schema יתפח למאות שורות עם חמש רמות של if/then. בשלב הזה אנשים עוקפים אותו.
מתי זה משתלם
- API ציבוריים עם צרכנים לא מוכרים
- כמה שירותים שקוראים את אותו payload
- מערכות מונחות-קונפיגורציה שבהן טעויות כתיב חייבות להיכשל מהר
- יצירת טיפוסים או טפסים מהחוזה
בשירות פנימי קטן עם חמישה שדות ופרונט אחד, בדיקות שנכתבות ביד מהירות יותר לתחזוקה. הכנסת Schema שם היא עבודה שלילית.
שאלות ותשובות
איך להחליט אם לאמץ JSON Schema?
שקלו צרכנים ציבוריים, כמה שירותים שקוראים את אותו payload, והצורך לייצר טיפוסים או טפסים. בשירות פנימי קטן עם חמישה שדות ופרונט אחד, בדיקות שנכתבות ביד מהירות יותר לתחזוקה.
למה כללים חוצי-שדות צריכים להישאר בקוד?
"סיום חייב להיות אחרי התחלה" אפשר לדחוס ל-if/then/else, אבל התוצאה ארוכה וקשה לקריאה יותר מכמה שורות קוד. Schema גם לא יכול לראות מצב חיצוני.
האם Schema צריך לאמת גודל payload ועומק קינון?
לא. Schema מתאר מבנה, לא גודל או עומק; המגבלות האלה שייכות לשכבת gateway או middleware.