YouTube Content ID API - बदलाव का इतिहास

ध्यान दें: YouTube Data API का इस्तेमाल, YouTube के कॉन्टेंट पार्टनर कर सकते हैं. यह सभी डेवलपर या YouTube के सभी उपयोगकर्ताओं के लिए उपलब्ध नहीं है. इसे ऐक्सेस करने के लिए, YouTube Content Manager खाते की ज़रूरत होती है. अगर आपके पास YouTube Content Manager खाता है, लेकिन आपको Google Cloud console में YouTube Data API, सेवाओं की सूची में नहीं दिख रहा है, तो अपने पार्टनर मैनेजर या पार्टनर सहायता टीम से संपर्क करें.

इस पेज पर, YouTube Content ID API में हुए बदलावों और दस्तावेज़ से जुड़े अपडेट की सूची दी गई है.

27 अगस्त, 2026

YouTube, सभी वीडियो फ़ॉर्मैट के लिए सार्वजनिक व्यू की गिनती करने के तरीके को एक जैसा करेगा. जैसे, लंबी अवधि के वीडियो, लाइव स्ट्रीम, और शॉर्ट वीडियो. वीडियो चलना शुरू होते ही, YouTube सार्वजनिक व्यू की गिनती शुरू कर देगा.

कमाई करने की ज़रूरी शर्तों और परफ़ॉर्मेंस की ज़्यादातर मुख्य मेट्रिक पर कोई असर नहीं पड़ता, क्योंकि ये मेट्रिक, दर्शकों की दिलचस्पी से जुड़ी मेट्रिक पर आधारित होती हैं. क्रिएटर की कमाई पहले की तरह ही "शॉर्ट वीडियो को मिले जुड़ाव वाले व्यू" और "जुड़ाव वाले देखने के घंटे" के हिसाब से तय की जाएगी. इन्हें YouTube Analytics > ऐडवांस मोड में देखा जा सकता है.

YouTube Partner Program में शामिल होने की ज़रूरी शर्तों में कोई बदलाव नहीं किया गया है. YouTube Partner Program में शामिल होने की ज़रूरी शर्तों को अब "शॉर्ट वीडियो को मिले व्यू" और "वीडियो देखने के मान्य घंटे" कहा जाएगा. पहले इन्हें "सार्वजनिक शॉर्ट वीडियो पर मिले मान्य व्यू" और "सार्वजनिक वीडियो देखने के मान्य घंटे" कहा जाता था.

ज़्यादा जानने के लिए, YouTube पर अपने कॉन्टेंट की परफ़ॉर्मेंस के बारे में जानना लेख पढ़ें.

मेट्रिक स्थिति ट्रिगर इनके लिए इस्तेमाल होता है
देखें अपडेट किया गया वीडियो पहले फ़्रेम से चलता है. इसमें अपने-आप चलने की सुविधा, पॉइंटर को वीडियो पर ले जाकर रोकना, और चलाने के लिए क्लिक/टैप करना शामिल है. सार्वजनिक तौर पर उपलब्ध व्यू की संख्या.
जुड़ाव वाले व्यू अपरिवर्तित. वीडियो पहले फ़्रेम के बाद भी चलता रहता है या उपयोगकर्ता, वीडियो चलाने के लिए क्लिक/टैप करता है. YouTube Partner Program के ज़रिए कमाई करने की सुविधा, ज़्यादातर मुख्य आंकड़ों (क्लिक मिलने की दर, वीडियो देखे जाने की औसत अवधि) और यूज़र ऐक्टिविटी की रिपोर्टिंग.
थंबनेल इंप्रेशन अपरिवर्तित. थंबनेल, उपयोगकर्ता के इंटरैक्शन या अपने-आप चलने की सुविधा के बिना दिखता है. यह फ़ीड-लेवल पर प्रॉडक्ट के दिखने और पैकेजिंग को मेज़र करता है.

4 अगस्त, 2026

YouTube Content ID API के दस्तावेज़ को अपडेट कर दिया गया है. इसमें, उन ऐसेट को अपडेट करने के लिए कार्रवाइयों का क्रम बताया गया है जिनका मालिकाना हक पहले से ही कॉन्टेंट के किसी दूसरे मालिक के पास है:

  • अगर किसी ऐसेट का मालिकाना हक पहले से ही कॉन्टेंट के किसी दूसरे मालिक के पास है, तो आपको ownership.update या ownership.patch का इस्तेमाल करके, ऐसेट पर अपना मालिकाना हक जोड़ना होगा. इसके बाद ही, ऐसेट का मेटाडेटा सेट या अपडेट किया जा सकेगा. साथ ही, मिलते-जुलते वीडियो से जुड़ी नीति सेट की जा सकेगी.
  • अगर मालिकाना हक का दावा करने से पहले, मेटाडेटा (assets.update या assets.patch) या मैच करने की नीति (assetMatchPolicy.update या assetMatchPolicy.patch) को अपडेट करने की कोशिश की जाती है, तो अनुरोध पूरा नहीं होगा और PERMISSION_DENIED गड़बड़ी दिखेगी.
  • किसी ऐसेट के लेबल अपडेट करना गाइड को अपडेट कर दिया गया है. इसमें, किसी दूसरे कॉन्टेंट क्रिएटर के मालिकाना हक वाली ऐसेट में लेबल जोड़ने के सिलसिलेवार निर्देश दिए गए हैं.

26 मार्च, 2025

YouTube, 31 मार्च, 2025 से शॉर्ट वीडियो पर मिलने वाले व्यू की गिनती करने का तरीका बदल देगा. पहले, शॉर्ट वीडियो को कुछ सेकंड तक चलाने के बाद ही उसे व्यू के तौर पर गिना जाता था. अब व्यू की गिनती इस आधार पर की जाएगी कि आपका कोई शॉर्ट वीडियो कितनी बार चलाया गया है या उसे फिर से देखने के लिए कितनी बार चलाया गया है. इस पर वीडियो देखने के कम से कम समय से जुड़ी कोई शर्त लागू नहीं होगी. ज़्यादा जानें

इस बदलाव के मुताबिक, Content ID API को 30 जून, 2025 तक इन तरीकों से अपडेट किया जाएगा:

  • claimSearch.list.sort के लिए, क्रम से लगाने के ऑर्डर अपडेट किए जाएंगे:
    • DAILY_ENGAGED_VIEWS को व्यू की संख्या गिनने के पुराने तरीके के आधार पर, रोज़ाना के व्यू की संख्या के लिए जोड़ा जाएगा.
    • LIFETIME_ENGAGED_VIEWS को व्यू की कुल संख्या में जोड़ दिया जाएगा. यह संख्या, व्यू की गिनती करने के पुराने तरीके के हिसाब से तय की जाएगी.
  • assetSearch.list.sort के लिए, क्रम से लगाने के ऑर्डर अपडेट किए जाएंगे:
    • DAILY_ENGAGED_VIEWS को व्यू की संख्या गिनने के पुराने तरीके के आधार पर, रोज़ाना के व्यू की संख्या के लिए जोड़ा जाएगा.

इस बदलाव के मुताबिक, Content ID API को 30 सितंबर, 2025 तक इन तरीकों से अपडेट किया जाएगा:

  • assetSearch.list.sort क्रम से लगाने का तरीका VIEWS अब इस्तेमाल नहीं किया जा सकेगा.
  • claimSearch.list.sort क्रम से लगाने का तरीका VIEW_COUNT अब इस्तेमाल नहीं किया जा सकेगा.
  • claimSearch.claimSnippet.videoViews को अपडेट किया जाएगा, ताकि शॉर्ट वीडियो को मिले व्यू की संख्या की गिनती करने के अपडेट किए गए तरीके को दिखाया जा सके.
  • claimSearch.claimSnippet.engagedViews को व्यू की संख्या गिनने के पुराने तरीके के आधार पर जोड़ा जाएगा

14 जनवरी, 2025

videoAdvertisingOption संसाधन के autoGeneratedBreaks[] फ़ील्ड को अपडेट कर दिया गया है. अब हम ad_breaks और autoGeneratedBreaks को एक साथ उपलब्ध कराने की अनुमति देते हैं. अगर adBreaks तय किए गए वीडियो पर autoGeneratedBreaks को 'सही' पर सेट किया जाता है, तो हमारे सिस्टम, मैन्युअल तरीके से तय किए गए ऐड स्लॉट के अलावा, विज्ञापन दिखाने के लिए जगहें ढूंढेंगे. ज़्यादा जानकारी के लिए, सहायता लेख देखें.

10 नवंबर, 2023

videoAdvertisingOption संसाधन के adFormats[] फ़ील्ड को अपडेट कर दिया गया है, ताकि उस फ़ील्ड के लिए सिर्फ़ third_party मान्य वैल्यू हो. अब इन विज्ञापन फ़ॉर्मैट का इस्तेमाल नहीं किया जा सकता: instream_trueview, instream_standard, display, preroll, postroll. ज़्यादा जानकारी के लिए, सहायता लेख देखें.

1 जून, 2023

ध्यान दें: यह सुविधा बंद होने की सूचना है.

इस अपडेट में ये बदलाव शामिल हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • videoAdvertisingOption संसाधन के breakPosition[] फ़ील्ड को बंद कर दिया गया है. इसे साल 2024 में हटा दिया जाएगा.
      videoAdvertisingOptions.update और videoAdvertisingOptions.patch तरीके पहले से ही फ़ील्ड को अनदेखा करते हैं.
    • videoAdvertisingOption संसाधन के adBreaks[].slot[] फ़ील्ड को हटा दिया गया है. यह फ़ील्ड अब इस्तेमाल में नहीं है.
    • asset संसाधन के बंद किए गए category और showCustomId फ़ील्ड हटा दिए गए हैं.
    • नए claim संसाधन के timeStatusLastModified फ़ील्ड से पता चलता है कि दावे में पिछली बार कब बदलाव किया गया था.
    • claimSearch.list तरीके के isVideoShortsEligible पैरामीटर का इस्तेमाल करके, दावा किए गए वीडियो को YouTube Shorts की ज़रूरी शर्तों के हिसाब से फ़िल्टर किया जा सकता है.

  • नए संसाधन और तरीके

    • अब एपीआई, YouTube Music के संसाधनों को लिस्ट करने की सुविधा देता है:

20 दिसंबर, 2022

assetSearch.list तरीके के ownershipRestriction क्वेरी पैरामीटर की परिभाषा को अपडेट किया गया है. इससे यह साफ़ तौर पर पता चलता है कि अगर उस पैरामीटर की वैल्यू none है, तो metadataSearchFields पैरामीटर की वैल्यू में कम से कम एक आईडी फ़िल्टर का इस्तेमाल किया जाना चाहिए. दस्तावेज़ में किए गए इस बदलाव से, एपीआई के काम करने के तरीके में कोई बदलाव नहीं होता.

9 नवंबर, 2022

asset.get और asset.list तरीकों के दस्तावेज़ अपडेट किए गए हैं. इससे यह साफ़ तौर पर बताया गया है कि इनके लिए एक से ज़्यादा वैल्यू कैसे काम करती हैं:

28 सितंबर, 2022

लाइसेंस देने की सुविधा से जुड़ी जानकारी को asset resource में जोड़ दिया गया है.

18 जुलाई, 2022

claimSearch.list तरीके के दस्तावेज़ को inactiveReasons YouTube Studio के साथ अनुकूलता के लिए सुधारों को दर्शाने के लिए अपडेट किया गया है:

  • Studio ने पहले ही Audio Swap और Song Erase के लिए सहायता बंद कर दी थी. एपीआई की वैल्यू, audio_removed और song_erased को चुपचाप अनदेखा कर दिया गया था. अब इन्हें दस्तावेज़ में शामिल नहीं किया गया है.
  • channel_whitelisted को channel_allowlisted से बदल दिया गया है. पिछली वैल्यू के बारे में अब दस्तावेज़ में जानकारी नहीं दी गई है, लेकिन यह अब भी काम करती है.
  • अब closed_disabled_monetization, closed_manually, closed_no_adsense, closed_own_video_match, reference_removed, replaced, और video_modified वैल्यू इस्तेमाल की जा सकती हैं.

14 जून, 2022

assetSearch संसाधन के दस्तावेज़ को अपडेट किया गया है, ताकि दो नई प्रॉपर्टी दिख सकें: isrcs[] और iswcs[]. नई isrcs[] और iswcs[] प्रॉपर्टी की वैल्यू में, स्ट्रिंग वैल्यू की एक कैटगरी होती है. हर वैल्यू, खोज के नतीजे से पहचाने गए ऐसेट से मैप होने वाले आईएसआरसी या आईएसडब्ल्यूसी के बारे में बताती है.

