Content

Content किसी Content Type (खाँचा) से बनाया गया एक वास्तविक डेटा रिकॉर्ड है। कपड़ों की दुकान वाले ऑनलाइन स्टोर को उदाहरण मानें, तो Content Type "उत्पाद" यह तय करता है कि उत्पाद का नाम, कीमत, विस्तृत विवरण जैसे आइटम कैसे संरचित होंगे, और "Stainless Tumbler 500ml" एक ऐसा रिकॉर्ड है जो उस खाँचे का अनुसरण करने वाला एक Content है।

Content दो हिस्सों से मिलकर बनता है। fields में प्रत्येक field का वास्तविक मान रहता है, और sys में प्रकाशन, संस्करण, संग्रहण जैसी स्थितियाँ रहती हैं। CMA में Content एक Space का अधीनस्थ संसाधन है, और इसके पढ़ने व हटाने के पथ /spaces/{spaceId}/contents को, तथा बनाने व बदलने के पथ Content Type के अधीनस्थ /spaces/{spaceId}/content-types/{contentTypeId}/contents को आधार बनाते हैं। प्रबंधन कार्य CMA में किए जाते हैं, और प्रकाशित snapshot CDA के ज़रिए डिलीवर किया जाता है।

संसाधन संरचना

नीचे प्रकाशित Content "Stainless Tumbler 500ml" का एकल पठन प्रतिक्रिया है। sys (सिस्टम गुण) के साथ इसमें fields (field मान) और metadata (tag आदि अतिरिक्त जानकारी) भी होते हैं।

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP",
    "type": "Content",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
    "publish": {
      "version": 1,
      "at": "2026-06-18T09:51:44.128Z",
      "firstAt": "2026-06-18T09:51:44.128Z",
      "counter": 1,
      "by": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } }
    },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:51:14.597Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:51:44.128Z",
    "version": 2,
    "status": "Published"
  },
  "fields": {
    "price": { "en-US": 18000 },
    "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }
  },
  "metadata": { "tags": [] }
}

मुख्य keys:

• sys.id: Content का विशिष्ट पहचानकर्ता। यह एकल पठन, बदलने, हटाने व प्रकाशन पथों के {contentId} में जाता है।
• sys.contentType: इस Content द्वारा अनुसरित Content Type की ओर इंगित करने वाला Refer।
• fields: प्रत्येक field का मान। key field का apiName है, और मान locale-वार map है। नीचे field की key apiName है में इसकी व्याख्या है।
• metadata.tags: इस Content पर लगाए गए Tag की सूची। प्रत्येक आइटम Refer<Tag> आकार का है, और यदि कोई tag नहीं है तो यह खाली array [] होता है।

field की key apiName है

fields ऑब्जेक्ट की key प्रत्येक field का apiName है। यह Content Type की आंतरिक id या कंटेंट स्टूडियो में दिखने वाला field नाम (उदा. उत्पाद नाम) नहीं है। इसलिए Content बनाते या पढ़ते समय key के रूप में Content Type में परिभाषित apiName का प्रयोग करना चाहिए।

डेमो "उत्पाद" Content Type के fields और उनके apiName की मैपिंग इस प्रकार है।

प्रत्येक field मान locale-वार map है। मान का आकार localized के अनुसार भिन्न होता है।

• localized: true field { "<locale>": मान } के रूप में कई locale मान रख सकता है। उदा.: "productName": { "en-US": "Stainless Tumbler 500ml", "ko-KR": "스테인리스 텀블러 500ml" }।
• localized: false field (गैर-निर्भर field) में मान केवल Space के डिफ़ॉल्ट Locale की एक key में डाला जाता है। अन्य locale keys नहीं डाली जा सकतीं। चूँकि डेमो Space का डिफ़ॉल्ट Locale en-US है, इसलिए कीमत "price": { "en-US": 18000 } की तरह केवल एक en-US key रखती है।

डिफ़ॉल्ट Locale क्या है, required field को किस locale तक भरना है, और मान न होने पर fallback नियम, ये बहुभाषा (अवधारणा) में बताए गए हैं।

टाइप के अनुसार मान का आकार

locale key के भीतर जाने वाले मान का आकार field के type का अनुसरण करता है। अधिकांश टाइप उस टाइप का मान सीधे रखते हैं (टेक्स्ट टाइप में string, Number, Long में संख्या, Boolean में true/false)। जिनका आकार ऑब्जेक्ट या array होने के कारण भ्रम होना आसान है, वे टाइप इस प्रकार हैं।

