- एचटीटीपी अनुरोध
- पाथ पैरामीटर
- अनुरोध का मुख्य हिस्सा
- जवाब का मुख्य हिस्सा
- अनुमति के दायरे
- अनुरोध करें
- ReplaceAllTextRequest
- SubstringmatchCriteria
- InsertTextRequest
- जगह की जानकारी
- EndOfRangeLocation
- UpdateTextStyleRequest
- CreateParagraphbulletsRequest
- bulletGlyphPreset
- DeleteParagraphbulletsRequest
- CreateNamedRangeRequest
- DeleteNamedRangeRequest
- UpdateParagraphStyleRequest
- DeleteContentRangeRequest
- इनलाइन इमेज रिक्वेस्ट डालें
- InsertTableRequest
- InsertTableRowRequest
- TableCellLocation
- InsertTableColumnRequest
- DeleteTableRowRequest
- DeleteTableColumnRequest
- InsertPageBreakRequest
- DeletePositionedObjectRequest
- UpdateTableColumnPropertiesRequest
- UpdateTableCellStyleRequest
- TableRange
- UpdateTableRowStyleRequest
- ReplaceImageRequest
- ImageReplaceMethod
- UpdateDocumentStyleRequest
- MergeTableCellsRequest
- UnMergeTableCellsRequest
- CreateHeaderRequest
- हेडरफ़ुटरटाइप
- नया अनुरोध करें
- CreateFootnoteRequest
- ReplaceNamedRangeContentRequest
- UpdatesectionStyleRequest
- InsertsectionBreakRequest
- DeleteHeaderRequest
- मिटाने का अनुरोध मिटाएं
- PinTableHeaderRowsRequest
- WriteControl
- जवाब
- ReplaceAllTextResponse
- CreateNamedRangeResponse
- इनलाइन इमेज रिस्पॉन्स डालें
- inlineSheetsChartResponse डालें
- CreateHeaderResponse
- परिवार से संपर्क में आए जवाब बनाएं
- CreateFootnoteResponse
- इसे आज़माएं!
दस्तावेज़ पर एक या एक से ज़्यादा अपडेट लागू करता है.
लागू होने से पहले, हर request
की पुष्टि हो जाती है. अगर कोई अनुरोध मान्य नहीं है, तो पूरा अनुरोध स्वीकार नहीं किया जाएगा और कुछ भी लागू नहीं होगा.
कुछ अनुरोधों में, replies
को लागू करने के तरीके के बारे में कुछ जानकारी दी जाती है. अन्य अनुरोधों के लिए जानकारी देना ज़रूरी नहीं होता. हर अनुरोध के लिए कोई खाली जवाब नहीं दिया जाता. जवाबों का क्रम, अनुरोधों से मेल खाता है.
उदाहरण के लिए, मान लें कि आप बैच अपडेट को चार अपडेट के साथ कॉल करते हैं और केवल तीसरा अपडेट जानकारी लौटाता है. इस जवाब में दो खाली जवाब होंगे, तीसरे अनुरोध का जवाब होगा, और दूसरा इसी क्रम में खाली होगा.
हो सकता है कि जब दूसरे लोग, दस्तावेज़ में बदलाव कर रहे हों, तो हो सकता है कि दस्तावेज़ आपके बदलावों को सटीक तौर पर न दिखाए. ऐसा हो सकता है कि सहयोगी बदलावों की वजह से आपके बदलावों में बदलाव हो जाए. अगर कोई सहयोगी नहीं है, तो दस्तावेज़ में आपके बदलाव दिखने चाहिए. किसी भी स्थिति में, आपके अनुरोध में किए गए अपडेट इस बात की गारंटी हैं कि वे एक साथ लागू होंगे.
एचटीटीपी अनुरोध
POST https://docs.googleapis.com/v1/documents/{documentId}:batchUpdate
यूआरएल, gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल करता है.
पाथ पैरामीटर
पैरामीटर में | |
---|---|
documentId |
उस दस्तावेज़ का आईडी जिसे अपडेट करना है. |
अनुरोध का मुख्य भाग
अनुरोध के मुख्य हिस्से में, नीचे दिए गए स्ट्रक्चर का डेटा शामिल है:
जेएसओएन के काेड में दिखाना |
---|
{ "requests": [ { object ( |
फ़ील्ड | |
---|---|
requests[] |
दस्तावेज़ पर लागू होने वाले अपडेट की सूची. |
writeControl |
यह नीति तय करती है कि अनुरोध कैसे लिखा जाएगा. |
जवाब का मुख्य भाग
documents.batchUpdate
के अनुरोध पर मिला जवाब.
अगर एपीआई सही से जुड़ जाता है, ताे जवाब के मुख्य भाग में नीचे दिए गए स्ट्रक्चर शामिल होता है.
जेएसओएन के काेड में दिखाना |
---|
{ "documentId": string, "replies": [ { object ( |
फ़ील्ड | |
---|---|
documentId |
उस दस्तावेज़ का आईडी जिस पर अपडेट लागू किए गए थे. |
replies[] |
अपडेट का जवाब. यह अपडेट के साथ 1:1 मैप करता है, हालांकि कुछ अनुरोधों के जवाब खाली हो सकते हैं. |
writeControl |
अनुरोध लागू करने के बाद, अपडेट किया गया राइट कंट्रोल. |
अनुमति के दायरे
इनमें से किसी एक OAuth दायरे की ज़रूरत होती है:
https://www.googleapis.com/auth/documents
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/drive.file
ज़्यादा जानकारी के लिए, अनुमति देने के लिए गाइड देखें.
राइट कंट्रोल
यह नीति तय करती है कि अनुरोध कैसे लिखा जाएगा.
जेएसओएन के काेड में दिखाना |
---|
{ // Union field |
फ़ील्ड | |
---|---|
यूनियन फ़ील्ड control . यह तय करता है कि दस्तावेज़ में किस तरह का बदलाव करना है और अगर दस्तावेज़ में मौजूदा संशोधन के मुताबिक कोई बदलाव नहीं हुआ है, तो अनुरोध कैसे काम करेगा. दोनों में से कोई भी फ़ील्ड तय न होने पर, अपडेट को नए वर्शन पर लागू किया जाता है. control इनमें से सिर्फ़ एक हो सकता है: |
|
requiredRevisionId |
जिस दस्तावेज़ में लेखन अनुरोध लागू किया गया है वह जब रिस्पॉन्स में किसी ज़रूरी बदलाव का आईडी दिखाया जाता है, तो यह बताता है कि अनुरोध लागू करने के बाद दस्तावेज़ का रिवीज़न आईडी मिला है. |
targetRevisionId |
उस दस्तावेज़ का वैकल्पिक लक्ष्य जब API का उपयोग करके दस्तावेज़ पढ़ा जाता है, तो सहयोगकर्ता परिवर्तन हो जाते हैं, फिर इस लेखन अनुरोध द्वारा किए गए परिवर्तन सहयोगी परिवर्तनों पर लागू हो जाते हैं. इससे एक नए दस्तावेज़ में बदलाव होता है, जिसमें सहयोगी बदलाव और अनुरोध में किए गए बदलाव, दोनों शामिल होते हैं. इसमें Docs सर्वर पर होने वाले बदलावों को आपस में सुलझाने में मदद मिलती है. जब टारगेट एपीआई आईडी का इस्तेमाल किया जाता है, तो एपीआई क्लाइंट को दस्तावेज़ का कोई दूसरा सहयोगी माना जा सकता है. टारगेट संशोधन आईडी का इस्तेमाल किसी दस्तावेज़ के सिर्फ़ नए वर्शन में लिखने के लिए किया जा सकता है. अगर टारगेट में होने वाला बदलाव, हाल ही में किए गए संशोधन से बहुत पीछे है, तो इस अनुरोध को प्रोसेस नहीं किया जाता और 400 खराब अनुरोध की गड़बड़ी दिखाई जाती है. दस्तावेज़ का सबसे नया वर्शन वापस लाने के बाद, फिर से अनुरोध करने की कोशिश करनी चाहिए. आम तौर पर, संशोधन आईडी को पढ़ने के बाद कई मिनट तक, टारगेट संशोधन के तौर पर इस्तेमाल करने के लिए मान्य बना रहता है. हालांकि, बार-बार बदलाव किए जाने वाले दस्तावेज़ों के लिए यह विंडो छोटी हो सकती है. |