assetSearch संसाधनों में पहले से शामिल isrc और iswc प्रॉपर्टी के बजाय, नई प्रॉपर्टी इस्तेमाल करने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि नई प्रॉपर्टी से ज़्यादा सटीक डेटा मिलता है. नई प्रॉपर्टी में स्ट्रिंग वैल्यू की एक सरणी शामिल हो सकती है. वहीं, isrc और iswc प्रॉपर्टी, खोज नतीजे से जुड़े सिर्फ़ एक आईएसआरसी या आईएसडब्ल्यूसी कोड की पहचान करती हैं.

12 मई, 2022

क्लाइंट लाइब्रेरी के लिंक अपडेट किए गए हैं, ताकि वे Google APIs की स्टैंडर्ड क्लाइंट लाइब्रेरी पर रीडायरेक्ट हो सकें. PHP के लिए, पहले से जनरेट किए गए बाइंडिंग को अपडेट किया गया.

3 मई, 2022

claimSearch.list तरीके का status पैरामीटर अब संभावित दावे की जानकारी के आधार पर ज़्यादा फ़िल्टर के साथ काम करता है.

May 2, 2022

assetSearch.list तरीके के जवाब के दस्तावेज़ को अपडेट किया गया है, ताकि AIP-158 के साथ अनुकूलता के लिए बढ़ोतरी को दिखाया जा सके:

  • pageInfo.totalResults के ब्यौरे में साफ़ तौर पर बताया गया है कि वैल्यू एक अनुमान है, असल वैल्यू नहीं
  • pageInfo.resultsPerPage और pageInfo.startIndex फ़ील्ड हटा दिए गए हैं

25 अप्रैल, 2022

assetLabels.list संसाधन के दस्तावेज़ को अपडेट किया गया है. इससे labelPrefix और q अनुरोध पैरामीटर के बारे में साफ़ तौर पर बताया गया है. साथ ही, यह भी बताया गया है कि अनुरोध / जवाब में पेज नंबरिंग की सुविधा काम करती है.

8 दिसंबर, 2021

claimSearch.list संसाधन के दस्तावेज़ को अपडेट कर दिया गया है. इससे, इस्तेमाल के उन दो तरीकों के बारे में सही जानकारी मिलती है जिनके लिए इस तरीके का इस्तेमाल किया जाता है:

  • आईडी (ऐसेट, रेफ़रंस या वीडियो) या क्वेरी स्ट्रिंग के हिसाब से खोजें
  • दावा बनाने की तारीख, बदलाव की तारीख या स्थिति के हिसाब से खोजें

इस्तेमाल के हर उदाहरण के लिए, क्वेरी पैरामीटर का अलग सेट काम करता है. claimSearch.list तरीके के दस्तावेज़ को अपडेट कर दिया गया है. इसमें बताया गया है कि इस्तेमाल के हर तरीके के लिए, कौनसे पैरामीटर काम करते हैं.

17 नवंबर, 2021

इस अपडेट में ये बदलाव शामिल हैं:

  • claims.update तरीके से, अब ऐसे दावे का स्टेटस active पर अपडेट किया जा सकता है जो अभी तक स्वीकार नहीं किया गया है या जिसे स्वीकार किया जा सकता है. claim संसाधन की status प्रॉपर्टी की परिभाषा में ज़्यादा जानकारी दी गई है.
  • claim और claimSearch संसाधनों के दस्तावेज़ को अपडेट कर दिया गया है. इसमें नया studioInfo ऑब्जेक्ट जोड़ा गया है. इसमें दावे से जुड़े YouTube Studio पेजों के लिंक शामिल हैं.
  • claimSearch.list तरीके के origin पैरामीटर के लिए इस्तेमाल की जा सकने वाली वैल्यू की सूची बदल गई है. अब इस पैरामीटर के लिए, चार और वैल्यू इस्तेमाल की जा सकती हैं: batchTool, inProductShorts, melodyMatch, और youTubeAdmin. इसके अलावा, dropboxUpload और webUpload वैल्यू का इस्तेमाल नहीं किया जा सकता.

26 फ़रवरी, 2021

claimSearch.list तरीके के videoId पैरामीटर के दस्तावेज़ को अपडेट कर दिया गया है. इसमें बताया गया है कि पैरामीटर की वैल्यू में अब ज़्यादा से ज़्यादा 10 वीडियो आईडी शामिल किए जा सकते हैं. इन आईडी को कॉमा लगाकर अलग किया जाता है. अगर वैल्यू में 10 से ज़्यादा वीडियो आईडी शामिल हैं, तो एपीआई badRequest गड़बड़ी — 400 एचटीटीपी रिस्पॉन्स कोड — दिखाएगा.

6 दिसंबर, 2018

ध्यान दें: यह सुविधा बंद होने की सूचना है.

एपीआई के दस्तावेज़ को अपडेट कर दिया गया है, ताकि contentOwnerAdvertisingOptions संसाधन और उसके तरीकों के रेफ़रंस हटाए जा सकें. इन तरीकों का इस्तेमाल बहुत कम किया गया था. साथ ही, एपीआई का इस्तेमाल करने वाले जिन लोगों ने इनका इस्तेमाल किया था उन्हें इस सूचना से पहले अलग से संपर्क किया गया था.

21 मार्च, 2018

इस अपडेट में ये बदलाव किए गए हैं:

  • अब म्यूज़िक वीडियो या साउंड रिकॉर्डिंग ऐसेट को शामिल, अपडेट या पैच करते समय, metadataMine.artist प्रॉपर्टी को सेट करना ज़रूरी है. अगर इन संसाधन टाइप के लिए प्रॉपर्टी सेट नहीं की गई है, तो एपीआई अब गड़बड़ी का मैसेज दिखाता है. इसके अलावा, ध्यान दें कि metadataMine.artist प्रॉपर्टी सिर्फ़ म्यूज़िक वीडियो और साउंड रिकॉर्डिंग कलाकारों के लिए उपलब्ध है.

24 जुलाई, 2017

इस अपडेट में ये बदलाव किए गए हैं:

  • नई package रिसॉर्स, वेब, एसएफ़टीपी या डिलीवरी के किसी अन्य तरीके से डिलीवर की गई फ़ाइलों के ग्रुप को दिखाता है. इस संसाधन के लिए, एपीआई दो तरीकों का इस्तेमाल करता है:

    • package.insert तरीके से, सिर्फ़ मेटाडेटा वाले पैकेज की पुष्टि की जाती है और उसे अपलोड किया जाता है. इस पैकेज में सिर्फ़ एक मेटाडेटा फ़ाइल होती है.
    • package.get तरीके से, पहले अपलोड किए गए पैकेज के बारे में जानकारी मिलती है.

  • validator.validate तरीके के लिए, uploaderName प्रॉपर्टी की परिभाषा को अपडेट किया गया है. इसमें बताया गया है कि वैल्यू से, डेटा अपलोड करने वाले कॉन्टेंट पार्टनर की पहचान नहीं होती. इसके बजाय, यह web-google या yt-google जैसी वैल्यू होती है, जिससे उस खास अपलोडर खाते की पहचान होती है जिसका इस्तेमाल कॉन्टेंट का मालिक कर रहा है.

  • reference संसाधन की status प्रॉपर्टी, अब duplicate_on_hold वैल्यू का इस्तेमाल नहीं करती. इसका इस्तेमाल यह बताने के लिए किया जाता था कि कोई रेफ़रंस, किसी दूसरे रेफ़रंस का डुप्लीकेट है. इसके बजाय, अगर कोई रेफ़रंस डुप्लीकेट है, तो अब status प्रॉपर्टी की वैल्यू inactive पर सेट हो जाती है. साथ ही, statusReason प्रॉपर्टी की वैल्यू REASON_DUPLICATE_FOR_OWNERS होती है.

    हालांकि, पहले की तरह ही, संसाधन की duplicateLeader प्रॉपर्टी सिर्फ़ तब भरी जाती है, जब रेफ़रंस डुप्लीकेट हो. अगर इसे सेट किया जाता है, तो उस प्रॉपर्टी की वैल्यू से डुप्लीकेट रेफ़रंस की पहचान होती है.

17 अप्रैल, 2017

इस अपडेट में ये बदलाव किए गए हैं:

  • नया assetShare संसाधन, सिर्फ़ कंपोज़िशन ऐसेट के लिए काम करता है. इससे किसी ऐसेट संसाधन के दो वर्शन के बीच के संबंध की पहचान होती है. ये प्रजेंटेशन, डेटा पब्लिश करने के नए मॉडल के हिसाब से तैयार किए गए हैं. इस मॉडल को इसलिए बनाया गया है, ताकि लोग, साउंड रिकॉर्डिंग ऐसेट से जुड़े अपने अधिकारों के बारे में बेहतर तरीके से समझ पाएं और उन पर बेहतर कंट्रोल रख पाएं.

    नए मॉडल में, हर साउंड रिकॉर्डिंग को सिर्फ़ एक यूनीक ऐसेट पर मैप किया जाता है. इसे कंपोज़िशन व्यू कहा जाता है. उस ऐसेट का मेटाडेटा, जानकारी का कैननिकल सेट होता है. YouTube, किसी रिकॉर्डिंग से जुड़े कंपोज़िशन के अधिकारों के बारे में यह जानकारी दिखाता है. यह जानकारी, कई डेटा प्रोवाइडर से मिल सकती है.

    इसके अलावा, कंपोज़िशन के हर मालिक के पास अपनी कंपोज़िशन शेयर ऐसेट होती है. कंपोज़िशन शेयर से पता चलता है कि किसी पब्लिशर ने कंपोज़िशन ऐसेट के लिए कौनसी जानकारी दी है. कंपोज़िशन शेयर को कई साउंड रिकॉर्डिंग से जोड़ा जा सकता है.

    assetShare संसाधन, कंपोज़िशन व्यू और कंपोज़िशन शेयर के बीच के संबंध की पहचान करता है. assetShares.list के नए तरीके से, इनमें से कोई एक काम किया जा सकता है:

    • कंपोज़िशन व्यू का आईडी उपलब्ध कराता है. साथ ही, अनुरोध करने वाले पार्टनर के मालिकाना हक वाले कंपोज़िशन शेयर को वापस पाता है. हालांकि, ऐसा तब होता है, जब ऐसा शेयर मौजूद हो.
    • कॉन्टेंट पार्टनर के मालिकाना हक वाली कंपोज़िशन शेयर का आईडी उपलब्ध कराएं और उन सभी कंपोज़िशन व्यू की सूची पाएं जिनसे वह शेयर लिंक है.

  • कंपोज़िशन ऐसेट मैनेज करना से जुड़ी नई गाइड में बताया गया है कि अलग-अलग एपीआई तरीके, अनुरोधों को कैसे हैंडल करते हैं. यह इस बात पर निर्भर करता है कि उन तरीकों को सबमिट किए गए ऐसेट आईडी, कंपोज़िशन व्यू या कंपोज़िशन शेयर की पहचान करते हैं या नहीं.

  • contentOwnerAdvertisingOptions संसाधन की नई claimedVideoOptions.autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि क्या YouTube को, दावा किए गए उन वीडियो में विज्ञापन के लिए ब्रेक अपने-आप जनरेट करने चाहिए जिनकी अवधि 10 मिनट से ज़्यादा है. इस प्रॉपर्टी का असर, कॉन्टेंट के मालिक के उन सभी वीडियो पर पड़ता है जो 10 मिनट से ज़्यादा लंबे हैं. हालांकि, अगर किसी वीडियो पर एक से ज़्यादा दावे किए गए हैं, तो वीडियो पर दावा करने वाला पहला पार्टनर, उस वीडियो के लिए इस प्रॉपर्टी का डिफ़ॉल्ट व्यवहार सेट करता है.

11 अगस्त, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • हाल ही में पब्लिश की गई YouTube API सेवाओं की सेवा की शर्तों ("अपडेट की गई शर्तें") के बारे में YouTube इंजीनियरिंग और डेवलपर ब्लॉग पर विस्तार से बताया गया है. इसमें, सेवा की मौजूदा शर्तों से जुड़े कई अपडेट दिए गए हैं. अपडेट किए गए नियमों के अलावा, इस अपडेट में कई सहायक दस्तावेज़ भी शामिल हैं. ये दस्तावेज़, उन नीतियों को समझने में मदद करेंगे जिनका पालन डेवलपर को करना होगा. ये नियम 10 फ़रवरी, 2017 से लागू होंगे.

    अपडेट किए गए नियमों के लिए बदलाव का इतिहास में, नए दस्तावेज़ों के पूरे सेट के बारे में बताया गया है. इसके अलावा, अपडेट की गई शर्तों या उनसे जुड़े दस्तावेज़ों में आने वाले समय में होने वाले बदलावों के बारे में भी, बदलाव के इतिहास में बताया जाएगा. उस दस्तावेज़ में मौजूद लिंक से, बदलाव के इतिहास में हुए बदलावों की सूची वाले आरएसएस फ़ीड की सदस्यता ली जा सकती है.