• Location: { "latitude": <संख्या>, "longitude": <संख्या> } ऑब्जेक्ट है। latitude -90 से 90 तक, longitude -180 से 180 तक होता है, और दोनों keys अनिवार्य हैं। परिभाषित keys के अलावा कुछ स्वीकार नहीं होता, इसलिए lat, lng, lon जैसी छोटी keys का प्रयोग अस्वीकार कर दिया जाता है।
• Refer: मान लक्ष्य की ओर इंगित करने वाला Refer ऑब्जेक्ट है, और केवल id string नहीं बल्कि पूरा sys ऑब्जेक्ट डाला जाता है। यदि यह किसी अन्य Content की ओर इंगित करता है तो targetType Content होता है, और किसी Media की ओर इंगित करता है तो Media। Refer का आकार स्वयं सिस्टम गुण (sys) का Refer आकार में परिभाषित है।
• Array: तत्व टाइप के मानों को रखने वाला JSON array है। यदि तत्व टेक्स्ट हैं तो यह string का array होता है, और यदि तत्व Refer (Content या Media) हैं तो यह Refer ऑब्जेक्ट का array होता है। यह id string का array नहीं होता।

नीचे fields में जाने वाले मानों के उदाहरण हैं (Space का डिफ़ॉल्ट Locale en-US होने पर)।

{
  "location": { "en-US": { "latitude": 37.5662, "longitude": 126.9910 } },
  "tags": { "en-US": ["नया", "सीमित संस्करण"] },
  "photo": { "en-US": { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } },
  "photos": { "en-US": [ { "sys": { "type": "Refer", "id": "3trmXRM3RqbgSnifyg7PUl8DzDgDzP", "targetType": "Media" } } ] }
}

सिस्टम गुण (sys)

प्रत्येक Content अपने सामान्य सिस्टम गुणों को sys ऑब्जेक्ट में रखता है। space, contentType, createdBy, updatedBy Refer आकार ({ "sys": { "id", "type": "Refer", "targetType" } }) में आते हैं।

status निम्न 4 में से एक होता है।

publish ऑब्जेक्ट प्रकाशन स्थिति की ओर इंगित करने वाला पॉइंटर है। प्रकाशित होने पर इसमें निम्न सभी keys होती हैं।

प्रकाशन रद्द करने पर publish से version, at, by हट जाते हैं और केवल firstAt, counter बचते हैं। यदि एक बार भी प्रकाशित नहीं किया गया हो, तो publish { "counter": 0 } होता है।

archive ऑब्जेक्ट केवल संग्रहित होने पर मौजूद रहता है। संग्रहित होने पर इसमें version (संग्रहण के समय का sys.version), at (संग्रहण समय), by (संग्रहित करने वाला उपयोगकर्ता) होते हैं, और संग्रहित स्थिति में न होने पर archive key स्वयं नहीं होती।

नीचे के उदाहरण में sys.version और सभी समय मान वास्तविक कॉल के समय के मान हैं, और हर कॉल पर भिन्न होते हैं।

प्रकाशन, संस्करण और समवर्तीता

Content का जीवनचक्र इस प्रकार है।

• बनाने पर status Draft होता है। Content बनाते समय अपने-आप प्रकाशित नहीं होता। यह बात Content Type से भिन्न है। Content Type बनाने के साथ ही अपने-आप प्रकाशित हो जाता है, परंतु Content को डिलीवरी पथ पर आने के लिए एक अलग प्रकाशन कॉल चाहिए।
• प्रकाशित करने पर status Published हो जाता है।
• प्रकाशित करने के बाद बदलने पर status Changed हो जाता है। इसका अर्थ है कि अप्रकाशित बदलाव मौजूद हैं।
• प्रकाशन रद्द करने पर status फिर से Draft हो जाता है।
• संग्रहित करने के लिए पहले प्रकाशन रद्द करना ज़रूरी है। प्रकाशित स्थिति वाला Content सीधे संग्रहित नहीं किया जा सकता।

sys.version हर बदलाव पर 1 बढ़ता है।

बदलने, आंशिक बदलाव, प्रकाशन, प्रकाशन रद्द करने, संग्रहण और संग्रहण हटाने के अनुरोधों में x-weegloo-version header में वर्तमान sys.version भेजना ज़रूरी है। यदि यह मान छूट जाए या वर्तमान संस्करण से मेल न खाए, तो इसे समवर्ती बदलाव टकराव माना जाता है और अनुरोध अस्वीकार कर दिया जाता है। बनाने और हटाने के अनुरोधों में यह header नहीं होता। प्रकाशन, प्रकाशन रद्द करने, संग्रहण और संग्रहण हटाने जैसी स्थिति बदलावों में कोई अलग अनुरोध बॉडी नहीं होती।

