Method: documents.batchUpdate

दस्तावेज़ पर एक या उससे ज़्यादा अपडेट लागू होते हैं.

लागू करने से पहले, हर request की पुष्टि की जाती है. अगर कोई अनुरोध मान्य नहीं है, तो पूरा अनुरोध रद्द हो जाएगा और कुछ भी लागू नहीं होगा.

कुछ अनुरोधों के बगल में replies होता है. इससे आपको यह जानकारी मिलती है कि उन्हें कैसे लागू किया जाता है. अन्य अनुरोधों को जानकारी लौटाने की ज़रूरत नहीं होती; ये हर एक खाली जवाब लौटाता है. जवाबों का क्रम, अनुरोधों के क्रम से मेल खाता है.

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

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

एचटीटीपी अनुरोध

POST https://docs.googleapis.com/v1/documents/{documentId}:batchUpdate

यूआरएल में gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल किया गया है.

पाथ पैरामीटर

पैरामीटर
documentId

string

अपडेट किए जाने वाले दस्तावेज़ का आईडी.

अनुरोध का मुख्य भाग

अनुरोध के मुख्य भाग में, नीचे दिए गए स्ट्रक्चर वाला डेटा होता है:

JSON के काेड में दिखाना 
{
  "requests": [
    {
      object (Request)
    }
  ],
  "writeControl": {
    object (WriteControl)
  }
}
फ़ील्ड
requests[]

object (Request)

दस्तावेज़ पर लागू किए जाने वाले अपडेट की सूची.
writeControl

object (WriteControl)

यह कंट्रोल करता है कि डेटा लिखने के अनुरोध कैसे लागू किए जाते हैं.

जवाब का मुख्य भाग

documents.batchUpdate के अनुरोध का जवाब देने के लिए मैसेज.

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

JSON के काेड में दिखाना 
{
  "documentId": string,
  "replies": [
    {
      object (Response)
    }
  ],
  "writeControl": {
    object (WriteControl)
  }
}
फ़ील्ड
documentId

string

उस दस्तावेज़ का आईडी जिस पर अपडेट लागू किए गए थे.
replies[]

object (Response)

अपडेट का जवाब. यह अपडेट के साथ 1:1 मैप करता है. हालांकि, कुछ अनुरोधों के जवाब खाली हो सकते हैं.
writeControl

object (WriteControl)

अनुरोध लागू करने के बाद, अपडेट किया गया लिखने का कंट्रोल.

अनुमति के दायरे

इसके लिए, OAuth के इनमें से किसी एक स्कोप की ज़रूरत होती है:

  • https://www.googleapis.com/auth/documents
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.file

ज़्यादा जानकारी के लिए, अनुमति से जुड़ी गाइड देखें.

WriteControl

यह कंट्रोल करता है कि डेटा लिखने के अनुरोध कैसे लागू किए जाते हैं.

JSON के काेड में दिखाना 
{

  // Union field control can be only one of the following:
  "requiredRevisionId": string,
  "targetRevisionId": string
  // End of list of possible types for union field control.
}
फ़ील्ड
यूनियन फ़ील्ड control. यह तय करता है कि किसी दस्तावेज़ में किस तरह का बदलाव करना है. साथ ही, यह भी तय करता है कि अगर वह बदलाव, दस्तावेज़ का मौजूदा संशोधन नहीं है, तो अनुरोध को कैसे काम करना चाहिए. अगर कोई भी फ़ील्ड तय नहीं है, तो अपडेट सबसे नए वर्शन पर लागू कर दिए जाते हैं. control इनमें से कोई एक हो सकता है:
requiredRevisionId

string

उस दस्तावेज़ का वैकल्पिक revision ID जिस पर लिखने का अनुरोध लागू किया गया है. अगर यह दस्तावेज़ का नया वर्शन नहीं है, तो अनुरोध प्रोसेस नहीं किया जाता और 400 गलत अनुरोध वाली गड़बड़ी का मैसेज दिखता है.

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

string

उस दस्तावेज़ का वैकल्पिक टारगेट revision ID जिस पर लिखने का अनुरोध लागू किया गया है.

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

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