31 मई, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • validator.validate तरीके से यह पता लगाया जा सकता है कि मेटाडेटा फ़ाइल में पुष्टि से जुड़ी ऐसी गड़बड़ियां तो नहीं हैं जिनकी वजह से YouTube इसे प्रोसेस नहीं कर पाएगा. अगर फ़ाइल में गड़बड़ियां हैं, तो एपीआई के जवाब की errors प्रॉपर्टी में पुष्टि करने से जुड़ी गड़बड़ियों की सूची होती है. इससे हर गड़बड़ी की गंभीरता, वजह, और जगह की पहचान की जा सकती है.

  • नई और अपडेट की गई गड़बड़ियां

    • assets.patch और assets.update तरीके अब इस गड़बड़ी के साथ काम करते हैं. याद रखें कि एक ही तरह की गड़बड़ी वाली कई गड़बड़ियों को ठीक करने के लिए, एक ही तरीके का इस्तेमाल किया जा सकता है. हर तरीके के लिए गड़बड़ी से जुड़े दस्तावेज़ देखें. इसके अलावा, संभावित गड़बड़ियों की पूरी सूची देखने के लिए, गड़बड़ियां पेज पर जाएं.

      गड़बड़ियां
      invalidValue (400) parameters.assetId
      अनुरोध पूरा नहीं किया जा सका, क्योंकि अपडेट की जा रही ऐसेट को किसी दूसरी ऐसेट के साथ मर्ज कर दिया गया है. उस ऐसेट के आईडी का इस्तेमाल करके अनुरोध को फिर से सबमिट करें. यह आईडी, गड़बड़ी के मैसेज में assetId पैरामीटर की वैल्यू के तौर पर दिखाया जाता है.

28 मार्च, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • claim संसाधन की नई matchInfo.matchSegments[] प्रॉपर्टी में एक सूची होती है. इसमें हर आइटम, दावे वाले वीडियो के उस सेगमेंट के बारे में बताता है जो पहचान वीडियो के किसी हिस्से से मेल खाता है. किसी दावे के लिए, मिलते-जुलते कई सेगमेंट हो सकते हैं. उदाहरण के लिए, अगर अपलोड किए गए वीडियो का ऑडियो और वीडियो कॉन्टेंट, रेफ़रंस वीडियो के ऑडियो और वीडियो कॉन्टेंट से मेल खाता है, तो मिलते-जुलते वीडियो के दो सेगमेंट होंगे. एक सेगमेंट में ऑडियो मैच के बारे में बताया जाएगा और दूसरे में वीडियो मैच के बारे में.

      हर मैच सेगमेंट के लिए, API, मिलते-जुलते कॉन्टेंट की अवधि और टाइप (ऑडियो या वीडियो) दिखाता है. एपीआई, टाइम ऑफ़सेट की भी पहचान करता है. इससे यह पता चलता है कि दावा किए गए वीडियो और रेफ़रंस वीडियो, दोनों में मिलते-जुलते वीडियो का हर सेगमेंट कब शुरू और खत्म होता है.

    • contentOwnerAdvertisingOptions.patch या contentOwnerAdvertisingOptions.update तरीकों को कॉल करने पर, अब contentOwnerAdvertisingOptions संसाधन की claimedVideoOptions.newVideoDefaults[] प्रॉपर्टी की वैल्यू अपडेट की जा सकती है.

    • contentOwnerAdvertisingOptions संसाधन की सिर्फ़ पढ़ने के लिए उपलब्ध allowedOptions.autoGeneratedBreaks प्रॉपर्टी अब काम नहीं करती है.

  • नई और अपडेट की गई गड़बड़ियां

    • एपीआई के claims.update तरीके में अब यह गड़बड़ी ठीक की जा सकती है. याद रखें कि एक ही तरह की गड़बड़ी वाली कई गड़बड़ियों को ठीक करने के लिए, एक ही तरीके का इस्तेमाल किया जा सकता है. हर तरीके के लिए गड़बड़ी से जुड़े दस्तावेज़ देखें. इसके अलावा, संभावित गड़बड़ियों की पूरी सूची देखने के लिए, गड़बड़ियां पेज पर जाएं.

      गड़बड़ियां
      badRequest (400) alreadyClaimed
      यह दावा, किसी मौजूदा दावे का डुप्लीकेट है. इसे अपडेट नहीं किया जा सकता.

    • assets.list तरीके का इस्तेमाल करने पर, कभी-कभी टाइम आउट हो जाता है और 500 एचटीटीपी रिस्पॉन्स कोड (Internal Server Error) मिलता है. ऐसा खास तौर पर तब होता है, जब अनुरोध में कई ऐसेट का डेटा वापस मिलता है और fetchMatchPolicy पैरामीटर की वैल्यू effective होती है. अगर आपके assets.list अनुरोध में कई ऐसेट आईडी दिए गए हैं और 500 गड़बड़ी का मैसेज दिखता है, तो किसी एक ऐसेट या कम संख्या में ऐसेट के लिए अनुरोध फिर से सबमिट करें.

    • references.insert गड़बड़ी के दस्तावेज़ को अपडेट किया गया है. इसमें बताया गया है कि अगर अनुरोध में खराब हुई रेफ़रंस फ़ाइल अपलोड की जाती है, तो उस समस्या का पता तब तक नहीं चलता, जब तक रेफ़रंस फ़ाइल प्रोसेस नहीं हो जाती. इसलिए, भले ही references.insert अनुरोध से सही जवाब मिले, लेकिन हो सकता है कि रेफ़रंस को प्रोसेस न किया जा सके. हमारा सुझाव है कि रेफ़रंस डालने के बाद, references.list तरीके का इस्तेमाल करके पोल करें. इससे यह पुष्टि की जा सकेगी कि रेफ़रंस उम्मीद के मुताबिक चालू हो गया है.

3 फ़रवरी, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • अब एपीआई के साथ, प्रॉडक्ट लिस्टिंग विज्ञापनों का इस्तेमाल किया जा सकता है. प्रॉडक्ट लिस्टिंग विज्ञापन, वीडियो के कॉन्टेंट में दिखाए गए या उससे जुड़े प्रॉडक्ट को हाइलाइट करते हैं. ये विज्ञापन, वीडियो के दौरान दिखाए जाने वाले प्रायोजित कार्ड होते हैं. कार्ड, विज्ञापन सिस्टम की तरफ़ से अपने आप जोड़े जाते हैं. दर्शकों को कुछ सेकंड तक कार्ड का टीज़र दिखाई देता है और वे वीडियो के ऊपरी दाएं किनारे पर स्थित आइकॉन पर क्लिक करके भी कार्ड ब्राउज़ कर सकते हैं.

      इस बदलाव के बाद, product_listing को अब इन प्रॉपर्टी की वैल्यू में शामिल किया जा सकता है:

      संसाधन/एपीआई मेथड प्रॉपर्टी
      contentOwnerAdvertisingOptions allowedOptions.licAdFormats[]
      contentOwnerAdvertisingOptions allowedOptions.ugcAdFormats[]
      contentOwnerAdvertisingOptions claimedVideoOptions.newVideoDefaults[]
      videoAdvertisingOptions adFormats[]
      videoAdvertisingOptions.getEnabledAds countriesRestriction[].adFormats[]

    • assetSearch.list तरीके के नए createdBefore और createdAfter, एपीआई को सिर्फ़ किसी तारीख से पहले और/या बाद में बनाई गई ऐसेट दिखाने का निर्देश देते हैं.

    • assetSearch.list के अनुरोध के लिए एपीआई के जवाब में, type प्रॉपर्टी अब art_track_video वैल्यू के साथ काम करती है. आर्ट ट्रैक वीडियो के बारे में ज़्यादा जानकारी के लिए, YouTube सहायता केंद्र पर जाएं.

    • claimSearch.list तरीके में, ये नए पैरामीटर इस्तेमाल किए जा सकते हैं:

      पैरामीटर
      referenceId इस फ़िल्टर पैरामीटर से, उस पहचान फ़ाइल का YouTube आईडी पता चलता है जिसके लिए दावे वापस लाए जा रहे हैं.
      inactiveReasons यह पैरामीटर इस्तेमाल करना ज़रूरी नहीं है. इसकी मदद से, एपीआई से मिले जवाब में सिर्फ़ उन दावों को शामिल किया जा सकता है जो अब मान्य नहीं हैं. ऐसा उन वजहों के आधार पर किया जाता है जिनकी वजह से दावे अमान्य हुए हैं. पैरामीटर की परिभाषा में, उन दावों के टाइप की सूची दी गई है जिनके लिए खोज की जा सकती है.
      partnerUploaded यह एक वैकल्पिक बूलियन पैरामीटर है. इसकी मदद से, यह तय किया जा सकता है कि एपीआई से मिले जवाब में, सिर्फ़ पार्टनर के अपलोड किए गए दावे शामिल होने चाहिए या पार्टनर के अपलोड नहीं किए गए दावे शामिल होने चाहिए.

    • reference संसाधन के नए references#origination ऑब्जेक्ट में ऐसी जानकारी होती है जिससे रेफ़रंस के सोर्स के बारे में पता चलता है.

    • references.insert तरीके से, अब YouTube के gfp_gen सॉफ़्टवेयर का इस्तेमाल करके जनरेट किए गए रेफ़रंस अपलोड किए जा सकते हैं. अगर आपने पहले से जनरेट किया गया फ़िंगरप्रिंट दिया है, तो अपलोड किए गए reference संसाधन में fpDirect प्रॉपर्टी की वैल्यू को true पर सेट करें.

      ध्यान दें कि इस बदलाव के बाद, रेफ़रंस अपलोड करते समय fpDirect प्रॉपर्टी सेट करने की कोशिश करने पर, एपीआई अब गड़बड़ी नहीं दिखाता है.

  • नई और अपडेट की गई गड़बड़ियां

    दस्तावेज़ में अब whitelist संसाधन के तरीकों से मिली गड़बड़ियों की सूची दी गई है.

    इसके अलावा, यहां दी गई टेबल में उन नई गड़बड़ियों के बारे में बताया गया है जिन्हें एपीआई सपोर्ट करता है. साथ ही, उन तरीकों के बारे में बताया गया है जिनसे हर गड़बड़ी दिख सकती है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है. ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    गड़बड़ियां
    badRequest (400) inappropriateCampaignTarget
    अगर कोई कैंपेन ऐसा वीडियो दिखाने की कोशिश करता है जो कुछ लोगों के लिए सही नहीं है, तो campaigns.insert और campaigns.update तरीके यह गड़बड़ी दिखाते हैं. इस गड़बड़ी को ठीक करने के लिए, कृपया दिखाने के लिए कोई दूसरा कॉन्टेंट चुनें.
    badRequest (400) canNotCreatePartnerUploadedClaimOnCompositionOrSoundRecordingAssets
    अगर कंपोज़िशन या साउंड रिकॉर्डिंग ऐसेट के साथ पार्टनर के ज़रिए अपलोड किया गया दावा बनाने की कोशिश की जाती है, तो claims.insert तरीके से यह गड़बड़ी दिखती है.
    badRequest (400) existingSoundRecordingOrMusicVideoClaim
    अगर बताए गए वीडियो में रिकॉर्ड किए गए संगीत पर पहले से कोई दावा मौजूद है, तो claims.insert तरीके से यह गड़बड़ी दिखती है. एपीआई के ज़रिए, सीधे तौर पर कंपोज़िशन के दावे नहीं जोड़े जा सकते.
    badRequest (400) asset_id
    अगर अनुरोध में किसी फ़ाइल के ज़रिए रेफ़रंस बनाने की कोशिश की गई है, लेकिन अनुरोध में assetId के बारे में नहीं बताया गया है, तो references.insert तरीके से यह गड़बड़ी दिखती है.
    badRequest (400) canNotBeActivated
    अगर रेफ़रंस को चालू नहीं किया जा सकता है, तो references.update तरीके से यह गड़बड़ी दिखती है. ऐसा रेफ़रंस की स्थिति या मालिकाना हक की शर्तों की वजह से हो सकता है.
    badRequest (400) videoNotClaimed
    अगर आपने उस वीडियो पर दावा नहीं किया है जिसके लिए आपको विज्ञापन दिखाने के विकल्प चाहिए, तो videoAdvertisingOptions.get तरीके से यह गड़बड़ी दिखती है. इससे आपको अनुरोध की गई जानकारी नहीं मिल पाती.

18 दिसंबर, 2015