मान सीमाएँ

field के मानों पर Content Type में लगाए गए validations के अलावा type द्वारा तय की गई प्लेटफ़ॉर्म-स्तरीय ऊपरी सीमा भी लगती है। प्रत्येक type की ऊपरी सीमा Content Type के field के प्रकार तालिका में है।

यह ऊपरी सीमा Content में मान लिखते समय जाँची जाती है, और प्रकाशित करते समय एक बार और जाँची जाती है। validations के size को इस ऊपरी सीमा से बड़ा नहीं लिखा जा सकता। जिस Content Type में ऐसा लिखा गया हो, वह सहेजते समय अस्वीकार हो जाता है (Content Type की त्रुटियाँ देखें)। इसलिए size चाहे जो भी हो, ShortText मान 65वें अक्षर से अस्वीकार हो जाता है।

प्रत्येक type की ऊपरी सीमा से अलग, एक Content के सभी टेक्स्ट मानों के कुल योग पर भी एक ऊपरी सीमा होती है। ShortText, LongText, RichText field के मानों की लंबाई को सभी field और सभी Locale में जोड़ने पर प्राप्त योग 102,400 अक्षर से अधिक नहीं हो सकता। उदाहरण के लिए, एक RichText field में पाँच Locale में से प्रत्येक के लिए 20,480 अक्षर का मान भरने पर, केवल उसी से कुल योग 102,400 अक्षर हो जाता है। Json और Array field के मान इस योग में नहीं गिने जाते। यह योग बनाने, बदलने और आंशिक बदलाव के समय जाँचा जाता है। आंशिक बदलाव में योग की गणना, न बदले गए field सहित, बदलाव लागू होने के बाद के पूरे परिणाम पर की जाती है।

validations की जाँच का समय आइटम के अनुसार भिन्न होता है। unique, mediaMimetypeGroup, mediaImageDimensions, mediaFileSize, referContentType की जाँच केवल प्रकाशन में होती है। शेष आइटमों तथा type और प्लेटफ़ॉर्म-स्तरीय ऊपरी सीमा की जाँच लिखने और प्रकाशन, दोनों में होती है। इसलिए लिखते समय पास हो चुका मान प्रकाशन में अस्वीकार हो सकता है।

Location और Refer परिभाषित keys के अलावा कुछ भी स्वीकार नहीं करते। lat जैसी संक्षिप्त key या sys के नीचे कोई अपरिचित key डालने पर वह अस्वीकार हो जाती है।

त्रुटियाँ

ये कोड field मानों की जाँच से निकलते हैं। प्रकाशन, संस्करण और स्थिति बदलाव से निकलने वाले कोड अभी इस तालिका में संकलित नहीं हैं। सभी संसाधनों में समान रूप से मिलने वाले कोड के लिए सामान्य त्रुटियाँ देखें।

API

नीचे के सभी endpoints का आधार URL https://cma.weegloo.com/v1 है, और Authorization header में CMA को प्रमाणित करने वाला Bearer टोकन ज़रूरी है। बदलने, आंशिक बदलाव, प्रकाशन, प्रकाशन रद्द करने, संग्रहण और संग्रहण हटाने में आशावादी समवर्तीता नियंत्रण के लिए X-Weegloo-Version header (वर्तमान संसाधन का sys.version) भी भेजना ज़रूरी है।

/contents सूची (GET /spaces/{spaceId}/contents) को fields.* से filter या sort करते समय, आपको उसे sys.contentType.sys.id={contentTypeId} से भी scope करना ज़रूरी है; अकेला contentType={contentTypeId} इसका विकल्प नहीं बनता। /content-types/{contentTypeId}/contents पथ में पहले से ही Content Type रखता है, इसलिए वहाँ इसकी ज़रूरत नहीं होती।

संबंधित दस्तावेज़

• Content Type: इस Content का खाँचा (field परिभाषा, apiName)।
• CDA Content: प्रकाशित Content को आगंतुकों तक डिलीवरी (पठन)।
• Tag: metadata.tags में लगाया जाने वाला वर्गीकरण लेबल।
• बहुभाषा (अवधारणा): डिफ़ॉल्ट Locale, अनिवार्य भराई, fallback।