डेटा सत्यापन बनाम डेटा सत्यापन बनाम जेएसओएन स्कीमा बनाम इनपुट सत्यापन

Question

जेएसओएन स्कीमा का उपयोग करने के बारे में मुझे क्या मिल सकता है, वैध डेटा का वर्णन करने के कार्यों (या कम से कम भेदभाव की कमी) के बारे में भ्रमित उलझन में प्रतीत होता है, मान्य संग्रहीत डेटा, और इनपुट डेटा मान्य।

एक विशिष्ट उदाहरण की तरह दिखता है:

var schema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

यह वही एक डेटा की दुकान में वैध डेटा यह सत्यापित करने के लिए की तरह दिखना चाहिए, और इसलिए वर्णन करने के लिए अच्छी तरह से काम करता है (उत्तरार्द्ध बहुत उपयोगी-अगर नहीं है क्या है एक स्टोर यह पहले से मान्य होना चाहिए):

var storedData = { 
    id: 123, 
    name: 'orange', 
    description: 'delicious' 
}; 

यह इनपुट को मान्य करने के लिए अच्छी तरह से काम नहीं करता है। id उपयोगकर्ता को इनपुट के हिस्से के रूप में प्रदान करने के लिए उत्पन्न करने के लिए सबसे अधिक संभावना है और नहीं। निम्नलिखित इनपुट सत्यापन में विफल रहता है, क्योंकि यह अभाव है id जो स्कीमा वाणी required होने के लिए:

var inputData = { 
    name: 'orange', 
    description: 'delicious' 
}; 

ठीक है, एक कह सकते हैं, स्कीमा प्रत्यक्ष इनपुट को मान्य करने के लिए नहीं होती है, सत्यापन के बाद ही होने चाहिए एप्लिकेशन ने id जोड़ा और डेटा संग्रहीत करने के लिए क्या है।

स्कीमा प्रत्यक्ष इनपुट को मान्य करने के लिए नहीं होती है अगर, हालांकि, क्या 1) JavaScript का बिंदु ब्राउज़र में चल प्रमाणकों, शायद प्रत्यक्ष इनपुट और 2) स्पष्ट रूप से इनपुट उन्मुख readonly की बात खिलाया जा रहा है कल्पना में स्कीमा सुविधा?

ग्राउंड्स को गुणों के बारे में सोचते समय शेकियर हो जाता है जिसे एक बार सेट किया जा सकता है लेकिन अपडेट नहीं किया जा सकता है (जैसे उपयोगकर्ता नाम), साथ ही विभिन्न एक्सेस स्तर (जैसे व्यवस्थापक और नारंगी का मालिक description को बदल सकता है, जबकि अन्य उपयोगकर्ताओं के लिए यह readonly रहना चाहिए)।

इससे निपटने के लिए सबसे अच्छा (या कम से कम काम करने वाला) अभ्यास क्या है? प्रत्येक उपयोग मामले के लिए एक अलग स्कीमा, जैसे नीचे?

var baseSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

var ownerUpdateSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: false, readonly: true }, 
     name: { type: 'string', required: true }, 
     description: { type: 'string', required: false } 
    } 
}; 

var userUpdateSchema = { 
    type: 'object', 
    properties: { 
     id: { type: 'integer', required: false, readonly: true }, 
     name: { type: 'string', required: false, readonly: true }, 
     description: { type: 'string', required: false, readonly: true } 
    } 
}; 

या कुछ और?

Answer 1

साइड-नोट: "आवश्यक" अब v4 में पेरेंट तत्व में एक सरणी है, और "केवल पढ़ने के लिए" अलग ढंग से अक्षर बड़ा है - मैं अपने उदाहरण के लिए उस प्रपत्र का उपयोग किया जाएगा

मैं मानता हूँ कि मान्य संग्रहीत डेटा बहुत दुर्लभ है। और यदि आप केवल डेटा का वर्णन कर रहे हैं, तो आपको यह निर्दिष्ट करने की आवश्यकता नहीं है कि "आईडी" आवश्यक है।

कहने की एक और बात यह है कि इन स्कीमा में सभी यूआरआई होना चाहिए जिन पर उन्हें संदर्भित किया जा सकता है (उदा। /schemas/baseSchema)। उस समय, आप "आईडी" उनमें से कुछ में आवश्यक बनाने के लिए स्कीमा का विस्तार कर सकते हैं:

var ownerInputSchema = { 
    type: 'object', 
    properties: { 
     id: {type: 'integer', readOnly: true}, 
     name: {type: 'string'}, 
     description: {type: 'string'} 
    }, 
    required: ['name'] 
}; 

var userInputSchema = { 
    allOf: [{"$ref": "/schemas/inputSchema"}], 
    properties: { 
     name: {readOnly: true} 
    } 
}; 

var storedSchema = { 
    allOf: [{"$ref": "/schemas/inputSchema"}], 
    required: ["id"] 
} 

हालांकि, जैसा कि मैंने ऊपर कहा, मुझे यकीन है कि storedSchema आवश्यक होना चाहिए नहीं कर रहा हूँ। जो आप समाप्त करते हैं वह एक "स्वामी" स्कीमा है जो डेटा प्रारूप का वर्णन करता है (जैसा कि सेवा करता है, और डेटा स्वामी द्वारा संपादन योग्य), और आपके पास एक द्वितीयक स्कीमा है जो अतिरिक्त संपत्ति पर readOnly घोषित करने के लिए विस्तारित करती है।

Answer 2

ठीक है, मुझे लगता है कि जेसन-स्कीमा का उद्देश्य v4 में अधिक स्पष्ट रूप से परिभाषित किया गया है।लक्ष्य आपको डेटा संरचना सत्यापन में सहायता करता है (चाहे वह संग्रहीत किया जा रहा है, यह आपको तार में भेजा गया है, या आप एक इंटरैक्टिव फैशन में बना रहे हैं)।

पढ़ा गया केवल एक जेसन-स्कीमा सत्यापन संपत्ति नहीं है क्योंकि इसकी सत्यापन बाधाएं नहीं हैं। जेसन-स्कीमा v4 में केवल पढ़ने के लिए हाइपर-स्कीमा परिभाषा का हिस्सा है। इसका उपयोग यह व्यक्त करने के लिए किया जा सकता है कि आप इस संपत्ति को POST अनुरोध में नहीं बदल सकते हैं।

जेसन-स्कीमा परिभाषित नहीं करता है कि आपको उपयोगकर्ता के साथ बातचीत को कैसे कार्यान्वित करना चाहिए, अगर आप "खराब" डेटा को स्थानांतरित करने की अनुमति देते हैं, या सिस्टम में अधिक डेटा जोड़ने से पहले किसी त्रुटि को सही किया जाना है। यह आप पर निर्भर करता है।