यूरोपियन यूनियन (ईयू) के कानूनों के मुताबिक, ईयू में रहने वाले असली उपयोगकर्ताओं को कुछ जानकारी देना और उनसे सहमति लेना ज़रूरी है. इसलिए, यूरोपीय संघ में रहने वाले असली उपयोगकर्ताओं के लिए, आपको ईयू उपयोगकर्ता की सहमति से जुड़ी नीति का पालन करना होगा. हमने इस ज़रूरी शर्त की सूचना, YouTube API की सेवा की शर्तों में जोड़ दी है.

21 अप्रैल, 2015

इस अपडेट में ये बदलाव किए गए हैं:

  • नई campaign रिसॉर्स, किसी खास कॉन्टेंट के मालिक के कैंपेन को दिखाता है. इससे कॉन्टेंट का मालिक, दावा किए गए और उपयोगकर्ता के अपलोड किए गए वीडियो पर एनोटेशन का इस्तेमाल करके कॉन्टेंट का प्रमोशन कर सकता है. उदाहरण के लिए, कॉन्टेंट का मालिक ऐसा कैंपेन बना सकता है जो दावा किए गए, उपयोगकर्ता के अपलोड किए गए उन वीडियो में किसी फ़िल्म के वॉच पेज के लिंक जोड़ता है जिनमें उस फ़िल्म के सीन शामिल हों.

    एपीआई, get, list, insert, update, patch, और delete campaign संसाधनों के लिए तरीके उपलब्ध कराता है.

  • एपीआई, campaigns.get, campaigns.insert, campaigns.update, और campaigns.delete के नए तरीकों के लिए कई नई गड़बड़ियों के बारे में बताता है.

30 मार्च, 2015

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • assetSearch.list तरीके के नए isrcs पैरामीटर की मदद से, ज़्यादा से ज़्यादा 50 आईएसआरसी की सूची दी जा सकती है. एपीआई से मिले जवाब में, उन आईएसआरसी से जुड़ी ऐसेट शामिल होंगी.

    • claimHistory संसाधन की event[].reason प्रॉपर्टी के लिए, ये नई वैल्यू इस्तेमाल की जा सकती हैं. हर वजह से यह पता चलता है कि दावे से जुड़ा कोई इवेंट क्यों हुआ:

      • closed_audio_claim_on_visual_reference
      • closed_partner_exclusion
      • closed_reference_conflict

    • claimSearch.list तरीके का नया sort पैरामीटर, उस तरीके के बारे में बताता है जिसका इस्तेमाल एपीआई रिस्पॉन्स में संसाधनों को क्रम से लगाने के लिए किया जाएगा. डिफ़ॉल्ट रूप से, संसाधनों को बनाए जाने की तारीखों के आधार पर, समय के हिसाब से उलटे क्रम में लगाया जाता है. यानी, सबसे नए संसाधन सबसे ऊपर दिखते हैं. दावे वाले कॉन्टेंट के लिए, संसाधनों को सबसे ज़्यादा से सबसे कम व्यू के हिसाब से भी क्रम से लगाया जा सकता है.

      ध्यान दें कि अगर claimSearch.list अनुरोध में, status पैरामीटर की वैल्यू को appealed, disputed, pending, potential या routedForReview पर सेट किया जाता है, तो नतीजे इस आधार पर क्रम से लगाए जाते हैं कि दावे की समीक्षा की अवधि कब खत्म होती है.

    • ownership.update और ownership.patch तरीकों से, अब उन सभी प्रॉपर्टी की सही सूची मिलती है जिन्हें इन तरीकों को कॉल करते समय अपडेट किया जा सकता है. इस बदलाव से, एपीआई के दस्तावेज़ में सुधार किया गया है. इससे एपीआई की सुविधाओं में कोई बदलाव नहीं हुआ है.

    • assets.get और assets.list तरीकों के लिए fetchMatchPolicy पैरामीटर में, अब effective को इस्तेमाल की जा सकने वाली वैल्यू के तौर पर शामिल किया गया है. इस वैल्यू से एपीआई सर्वर को, मिलते-जुलते वीडियो से जुड़ी वह नीति वापस पाने का निर्देश मिलता है जिसे YouTube, ऐसेट के लिए लागू करता है.

    • assets.list, claims.list, contentOwners.list, policies.list, publishers.list, और references.list तरीकों के लिए id पैरामीटर अब यह बताते हैं कि उनकी पैरामीटर वैल्यू में, कॉमा से अलग किए गए ज़्यादा से ज़्यादा 50 आईडी शामिल हो सकते हैं.

  • नई और अपडेट की गई गड़बड़ियां

    यहां दी गई टेबल में, एपीआई के साथ काम करने वाली नई गड़बड़ियों और हर गड़बड़ी को ठीक करने के तरीकों के बारे में बताया गया है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    badRequest (400) tooManyIsrcs अगर isrcs पैरामीटर में 50 से ज़्यादा आईएसआरसी दिए गए हैं, तो assetSearch.list तरीके से यह गड़बड़ी मिलती है.
    badRequest (400) videoIsPrivate अगर किसी निजी वीडियो पर दावा करने की कोशिश की जाती है, तो claims.insert तरीके से यह गड़बड़ी दिखती है. किसी वीडियो पर सिर्फ़ तब दावा किया जा सकता है, जब उसकी निजता की स्थिति public या unlisted हो.
    notModified (304) blockOutsideOwnershipUnchanged अगर दावे पर मौजूद blockOutsideOwnership फ़्लैग में बदलाव नहीं किया जा सका, तो claims.update तरीके से यह गड़बड़ी दिखती है. यह गड़बड़ी कई वजहों से हो सकती है. इसका एक सामान्य उदाहरण यह है कि बताए गए बदलाव का असर, दावे वाले वीडियो पर नहीं पड़ता.

7 नवंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • claimSearch.list तरीके के status पैरामीटर के लिए, अब routedForReview वैल्यू का इस्तेमाल किया जा सकता है. इस वैल्यू से, नतीजे सिर्फ़ उन दावों तक सीमित हो जाते हैं जिनकी मैन्युअल तरीके से समीक्षा करने की ज़रूरत होती है. ऐसा, किसी ऐसेट के मिलते-जुलते वीडियो से जुड़ी नीति के नियम के आधार पर होता है.

    • claimHistory संसाधन की event[].reason प्रॉपर्टी के लिए, ये नई वैल्यू इस्तेमाल की जा सकती हैं. हर वजह से यह पता चलता है कि दावे से जुड़ा कोई इवेंट क्यों हुआ:

      • closed_invalid_reference_segment
      • closed_noadsense
      • suspended_monetization_on_channel
      • video_content_modified

    • claim रिसॉर्स की origin.source प्रॉपर्टी, दावे के सोर्स की पहचान करती है. अब यह melodyMatch वैल्यू के साथ काम करती है. मेलोडी मैच वाले दावे से पता चलता है कि दावा किए गए वीडियो में मौजूद संगीत कंपोज़िशन, रेफ़रंस के तौर पर इस्तेमाल की गई कंपोज़िशन से मिलती-जुलती है.

    • references.insert तरीके के दस्तावेज़ को अपडेट किया गया है, ताकि यह सही तरीके से दिखाया जा सके कि एपीआई, उस तरीके के लिए दो अलग-अलग एंडपॉइंट का इस्तेमाल करता है. इससे एपीआई के काम करने के तरीके में कोई बदलाव नहीं होगा. हालांकि, मौजूदा दस्तावेज़ में सुधार किया गया है.

      • अगर अनुरोध में नई रेफ़रंस फ़ाइल अपलोड की जा रही है, तो सही एंडपॉइंट यह है:

        POST https://www.googleapis.com/upload/youtube/partner/v1/references

      • अगर अनुरोध में, दावा किए गए वीडियो को रेफ़रंस कॉन्टेंट के तौर पर इस्तेमाल करके रेफ़रंस बनाया जा रहा है, तो सही एंडपॉइंट यह है:

        POST https://www.googleapis.com/youtube/partner/v1/references

  • नई और अपडेट की गई गड़बड़ियां

    यहां दी गई टेबल में, एपीआई के साथ काम करने वाली नई गड़बड़ियों और हर गड़बड़ी को ठीक करने के तरीकों के बारे में बताया गया है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    badRequest (400) invalidLabelName अगर किसी ऐसेट लेबल का नाम अमान्य है, तो assets.insert, assets.update, और assetLabels.insert तरीके यह गड़बड़ी दिखाते हैं. लेबल के नाम में दो से 30 वर्ण होने चाहिए. इनमें ऐंगल ब्रैकेट, कॉमा, कोलन, ऐंपरसैंड या वर्टिकल पाइप कैरेक्टर (|) शामिल नहीं हो सकते.
    badRequest (400) ownerHaveMaximumNumberOfLabels अगर कॉन्टेंट के मालिक ने पहले ही 2,500 यूनीक ऐसेट लेबल तय कर लिए हैं, तो assets.insert, assets.update, और assetLabels.insert तरीके इस गड़बड़ी को दिखाते हैं. फ़िलहाल, इतने ही लेबल तय किए जा सकते हैं.
    badRequest (400) tooManyLabelsOnOneAsset अगर कोई ऐसेट पहले से ही 30 ऐसेट लेबल से जुड़ी है, तो assets.insert और assets.update तरीके यह गड़बड़ी दिखाते हैं. फ़िलहाल, ऐसेट को ज़्यादा से ज़्यादा 30 ऐसेट लेबल से जोड़ा जा सकता है.
    badRequest (400) channelMonetizationSuspended अगर पार्टनर के दावों की वजह से किसी वीडियो के चैनल को निलंबित कर दिया जाता है, तो claims.insert और claims.update तरीके से यह गड़बड़ी दिखती है.
    badRequest (400) channelNotActive अगर किसी वीडियो का चैनल चालू नहीं है, तो claims.update तरीके से यह गड़बड़ी दिखती है.

  • अगर अनुरोध के मुख्य हिस्से में मौजूद संसाधन में metadataMine.contentType प्रॉपर्टी शामिल नहीं है, तो assets.insert और assets.update तरीके अब कुछ ऐसेट के लिए badRequest गड़बड़ी नहीं दिखाते.

23 सितंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • कॉन्टेंट के मालिक के आईडी में बदलाव

    कॉन्टेंट के मालिक के आईडी में हुए बदलावों के बारे में, 9 जुलाई, 2014 को संशोधन के इतिहास में बताया गया था. ये बदलाव लागू हो गए हैं. इस बदलाव के बाद, एपीआई अब एक जनरेट किया गया यूनीक आईडी दिखाता है. इससे, पुष्टि किए गए उपयोगकर्ता या एपीआई के ज़रिए मैनेज किए गए संसाधन से जुड़े कॉन्टेंट के मालिक की पहचान की जा सकती है. इससे पहले, एपीआई आईडी के तौर पर ऐसा नाम दिखाता था जिसे आसानी से पढ़ा जा सकता है. जैसे, "qrs_network."

    इस बदलाव का असर, एपीआई की इन सुविधाओं पर पड़ेगा. साथ ही, इससे उन पार्टनर पर भी असर पड़ेगा जिन्होंने अपने ऐप्लिकेशन में पार्टनर कोड को हार्ड-कोड किया है.

    • अब एपीआई, नए आईडी को उन संसाधन प्रॉपर्टी की वैल्यू के तौर पर दिखाता है जो पहले पार्टनर कोड दिखाती थीं. जैसे, contentOwner संसाधन की id प्रॉपर्टी.
    • एपीआई के सभी तरीके, onBehalfOfContentOwner पैरामीटर के साथ काम करते हैं. यह पैरामीटर, उस कॉन्टेंट के मालिक की पहचान करता है जिसकी ओर से एपीआई अनुरोध किया जा रहा है. बदलाव के बाद, पैरामीटर को पार्टनर कोड के बजाय नए आईडी पर सेट किया जाना चाहिए. कोड में गड़बड़ियां होने से रोकने के लिए, ट्रांज़िशन पीरियड के दौरान पैरामीटर, दोनों में से कोई भी वैल्यू स्वीकार करेगा.
    • बदलाव के बाद, contentOwners.list तरीके के contentOwnerId पैरामीटर में पार्टनर कोड के बजाय नया आईडी होना चाहिए.

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • assetSearch.list तरीके के नए metadataSearchFields पैरामीटर की मदद से, ऐसे ऐसेट मेटाडेटा फ़ील्ड तय किए जा सकते हैं जिन्हें आपको खोजना है. साथ ही, उन फ़ील्ड में मौजूद ऐसी वैल्यू तय की जा सकती हैं जिन्हें आपको खोजना है. पैरामीटर की वैल्यू, फ़ील्ड और वैल्यू पेयर की कॉमा से अलग की गई सूची होती है. किसी पेयर में, फ़ील्ड और वैल्यू को कोलन से अलग किया जाता है.

    • claim संसाधन का नया appliedPolicy ऑब्जेक्ट, उस नीति के बारे में बताता है जिसे YouTube, दावे के लिए लागू करता है. ऑब्जेक्ट की वैल्यू, policy रिसॉर्स होती है. इस संसाधन में, उन देशों के लिए नीति की जानकारी शामिल होती है जहां अनुरोध सबमिट करने वाले कॉन्टेंट के मालिक के पास, दावा की गई ऐसेट का मालिकाना हक है.

      लागू की गई नीति, कॉन्टेंट ओनर की तय की गई नीति से दो तरह से अलग हो सकती है:

      1. इसमें उन मालिकों की सेट की गई नीतियां शामिल होती हैं जिनके पास, दावे वाली ऐसेट का कुछ देशों/इलाकों में आंशिक मालिकाना हक है. ये देश/इलाके, एपीआई अनुरोध सबमिट करने वाले कॉन्टेंट के मालिक के देशों/इलाकों से मिलते-जुलते हैं.

      2. इसमें YouTube की उन प्रशासनिक नीतियों को ध्यान में रखा जाता है जो उन देशों/इलाकों में लागू होती हैं जहां कॉन्टेंट के मालिक के पास, दावा की गई ऐसेट का मालिकाना हक होता है.

    • claimHistory संसाधन की नई uploaderChannelId प्रॉपर्टी, उस चैनल के आईडी की पहचान करती है जिस पर दावा किया गया वीडियो अपलोड किया गया था.

8 सितंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • नए assetLabel संसाधन से, ऐसे टेक्स्ट लेबल की पहचान होती है जिसे किसी ऐसेट को असाइन किया जा सकता है. ऐसेट लेबल की मदद से, ऐसेट को अपनी पसंद की कैटगरी में रखा जा सकता है. इससे ऐसेट लाइब्रेरी को मैनेज करना आसान हो जाता है. ऐसेट को उनके लेबल के हिसाब से खोजा जा सकता है. इससे उन इस्तेमाल के उदाहरणों को भी आसान बनाया जा सकता है जिनमें आपको ऐसेट के किसी खास ग्रुप को अपडेट करना होता है.

      • assetLabels.list तरीके से, कॉन्टेंट के मालिक के लेबल की सूची वापस पाई जा सकती है.
      • assetLabels.insert तरीके से, नया ऐसेट लेबल बनाया जा सकता है. assets.update तरीके का इस्तेमाल करके भी नए लेबल बनाए जा सकते हैं. साथ ही, किसी ऐसेट के लिए लेबल अपडेट किए जा सकते हैं. एपीआई सर्वर, पहले से तय नहीं किए गए किसी भी लेबल के लिए, अपने-आप एक नया assetLabel संसाधन बना देगा.

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • asset संसाधन की label[] प्रॉपर्टी को अपडेट किया गया है, ताकि यह पता चल सके कि किसी ऐसेट के लेबल अपडेट करने के लिए, assets.update तरीके का इस्तेमाल किया जा सकता है. हालांकि, assets.insert तरीके को कॉल करते समय, किसी ऐसेट के लेबल सेट नहीं किए जा सकते.

      ऐसेट लेबल इस्तेमाल करना नई गाइड में, ऐसेट लेबल बनाने और उन्हें वापस पाने का तरीका बताया गया है. साथ ही, इसमें किसी ऐसेट के लेबल अपडेट करने या किसी खास लेबल से जुड़ी ऐसेट खोजने का तरीका भी बताया गया है.

  • नई और अपडेट की गई गड़बड़ियां

    एपीआई, नए assetLabels.list और assetLabels.insert तरीकों के लिए कई नई गड़बड़ियों के बारे में बताता है.

9 जुलाई, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • कॉन्टेंट के मालिक के आईडी में बदलाव

    पहले, एपीआई में पार्टनर कोड का इस्तेमाल किया जाता था. यह कोड, इंसानों के पढ़ने लायक होता है. जैसे, "qrs_network". इसका इस्तेमाल, पुष्टि किए गए उपयोगकर्ता या एपीआई के ज़रिए मैनेज किए गए संसाधन से जुड़े कॉन्टेंट के मालिक की पहचान करने के लिए किया जाता है. तीसरी तिमाही 2014 में, एपीआई कॉन्टेंट के मालिकों की पहचान करने के लिए, 22 वर्णों वाले यूनीक आईडी का इस्तेमाल करेगा. इस बदलाव से, एपीआई की इन सुविधाओं पर असर पड़ेगा. साथ ही, इससे उन पार्टनर पर भी असर पड़ेगा जिन्होंने अपने ऐप्लिकेशन में पार्टनर कोड को हार्ड-कोड किया है.

    • एपीआई, 22 वर्णों वाले आईडी को उन संसाधन प्रॉपर्टी की वैल्यू के तौर पर दिखाएगा जो पहले पार्टनर कोड दिखाती थीं. जैसे, contentOwner संसाधन की id प्रॉपर्टी.
    • एपीआई के सभी तरीके, onBehalfOfContentOwner पैरामीटर के साथ काम करते हैं. यह पैरामीटर, उस कॉन्टेंट के मालिक की पहचान करता है जिसकी ओर से एपीआई अनुरोध किया जा रहा है. बदलाव के बाद, पैरामीटर को पार्टनर कोड के बजाय 22 वर्णों वाले आईडी पर सेट किया जाना चाहिए. कोड में गड़बड़ियां होने से रोकने के लिए, ट्रांज़िशन पीरियड के दौरान पैरामीटर, दोनों में से कोई भी वैल्यू स्वीकार करेगा.
    • बदलाव के बाद, contentOwners.list तरीके के contentOwnerId पैरामीटर में पार्टनर कोड के बजाय, 22 वर्णों वाला आईडी होना चाहिए.

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • asset संसाधन अब label प्रॉपर्टी के साथ काम करता है. यह प्रॉपर्टी, ऐसेट से जुड़े ऐसेट लेबल की सूची के बारे में बताती है. आप एक से ज़्यादा एसेट को समूह में रखने के लिए उन पर लेबल लगा सकते हैं. इकट्ठे अपडेट करने, रिपोर्ट डाउनलोड करने या YouTube Analytics को फ़िल्टर करने के लिए, खोज फ़िल्टर के तौर पर लेबल का इस्तेमाल किया जा सकता है.

    • assetSearch.list तरीके में अब ये वैकल्पिक पैरामीटर इस्तेमाल किए जा सकते हैं:

      • labels: इससे नतीजों में सिर्फ़ वे ऐसेट शामिल होती हैं जो बताए गए लेबल से जुड़ी होती हैं. डिफ़ॉल्ट रूप से, एपीआई उन ऐसेट को दिखाता है जो बताए गए सभी लेबल से मेल खाती हैं. हालांकि, includeAnyProvidedLabel पैरामीटर का इस्तेमाल करके, एपीआई को यह निर्देश दिया जा सकता है कि वह ऐसेट दिखाए जो किसी भी लेबल से मेल खाती हों.
      • includeAnyProvidedLabel: इस पैरामीटर का इस्तेमाल labels पैरामीटर के साथ किया जाता है. यह पैरामीटर, एपीआई को ऐसी ऐसेट दिखाने का निर्देश देता है जो labels पैरामीटर वैल्यू में दिए गए किसी भी लेबल से जुड़ी हों.

    • claimHistory संसाधन में अब ये नई प्रॉपर्टी शामिल हैं:

      • event[].source.userEmail प्रॉपर्टी से, इवेंट शुरू करने वाले उपयोगकर्ता का ईमेल पता मिलता है.
      • event[].typeDetails.disputeNotes प्रॉपर्टी में, dispute_create इवेंट के लिए विवाद के नोट शामिल होते हैं.

    • claimSearch.list तरीके में अब ये वैकल्पिक पैरामीटर इस्तेमाल किए जा सकते हैं:

      • createdAfter: इससे नतीजों को सिर्फ़ उस तारीख के बाद किए गए दावों तक सीमित किया जाता है.
      • createdBefore: इससे नतीजों को सिर्फ़ उन दावों तक सीमित किया जाता है जो बताई गई तारीख से पहले किए गए थे.
      • includeThirdPartyClaims: इस पैरामीटर का इस्तेमाल videoId पैरामीटर के साथ किया जाता है. यह पैरामीटर बताता है कि एपीआई के नतीजों में तीसरे पक्ष के दावों को शामिल करना है या नहीं.

  • गड़बड़ी के बारे में ज़्यादा जानकारी

    गड़बड़ी से जुड़े दस्तावेज़ में अब हर तरह की गड़बड़ी के लिए, एचटीटीपी रिस्पॉन्स कोड की जानकारी दी गई है.

  • नई और अपडेट की गई गड़बड़ियां

    यहां दी गई टेबल में, एपीआई के साथ काम करने वाली नई गड़बड़ियों और हर गड़बड़ी को ठीक करने के तरीकों के बारे में बताया गया है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर किसी ऐसी asset संसाधन को डाला जाता है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी दिखती है. दरअसल, एक से ज़्यादा मेटाडेटा फ़ील्ड ज़रूरी हो सकते हैं. इनमें से हर फ़ील्ड के लिए, आपको थोड़ा अलग मैसेज वाली गड़बड़ी दिखेगी.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    तरीका गड़बड़ियां
    assetSearch.list
    • invalidValue – इस एपीआई में, शो या सीज़न की ऐसेट खोजने की सुविधा काम नहीं करती. type पैरामीटर की वैल्यू को इस्तेमाल की जा सकने वाली वैल्यू पर सेट करें.
    assets.insert
    • conflict – एक ही आइडेंटिफ़ायर (जैसे, कस्टम आईडी, आईएसआरसी वगैरह) वाली बहुत सारी ऐसेट पहले से मौजूद हैं.
    • conflict – बताई गई ऐसेट की बहुत सारी कॉपी पहले से मौजूद हैं.
    • invalidValue – एपीआई का इस्तेमाल करने वाले व्यक्ति के पास, तय किए गए टाइप की ऐसेट बनाने की अनुमति नहीं है.
    assets.patch
    assets.update
    • badRequest – एपीआई, उस ऐसेट टाइप कन्वर्ज़न का समर्थन नहीं करता है जिसे आपने आज़माया है.
    claimSearch.list
    • badRequest – includeThirdPartyClaims पैरामीटर का इस्तेमाल सिर्फ़ videoId फ़िल्टर के साथ किया जा सकता है.
    ownership.patch
    ownership.update
    • badRequest – किसी आर्ट ट्रैक ऐसेट के मालिकाना हक को अपडेट नहीं किया जा सकता.
    references.patch
    references.update
    • badRequest – आपने जिस कार्रवाई को करने की कोशिश की है उसके लिए, रेफ़रंस अमान्य स्थिति में है.

3 फ़रवरी, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • asset रिसॉर्स की type वैल्यू अब art_track_video हो सकती है.

    • claimSearch संसाधन में अब ये नई प्रॉपर्टी शामिल हैं:

      • origin ऑब्जेक्ट में ऐसी जानकारी होती है जिससे पता चलता है कि दावा कैसे बनाया गया था.
      • thirdPartyClaim प्रॉपर्टी में बूलियन वैल्यू होती है. इससे पता चलता है कि दावा, कॉन्टेंट के उस मालिक ने किया है या नहीं जो खोज करने वाले व्यक्ति से जुड़ा है.

    • claimSearch.list तरीके में अब ये वैकल्पिक पैरामीटर इस्तेमाल किए जा सकते हैं:

      • contentType: इससे खोज के नतीजों में, सिर्फ़ ऑडियो, सिर्फ़ वीडियो या ऑडियो-विज़ुअल वाले दावे शामिल किए जाते हैं.
      • origin: इससे दावे के एक या उससे ज़्यादा सोर्स के बारे में पता चलता है. जैसे, descriptiveSearch या videoMatch. आपको इन सोर्स के लिए दावे ढूंढने हैं.
      • status: नतीजों को सिर्फ़ उन दावों तक सीमित करता है जिनकी स्थिति बताई गई है.

    • claim संसाधन की status प्रॉपर्टी के लिए, अब ये अतिरिक्त वैल्यू इस्तेमाल की जा सकती हैं: appealed, disputed, potential, takedown, और unknown.

    • claim संसाधन की नई blockOutsideOwnership प्रॉपर्टी से पता चलता है कि दावा किए गए वीडियो को उन देशों/इलाकों में ब्लॉक किया जाना चाहिए जहां वीडियो पर मालिकाना हक साफ़ तौर पर नहीं बताया गया है. डिफ़ॉल्ट रूप से, दावा किया गया वीडियो उन देशों में अब भी देखा जा सकेगा जहां दावे से जुड़ी ऐसेट के लिए मालिकाना हक का डेटा तय नहीं किया गया है.

    • contentOwnerAdvertisingOption संसाधन की नई allowedOptions.autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि पार्टनर, YouTube की ओर से अपने-आप तय किए गए ब्रेक के दौरान, बीच में दिखने वाले विज्ञापन और इन-स्ट्रीम विज्ञापन दिखाने का विकल्प चुन सकता है या नहीं.

    • अब contentOwners.list तरीके को ऐसे अनुमति टोकन के साथ कॉल किया जा सकता है जो https://www.googleapis.com/auth/youtubepartner-content-owner-readonly स्कोप के बारे में बताता है.

    • policy संसाधन की नई timeUpdated प्रॉपर्टी से पता चलता है कि नीति को पिछली बार कब अपडेट किया गया था.

    • policies.list तरीके में अब sort पैरामीटर का इस्तेमाल किया जा सकता है. इसका इस्तेमाल यह बताने के लिए किया जा सकता है कि नतीजों को, पिछली बार अपडेट किए जाने के समय के हिसाब से बढ़ते या घटते क्रम में लगाया जाना चाहिए.

    • referenceConflict संसाधन की नई expiryTime प्रॉपर्टी से पता चलता है कि रेफ़रंस के टकराव की समीक्षा की अवधि कब खत्म होगी. इससे टकराव खत्म हो जाएगा.

    • videoAdvertisingOption संसाधन की नई autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि वीडियो में, YouTube की ओर से अपने-आप तय किए गए ब्रेक के दौरान बीच में दिखने वाले विज्ञापन और इन-स्ट्रीम विज्ञापन दिखाने चाहिए या नहीं.

  • नई और अपडेट की गई गड़बड़ियां

    यहां दी गई टेबल में, एपीआई के साथ काम करने वाली नई गड़बड़ियों और हर गड़बड़ी को ठीक करने के तरीकों के बारे में बताया गया है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर किसी ऐसी asset संसाधन को डाला जाता है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी दिखती है. दरअसल, एक से ज़्यादा मेटाडेटा फ़ील्ड ज़रूरी हो सकते हैं. इनमें से हर फ़ील्ड के लिए, आपको थोड़ा अलग मैसेज वाली गड़बड़ी दिखेगी.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    तरीका गड़बड़ियां
    assets.insert
    assets.update
    • badRequest – यह एपीआई, आर्ट ट्रैक ऐसेट पर लिखने की कार्रवाइयों के साथ काम नहीं करता.
    claimSearch.list
    • invalidValue – अनुरोध में मौजूद pageToken पैरामीटर में, पेज का अमान्य टोकन दिया गया है.
    claims.insert
    • badRequest – जिस वीडियो पर दावा किया जा रहा है उसका चैनल चालू नहीं है. इसलिए, दावा नहीं किया जा सकता.
    • badRequest – जिस वीडियो पर दावा किया जा रहा है उसे वीडियो हटाने की नीति से छूट मिली है. किसी भी सवाल के लिए, कृपया copyright@youtube.com पर संपर्क करें
    • badRequest – आपका अनुरोध प्रोसेस नहीं किया जा सकता, क्योंकि आपके पास बताए गए वीडियो पर तीसरे पक्ष का दावा करने का विकल्प नहीं है.
    • conflict – YouTube, अनुरोध किया गया दावा नहीं कर सकता, क्योंकि वीडियो के ख़िलाफ़ वीडियो हटाने के नोटिस का विरोध किया गया है.
    • conflict – YouTube, अनुरोध किया गया दावा नहीं कर सकता, क्योंकि वीडियो पर वीडियो हटाने का एक दावा मौजूद है.
    references.insert
    • badRequest – जिस वीडियो पर दावा किया गया है उसे इस्तेमाल करने की कोशिश की जा रही है. हालांकि, उसे मिटा दिया गया है या अस्वीकार कर दिया गया है. इसके अलावा, उसे प्रोसेस करने में समस्या आई है.

  • contentOwnerNotProvided और internalError गड़बड़ियां, किसी खास एपीआई तरीके से जुड़ी नहीं हैं. इसलिए, अब इन्हें हर तरीके के पेज पर नहीं दिखाया जाता. इनके बारे में जानकारी, अब भी एपीआई के गड़बड़ी से जुड़े दस्तावेज़ के सामान्य गड़बड़ियां सेक्शन में देखी जा सकती है.

12 सितंबर, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • नई referenceConflict संसाधन से, दो पहचान फ़ाइलों के बीच टकराव का पता चलता है. साथ ही, उन फ़ाइलों के बीच मौजूद मेल खाने वाले कॉन्टेंट की सूची मिलती है. यह सूची तब मिलती है, जब टकराव का पता चलता है. referenceConflicts.list तरीके से, कॉन्टेंट के उस मालिक से जुड़े ऐसे विवादों की सूची वापस पाई जा सकती है जिनका अब तक समाधान नहीं हुआ है. referenceConflicts.get तरीके से, रेफ़रंस के टकराव की जानकारी वापस पाई जा सकती है. इसके लिए, रेफ़रंस के टकराव का यूनीक आईडी देना होता है.

    मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • अब एपीआई की मदद से, किसी ऐसेट के लिए लागू होने वाली मिलते-जुलते वीडियो से जुड़ी नीति को वापस पाया जा सकता है. यह बदलाव, 16 जुलाई, 2013 को रिलीज़ किए गए बदलावों के जैसा ही है. इसमें किसी ऐसेट के लिए, मेटाडेटा और मालिकाना हक के डेटा का कैननिकल सेट वापस पाने की सुविधा शामिल थी.

      किसी ऐसेट के लिए, मिलते-जुलते वीडियो से जुड़ी नीति को लागू करने के लिए, assets.get या assets.list में से किसी एक तरीके को कॉल करते समय, fetchMatchPolicy पैरामीटर वैल्यू को effective पर सेट करें. एपीआई से मिले जवाब में, हर asset संसाधन में मौजूद matchPolicyEffective ऑब्जेक्ट में, उस ऐसेट के लिए मैच करने की नीति शामिल होती है.

    • asset संसाधन के नए ownershipConflicts ऑब्जेक्ट में, ऐसेट के मालिकाना हक से जुड़े विवादों के बारे में जानकारी होती है. ऑब्जेक्ट का स्ट्रक्चर, ownership रिसोर्स के स्ट्रक्चर जैसा होता है. इससे हर तरह के उन अधिकारों की पहचान होती है जो किसी ऐसेट के मालिक के पास हो सकते हैं. (ज़्यादातर ऐसेट टाइप के लिए, मालिकों के पास ऐसेट के मालिकाना हक का सामान्य अधिकार होता है. हालांकि, कंपोज़िशन ऐसेट के लिए, मालिक परफ़ॉर्म करने के अधिकार, सिंक्रनाइज़ेशन के अधिकार या मैकेनिकल अधिकारों के मालिकाना हक की जानकारी दे सकते हैं.)

      इसी तरह, ownershipConflicts ऑब्जेक्ट में अलग-अलग सूचियां होती हैं. इनसे मालिकाना हक के सामान्य अधिकारों, परफ़ॉर्म करने के अधिकारों, सिंक्रनाइज़ेशन के अधिकारों, और मैकेनिकल अधिकारों से जुड़े विवादों की पहचान की जाती है. हर विवाद के लिए, डेटा में यह जानकारी होती है: विवाद किन देशों/इलाकों में हुआ है, किन मालिकों ने मालिकाना हक का विवादित डेटा दिया है, और विवादित मालिकाना हक वाले हर मालिक का ऐसेट पर कितने प्रतिशत मालिकाना हक है.

    • assets.get और assets.get तरीके अब नए fetchOwnershipConflicts पैरामीटर के साथ काम करते हैं. इस पैरामीटर की वैल्यू बूलियन होती है. इससे पता चलता है कि एपीआई अनुरोध को, एपीआई जवाब में मौजूद ऐसेट के मालिकाना हक से जुड़े विवादों को वापस पाना चाहिए या नहीं. डिफ़ॉल्ट वैल्यू false है. इसका मतलब है कि मालिकाना हक से जुड़े विवादों के बारे में जानकारी नहीं दी जाती.

    • assetSearch.list तरीके के q पैरामीटर की परिभाषा को अपडेट किया गया है. इससे उन मेटाडेटा फ़ील्ड की पहचान की जा सकती है जिन्हें YouTube खोजता है.

    • references.insert तरीके के लिए अनुरोध के मुख्य हिस्से के दस्तावेज़ में अब यह बताया गया है कि आपको contentType प्रॉपर्टी की वैल्यू सेट करनी होगी. इस बदलाव से, दस्तावेज़ को अपडेट किया गया है, ताकि एपीआई की असल फ़ंक्शनैलिटी को सही तरीके से दिखाया जा सके. हालांकि, इससे एपीआई की फ़ंक्शनैलिटी में कोई बदलाव नहीं हुआ है.

  • नई और अपडेट की गई गड़बड़ियां

    • एपीआई में एक नई forbidden गड़बड़ी का पता चला है. यह किसी खास तरीके से जुड़ी नहीं है. इससे पता चलता है कि सेवा खाता, अनुरोध किए गए ऑपरेशन को अनुमति नहीं दे सकता.

    • assets.insert तरीके से अब मेटाडेटा से जुड़ी गड़बड़ियों की पहचान, metadata ऑब्जेक्ट के बजाय metadataMine ऑब्जेक्ट में मौजूद प्रॉपर्टी के तौर पर की जाती है. ऑब्जेक्ट को 16 जुलाई, 2013 को एपीआई अपडेट के बाद बंद कर दिया गया था.

    • गड़बड़ियां पेज को अपडेट किया गया है. अब update और patch तरीकों के साथ काम करने वाले हर संसाधन के लिए, पेज में एक टेबल मौजूद होगी. इस टेबल में, इन दोनों तरीकों से मिली गड़बड़ियों की सूची होगी. इससे पहले, पेज पर हर तरीके के लिए गड़बड़ियों की सूची अलग-अलग दिखाई जाती थी. हालांकि, ये सूचियां हमेशा एक जैसी होती थीं.

16 जुलाई, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • claimHistory.get के नए तरीके से, किसी खास दावे की पहचान की जा सकती है और उसके बारे में जानकारी वापस पाई जा सकती है. जवाब में मिले claimHistory संसाधन में, दावे से जुड़े इवेंट की सूची होती है. जैसे, दावा बनाया गया, अपडेट किया गया, विवादित किया गया या बंद किया गया.

    • claimSearch.list तरीके से, ऐसे दावों को खोजा जा सकता है जो इनमें से किसी एक या सभी शर्तों को पूरा करते हैं:

      • दावे किसी ऐसेट से जुड़े हों.
      • ये दावे किसी वीडियो से जुड़े होते हैं.
      • दावे, अनुरोध में दी गई क्वेरी स्ट्रिंग से मेल खाते हैं.

      एपीआई रिस्पॉन्स में मौजूद हर claimSnippet संसाधन में, दावे के बारे में जानकारी होती है. इसमें दावे का यूनीक आईडी, उसकी स्थिति, उसका टाइप (audio, video या audiovisual), और दावे से जुड़ी ऐसेट और वीडियो शामिल हैं. इस संसाधन में, दावा किए गए वीडियो के व्यू की संख्या और उसके टाइटल के बारे में भी बताया गया है.

  • मौजूदा संसाधनों और तरीकों से जुड़े अपडेट

    • दस्तावेज़ में अब उन प्रॉपर्टी के लिए इस्तेमाल की जा सकने वाली वैल्यू की सूची दी गई है जिनके लिए एनुमरेशन वैल्यू का सेट उपलब्ध है. इन प्रॉपर्टी में, asset संसाधन की type प्रॉपर्टी और claim संसाधन की status प्रॉपर्टी शामिल हैं.

    • एपीआई अब assets.get और assets.list तरीकों के लिए, fetchMetadata और fetchOwnership अनुरोध पैरामीटर के लिए कॉमा लगाकर अलग की गई वैल्यू का इस्तेमाल कर सकता है. इससे आपको मेटाडेटा या मालिकाना हक के डेटा के कई सेट वापस पाने में मदद मिलती है.

      यहां दी गई सूची में, asset संसाधन के स्ट्रक्चर में हुए बदलावों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि इन बदलावों का असर, एपीआई के उन तरीकों पर कैसे पड़ेगा जो get, list, insert, update या patch asset संसाधनों का इस्तेमाल करते हैं.

      • metadata ऑब्जेक्ट के इस्तेमाल पर रोक लगा दी गई है. इसकी जगह metadataMine और metadataEffective ऑब्जेक्ट का इस्तेमाल किया जाएगा. नए ऑब्जेक्ट की मदद से, asset रिसॉर्स में एपीआई अनुरोध करने वाले कॉन्टेंट के मालिक की ओर से दिया गया मेटाडेटा और मेटाडेटा का कैननिकल सेट, दोनों शामिल किए जा सकते हैं. YouTube ने यह तय किया है कि ऐसेट के लिए मेटाडेटा का सबसे सटीक और पूरा सेट कौन-सा है.

      • इसी तरह, ownership ऑब्जेक्ट को ownershipMine और ownershipEffective ऑब्जेक्ट से बदल दिया गया है.

      • matchPolicy ऑब्जेक्ट को matchPolicyMine ऑब्जेक्ट से बदल दिया गया है. फ़िलहाल, एपीआई किसी ऐसेट के लिए, लागू होने वाली मिलते-जुलते वीडियो से जुड़ी नीति को वापस पाने की सुविधा नहीं देता.

      ध्यान दें: यह पक्का करने के लिए कि एपीआई का इस्तेमाल पुराने वर्शन के साथ भी किया जा सके, अगर किसी ऐसेट के लिए सिर्फ़ एक मेटाडेटा वर्शन, मालिकाना हक वाले डेटा का एक सेट या मिलते-जुलते वीडियो से जुड़ी एक नीति का अनुरोध किया जाता है, तो एपीआई के जवाब में बंद किया गया ऑब्जेक्ट और नया ऑब्जेक्ट, दोनों शामिल होंगे. उदाहरण के लिए, अगर कोई अनुरोध fetchMetadata पैरामीटर को mine पर सेट करता है, तो एपीआई के जवाब में metadata ऑब्जेक्ट और metadataMine ऑब्जेक्ट, दोनों शामिल होंगे. इन दोनों में एक जैसा डेटा होगा. (सुविधा के अपडेट से पहले, fetchMetadata=mine को सेट करने की सुविधा उपलब्ध थी. इससे आपको मेटाडेटा के कई वर्शन वापस पाने की सुविधा मिलती थी.)

      हालांकि, अगर fetchMetadata पैरामीटर को mine,effective पर सेट किया जाता है, तो एपीआई रिस्पॉन्स में metadataMine और metadataEffective ऑब्जेक्ट शामिल होंगे. हालांकि, इसमें metadata ऑब्जेक्ट शामिल नहीं होगा. (इस सुविधा के अपडेट से पहले, fetchMetadata=mine,effective सेट करने की सुविधा उपलब्ध नहीं थी. इसलिए, पुराने सिस्टम के साथ काम करने की सुविधा के लिए, metadata ऑब्जेक्ट को वापस लाने की ज़रूरत नहीं है.) यही सिद्धांत fetchOwnership और fetchMatchPolicy पैरामीटर पर भी लागू होता है.

      इसी तरह, पिछले वर्शन के साथ काम करने की सुविधा के लिए, asset संसाधन के insert, update या patch के अनुरोध में, metadataMine ऑब्जेक्ट या metadata ऑब्जेक्ट में से कोई एक शामिल किया जा सकता है. asset संसाधन के मालिकाना हक का डेटा या मिलते-जुलते वीडियो से जुड़ी नीति सेट करने पर भी यही सिद्धांत लागू होता है.

    • claims.list तरीके के assetId, q, और videoId पैरामीटर अब काम नहीं करते हैं. इनमें से किसी भी मानदंड का इस्तेमाल करके दावों को खोजने के लिए, claimSearch.list तरीके का इस्तेमाल करें. यह तरीका, इन सभी पैरामीटर के साथ काम करता है.

    • ownership रिसोर्स में, general[].ratio, performance[].ratio, synchronization[].ratio, और mechanical[].ratio प्रॉपर्टी की वैल्यू का कॉन्टेंट फ़ॉर्मैट अब integer के बजाय double है.

    • policy संसाधन की rules[].action प्रॉपर्टी की डेफ़िनिशन में, अब उस प्रॉपर्टी के लिए मान्य वैल्यू दी गई हैं: block, monetize, takedown, और track. हालांकि, ध्यान दें कि किसी दावे पर कॉन्टेंट हटाने से जुड़ी नीति लागू करने के लिए, एपीआई का इस्तेमाल नहीं किया जा सकता.

    • अगर रेफ़रंस, किसी ऐसे YouTube वीडियो से ऐसेट को जोड़कर बनाया गया था जिसे आपके CMS खाते से लिंक किए गए YouTube चैनल पर अपलोड किया गया था, तो reference संसाधन की नई claimId प्रॉपर्टी मौजूद होती है. ऐसे मामले में, इस फ़ील्ड में उस दावे का आईडी होता है जो ऐसेट और वीडियो के बीच बने संबंध को दिखाता है.

    • reference संसाधन की नई excludedIntervals[] प्रॉपर्टी, पहचान फ़ाइल के दौरान समय के ऐसे इंटरवल की सूची तय करती है जिन्हें YouTube को पहचान फ़ाइल से मैच करने की कोशिश करते समय अनदेखा करना चाहिए. हर अंतराल में, वीडियो के शुरू होने के समय से लेकर, शुरू और खत्म होने के समय को सेकंड में मेज़र किया जाता है.

    • एपीआई को अब status प्रॉपर्टी को reference संसाधन में सेट करने की ज़रूरत नहीं है. यह संसाधन, references.update या references.patch अनुरोध के मुख्य हिस्से में भेजा जाता है.

    • दस्तावेज़ में बदलाव किया गया है, ताकि videoAdvertisingOptions.getEnabledAds तरीके के लिए एपीआई रिस्पॉन्स फ़ॉर्मैट के बारे में सही जानकारी दी जा सके. जवाब में, youtubePartner#videoAdvertisingOptionGetEnabledAds संसाधन के बारे में यह जानकारी शामिल होती है:

      • id – यह वह आईडी है जिसका इस्तेमाल YouTube, दावा किए गए वीडियो की पहचान करने के लिए करता है. यह वीडियो, सेटिंग से जुड़ा होता है.

      • adBreaks – ऑब्जेक्ट की एक सूची, जिसमें हर ऑब्जेक्ट में वीडियो के चलने से पहले, उसके दौरान या उसके बाद के किसी पॉइंट के बारे में जानकारी होती है. यह जानकारी तब मिलती है, जब विज्ञापनों को चलने की अनुमति दी जाती है. हर ऑब्जेक्ट, विज्ञापन ब्रेक के अन्य एट्रिब्यूट भी तय कर सकता है. जैसे, ब्रेक के दौरान दिखने वाले विज्ञापन स्लॉट और हर स्लॉट के दौरान दिखाए जा सकने वाले विज्ञापनों के टाइप.

      • adsOnEmbeds – यह एक बूलियन फ़ील्ड है. इससे पता चलता है कि एम्बेड किए गए प्लेयर में वीडियो चलाने के दौरान, YouTube विज्ञापन दिखा सकता है या नहीं.

      • countriesRestriction – यह ऑब्जेक्ट की एक सूची है. इसमें हर ऑब्जेक्ट, देशों/इलाकों की सूची और उन देशों/इलाकों में वीडियो चलाने के दौरान इस्तेमाल किए गए विज्ञापन फ़ॉर्मैट की पहचान करता है.

  • नई और अपडेट की गई गड़बड़ियां

    • यहां दी गई टेबल में, एपीआई के साथ काम करने वाली नई गड़बड़ियों और हर गड़बड़ी को ठीक करने के तरीकों के बारे में बताया गया है. इससे उन गड़बड़ियों की भी पहचान होती है जिनमें बदलाव हुआ है. ध्यान दें कि कोई तरीका, एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर किसी ऐसी asset संसाधन को डाला जाता है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी दिखती है. दरअसल, एक से ज़्यादा मेटाडेटा फ़ील्ड ज़रूरी हो सकते हैं. इनमें से हर फ़ील्ड के लिए, आपको थोड़ा अलग मैसेज वाली गड़बड़ी दिखेगी.

      ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

      तरीका गड़बड़ियां
      assets.insert
      assets.update
      assets.patch
      • invalidValue और required गड़बड़ियां, पहले metadata ऑब्जेक्ट की चाइल्ड प्रॉपर्टी से जुड़ी थीं. अब ये गड़बड़ियां, metadataMine ऑब्जेक्ट की चाइल्ड प्रॉपर्टी से जुड़ी हैं.
      claimHistory.get
      • notFound – जिस दावे का इतिहास वापस पाने की कोशिश की जा रही है वह नहीं मिला.
      • required – अनुरोध में, claimId पैरामीटर के लिए कोई वैल्यू नहीं दी गई है.
      claimSearch.list
      claims.list
      • badRequest – अनुरोध में अमान्य मानदंड दिए गए हैं. इनमें से ज़्यादा से ज़्यादा एक फ़िल्टर पैरामीटर तय किया जा सकता है: q, assetId, videoId.
      claims.insert
      • badRequest – आपने जिस दावे को बनाने की कोशिश की है वह अमान्य है. ऐसा इसलिए है, क्योंकि अनुरोध करने वाला कॉन्टेंट का मालिक, दावे से जुड़ी ऐसेट का मालिक नहीं है.
      • badRequest – जिस कॉन्टेंट के मालिक की ओर से कार्रवाई की जा रही है उसके पास, तय की गई कार्रवाई के साथ नीतियां बनाने की अनुमति नहीं है.
      • invalidValue – The content owner that you are acting on behalf of does not have permission to claim user-uploaded videos via the API.
      contentOwners.list
      • badRequest – अनुरोध में अमान्य मानदंड दिए गए हैं. इनमें से सिर्फ़ एक फ़िल्टर पैरामीटर तय किया जाना चाहिए: fetchMine, id. (इससे पहले, गड़बड़ी में फ़िल्टर पैरामीटर का एक अलग सेट दिखता था – has_conflicts_with, restrict_to_user, name_prefix, और id.)
      ownership.update
      ownership.patch
      • badRequest – कंपोज़िशन ऐसेट के मालिकाना हक के डेटा को अपडेट करने के अनुरोध में, मालिकाना हक के बारे में ज़्यादा जानकारी देनी होगी. जैसे, mechanical, performance, synchronization, और/या lyric के अधिकार. इसमें general के मालिकाना हक के अधिकार के बारे में जानकारी नहीं देनी होगी. lyric के लिए, अधिकारों का नया टाइप उपलब्ध है.
      policies.insert
      policies.update
      policies.patch
      • invalidValue – अनुरोध में नीति का अमान्य नियम शामिल है, क्योंकि एपीआई ऐसी नीतियां बनाने या उनमें बदलाव करने की सुविधा नहीं देता है जिनमें takedown कार्रवाई तय की गई हो. यह गड़बड़ी, अब काम न करने वाली invalidPolicyConditionalTakedown गड़बड़ी की जगह ले लेगी. इसमें invalidPolicyTakedownAction की वजह से हुई गड़बड़ी की जानकारी मिलती है.
      references.insert
      • badRequest – अनुरोध में, मीडिया फ़ाइल भेजी जानी चाहिए या claimId अनुरोध पैरामीटर के लिए वैल्यू तय की जानी चाहिए. हालांकि, किसी अनुरोध में मीडिया फ़ाइल नहीं भेजी जा सकती और claimId अनुरोध पैरामीटर के लिए वैल्यू तय नहीं की जा सकती.
      • badRequest – इसी कॉन्टेंट के लिए, YouTube वीडियो पर किए गए किसी दूसरे दावे से पहचान फ़ाइल पहले ही बनाई जा चुकी है.
      • badRequest – एपीआई, रेफ़रंस बनाते समय fpDirect प्रॉपर्टी के लिए वैल्यू सेट करने की सुविधा नहीं देता.
      • internalError – अपलोड की गई मीडिया फ़ाइल में कोई समस्या है.
      • invalidValue – contentType, assetId या claimId अनुरोध के पैरामीटर की वैल्यू अमान्य है. इस गड़बड़ी से, अमान्य वैल्यू की पहचान होती है.
      • notFound – आपने जिस ऐसेट या दावे के बारे में बताया है वह नहीं मिला. कृपया अपने अनुरोध में, assetId और claimId पैरामीटर की वैल्यू देखें.
      • required – अनुरोध में, contentType पैरामीटर के लिए वैल्यू तय करना ज़रूरी है.
      references.insert
      references.update
      references.patch
      • invalidValue – रेफ़रंस के लिए तय किए गए excludedIntervals मान्य नहीं हैं. ध्यान दें कि किसी पहचान फ़ाइल को बंद करते समय, बाहर रखे गए इंटरवल के बारे में नहीं बताया जा सकता.

10 मई, 2013

इस अपडेट में ये बदलाव किए गए हैं:

8 अप्रैल, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • इस एपीआई का नाम बदलकर YouTube Content ID API कर दिया गया है.

  • assetMatchPolicy संसाधन में कई प्रॉपर्टी बदली गई हैं:

    • kind प्रॉपर्टी की वैल्यू youtubePartner#policy से बदलकर youtubePartner#assetMatchPolicy हो गई है.
    • नई policyId प्रॉपर्टी में ऐसी वैल्यू होती है जो सेव की गई नीति के संसाधन की खास तौर पर पहचान करती है.
    • rules[].subaction प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • rules[].conditions.contentMatchType प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • id, name, और description प्रॉपर्टी हटा दी गई हैं.

  • assetMatchPolicy.update तरीके के दस्तावेज़ को अपडेट किया गया है. इससे यह पता चलता है कि इस तरीके को कॉल करते समय, policyId प्रॉपर्टी या rules[] ऑब्जेक्ट के लिए वैल्यू सेट की जा सकती हैं.

  • claims संसाधन अब कई नई प्रॉपर्टी के साथ काम करता है:

    प्रॉपर्टी का नाम वैल्यू ब्यौरा
    timeCreated datetime दावा किए जाने की तारीख और समय.
    matchInfo object matchInfo ऑब्जेक्ट में, उस मिलते-जुलते कॉन्टेंट के बारे में जानकारी होती है जिसकी वजह से दावा जनरेट हुआ है. यह जानकारी सिर्फ़ claim संसाधन में शामिल की जाती है. ऐसा तब होता है, जब अपलोड किया गया कोई वीडियो, मौजूदा रेफ़रंस फ़ाइल से मेल खाने की वजह से दावा अपने-आप जनरेट हुआ हो.
    matchInfo.referenceId string यह यूनीक आईडी है. इसका इस्तेमाल YouTube, उस रेफ़रंस reference की पहचान करने के लिए करता है जिससे मैच जनरेट हुआ है.
    matchInfo.longestMatch object longestMatch ऑब्जेक्ट में, पहचान फ़ाइल और अपलोड किए गए वीडियो के बीच सबसे ज़्यादा मेल खाने वाले हिस्से के बारे में जानकारी होती है.
    matchInfo.longestMatch.durationSecs unsigned long मिलते-जुलते अवसर की अवधि, सेकंड में.
    matchInfo.longestMatch.userVideoOffset unsigned long मैच शुरू होने का टाइम ऑफ़सेट. इसे अपलोड किए गए वीडियो की शुरुआत से सेकंड में मापा जाता है.
    matchInfo.longestMatch.referenceOffset unsigned long मैच शुरू होने पर टाइम ऑफ़सेट, रेफ़रंस की शुरुआत से सेकंड में मापा जाता है.
    matchInfo.totalMatch object totalMatch ऑब्जेक्ट में, अपलोड किए गए वीडियो के उस हिस्से के बारे में जानकारी होती है जो पहचान फ़ाइल से मिलता-जुलता है. साथ ही, इसमें पहचान फ़ाइल के उस हिस्से के बारे में जानकारी होती है जो अपलोड किए गए वीडियो से मिलता-जुलता है. अगर मैच किया गया कॉन्टेंट, अपलोड किए गए वीडियो या रेफ़रंस में लूप में चलता है, तो ये वैल्यू अलग-अलग हो सकती हैं. उदाहरण के लिए, अगर अपलोड किए गए वीडियो में किसी रेफ़रंस से 10 सेकंड की क्लिप शामिल है, लेकिन क्लिप को छह बार दोहराया गया है, तो अपलोड किए गए वीडियो में मिलता-जुलता कॉन्टेंट 60 सेकंड का है. हालांकि, रेफ़रंस में मिलता-जुलता कॉन्टेंट सिर्फ़ 10 सेकंड का है.
    matchInfo.totalMatch.userVideoDurationSecs unsigned long अपलोड किए गए वीडियो के उस कॉन्टेंट की कुल अवधि, जो पहचान फ़ाइल से मेल खाती है. यह अवधि सेकंड में होती है.
    matchInfo.totalMatch.referenceDurationSecs unsigned long अपलोड किए गए वीडियो से मेल खाने वाले पहचान वाले वीडियो की कुल अवधि, सेकंड में.
    origin object origin ऑब्जेक्ट में, दावे के सोर्स के बारे में जानकारी होती है.
    origin.source string दावे का सोर्स.

  • claims संसाधन में मौजूद policy प्रॉपर्टी को अपडेट कर दिया गया है. इससे यह पता चलता है कि 'ऑडियो बदलें' सुविधा के दावे के लिए, वैल्यू को अपडेट नहीं किया जा सकता.

  • metadataHistory संसाधन की timeProvidedMs प्रॉपर्टी का नाम बदलकर timeProvided कर दिया गया है.

  • ownershipHistory संसाधन की timeProvidedMs प्रॉपर्टी का नाम बदलकर timeProvided कर दिया गया है.

  • ownershipHistory.list तरीके की परिभाषा को अपडेट किया गया है. इसमें बताया गया है कि यह तरीका, कॉन्टेंट के हर मालिक के लिए, मालिकाना हक का सबसे नया डेटा ही वापस पाता है. हालांकि, अगर कॉन्टेंट के मालिक ने मालिकाना हक वाला डेटा, कई डेटा सोर्स (एपीआई, कॉन्टेंट फ़ीड वगैरह) के ज़रिए सबमिट किया है, तो सूची में हर कॉन्टेंट के मालिक और डेटा सोर्स के लिए सबसे नया डेटा शामिल होगा.

  • policy संसाधन में कई प्रॉपर्टी बदली गई हैं:

    • rule प्रॉपर्टी का नाम बदलकर rules कर दिया गया है.
    • rules[].subaction प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • rules[].conditions.contentMatchType प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.

  • policies.insert और policies.update तरीकों के दस्तावेज़ को अपडेट किया गया है. इससे पता चलता है कि इन तरीकों को कॉल करते समय, rules[] ऑब्जेक्ट के लिए वैल्यू सेट की जा सकती हैं.

  • एपीआई के कई तरीकों में, गड़बड़ियों के नए टाइप काम करते हैं. नीचे दी गई टेबल में, गड़बड़ी का पता लगाने के तरीके और नई तरह की गड़बड़ियों के बारे में बताया गया है. कई मामलों में, किसी एक तरह की कई गड़बड़ियां हो सकती हैं. उदाहरण के लिए, अगर किसी ऐसी asset संसाधन को डाला जाता है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी दिखती है. दरअसल, एक से ज़्यादा मेटाडेटा फ़ील्ड ज़रूरी हो सकते हैं. इनमें से हर फ़ील्ड के लिए, आपको थोड़ा अलग मैसेज वाली गड़बड़ी दिखेगी.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें या गड़बड़ियां पेज पर जाएं.

    तरीका गड़बड़ियां
    assets.insert
    • invalidValue – ऐसेट मेटाडेटा फ़ील्ड में एक अमान्य वैल्यू शामिल है.
    • required – ऐसेट के मेटाडेटा का कोई ज़रूरी फ़ील्ड मौजूद नहीं है.
    assets.update
    assets.patch
    • forbidden – जिस ऐसेट को अपडेट किया जा रहा है उसका मालिकाना हक उस पार्टनर के पास नहीं है जो अपडेट करने की कोशिश कर रहा है.
    • invalidValue – ऐसेट मेटाडेटा फ़ील्ड में एक अमान्य वैल्यू शामिल है.
    • notFound – ऐसेट को किसी सीज़न ऐसेट या शो ऐसेट से जोड़ा जा रहा है, जो नहीं मिल रही है.
    • required – ऐसेट के मेटाडेटा का कोई ज़रूरी फ़ील्ड मौजूद नहीं है.
    claims.insert
    • badRequest – इस अनुरोध में किसी वीडियो पर दावा करने की कोशिश की गई है, लेकिन दावा करने की अनुमति नहीं है.
    ownership.update
    ownership.patch
    • badRequest – इस अनुरोध में, किसी देश/इलाके में 100% से ज़्यादा मालिकाना हक का दावा किया गया है.
    policies.insert
    policies.patch
    policies.update
    • conflictingPolicyRules – नीति में, नीति के ऐसे नियम शामिल हैं जो एक-दूसरे से मेल नहीं खाते.

  • नए गड़बड़ियां पेज पर, उन गड़बड़ियों की सूची दी गई है जो एपीआई दिखा सकता है. इस पेज पर, सामान्य गड़बड़ियों के साथ-साथ किसी खास तरीके से जुड़ी गड़बड़ियों की जानकारी भी दी गई है. सामान्य गड़बड़ियां, एपीआई के कई अलग-अलग तरीकों में हो सकती हैं.

18 जनवरी, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • हाल ही में जोड़े गए videoAdvertisingOptions.getEnabledAds तरीके से, आपको किसी पार्टनर या उपयोगकर्ता के अपलोड किए गए वीडियो पर दिखाए जा सकने वाले विज्ञापनों के टाइप के बारे में जानकारी मिलती है.

  • assetSearch.list तरीके के ownershipRestriction पैरामीटर की परिभाषा को अपडेट किया गया है. इसमें बताया गया है कि पैरामीटर की डिफ़ॉल्ट वैल्यू mine है. इसका मतलब है कि एपीआई को सिर्फ़ मौजूदा उपयोगकर्ता के मालिकाना हक वाली ऐसेट को वापस पाना चाहिए.

  • assets.list तरीके के दस्तावेज़ में ये बदलाव दिखते हैं:

    • अब id पैरामीटर ज़रूरी है.

    • नए fetchMatchPolicy पैरामीटर की मदद से, यह बताया जा सकता है कि एपीआई अनुरोध में, उस मिलते-जुलते वीडियो से जुड़ी नीति को भी शामिल किया जाना चाहिए या नहीं जिसे आपने ऐसेट के लिए सेट किया है.

    • fetchOwnership पैरामीटर का इस्तेमाल करके, यह बताया जा सकता है कि एपीआई अनुरोध में ऐसेट के मालिकाना हक का डेटा भी शामिल किया जाना चाहिए या नहीं.

    • एपीआई से मिलने वाली ऐसेट की सूची में अब पेज नंबर के हिसाब से डेटा नहीं होता. इस वजह से, एपीआई के जवाब से nextPageToken प्रॉपर्टी और pageInfo ऑब्जेक्ट, दोनों को हटा दिया गया है. pageInfo ऑब्जेक्ट में totalResults, resultsPerPage, और startIndex प्रॉपर्टी शामिल थीं.

  • claims संसाधन के दस्तावेज़ को अपडेट किया गया है. इसमें बताया गया है कि दावा बनाते समय, आपको नीति की जानकारी देनी होगी. (अगर डाले गए दावे में किसी नीति के बारे में नहीं बताया गया है, तो YouTube फ़िलहाल इस्तेमाल की डिफ़ॉल्ट नीति लागू नहीं करता है. हालांकि, दस्तावेज़ में पहले बताया गया था कि ऐसा होता है.)

  • policy संसाधन की hasUnpublishedDraft प्रॉपर्टी अब काम नहीं करती है.

  • policies.list तरीके के साथ काम करने वाला नया id पैरामीटर, आपको उन सेव की गई नीतियों की पहचान करने की सुविधा देता है जिन्हें एपीआई अनुरोध को वापस पाना चाहिए. सिर्फ़ उन नीतियों को वापस पाया जा सकता है जो पुष्टि किए गए मौजूदा कॉन्टेंट के मालिक से जुड़ी हैं.

  • references.patch और references.update, दोनों तरीकों के लिए releaseClaims पैरामीटर की परिभाषा को अपडेट किया गया है. इसमें बताया गया है कि यह पैरामीटर सिर्फ़ तब काम करता है, जब दावे का स्टेटस inactive पर अपडेट किया जा रहा हो. ऐसे में, रेफ़रंस से जनरेट किए गए सभी मैच के दावों को रिलीज़ करने के लिए, releaseClaims पैरामीटर की वैल्यू को true पर भी सेट किया जा सकता है.

  • references.patch और references.update, दोनों तरीकों को अपडेट किया गया है. इनमें बताया गया है कि इनमें से कोई भी कार्रवाई करते समय, आपको रेफ़रंस का स्टेटस बताना होगा.

  • एपीआई के कई तरीकों में, गड़बड़ियों के नए टाइप काम करते हैं. यहां दी गई टेबल में, गड़बड़ी ठीक करने के तरीके और नई गड़बड़ियों के बारे में बताया गया है:

    तरीका गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    guideCategories.list notFound Unavailable जिस ऐसेट के लिए मिलते-जुलते वीडियो से जुड़ी नीति वापस लाने की कोशिश की जा रही है वह नहीं मिली.
    claims.get notFound Unavailable आपको जिस दावे की जानकारी चाहिए वह नहीं मिल सकी.
    ownership.patch invalidValue Unavailable आपने मालिकाना हक के लिए जो डेटा दिया है उसमें अमान्य वैल्यू शामिल है.
    ownership.update invalidValue Unavailable आपने मालिकाना हक के लिए जो डेटा दिया है उसमें अमान्य वैल्यू शामिल है.