फ़ाइलें बनाना और उन्हें मैनेज करना

इस गाइड में, Google Drive API का इस्तेमाल करके Google Drive में फ़ाइलें बनाने और उन्हें मैनेज करने का तरीका बताया गया है.

फ़ाइल बनाना

Drive में ऐसी फ़ाइल बनाने के लिए जिसमें कोई मेटाडेटा या कॉन्टेंट न हो, files संसाधन पर बिना किसी पैरामीटर के create तरीके का इस्तेमाल करें.

फ़ाइल बनाते समय, यह तरीका files संसाधन दिखाता है. फ़ाइल को kind drive.file, id, "Untitled" का name, और application/octet-stream का mimeType दिया गया है. uploadType को 'ज़रूरी' के तौर पर मार्क किया गया है, लेकिन इसकी डिफ़ॉल्ट वैल्यू media है. इसलिए, आपको इसे सबमिट करने की ज़रूरत नहीं है.

Drive में फ़ाइल की सीमाओं के बारे में ज़्यादा जानने के लिए, फ़ाइल और फ़ोल्डर की सीमाएं देखें.

फ़ील्ड पैरामीटर का इस्तेमाल करना

अगर आपको जवाब में दिखाए जाने वाले फ़ील्ड तय करने हैं, तो files रिसॉर्स के किसी भी तरीके के साथ fields सिस्टम पैरामीटर सेट किया जा सकता है. fields पैरामीटर को शामिल न करने पर, सर्वर उस तरीके के हिसाब से फ़ील्ड का डिफ़ॉल्ट सेट दिखाता है. उदाहरण के लिए, list तरीके से, हर फ़ाइल के लिए सिर्फ़ kind, id, name, mimeType, और resourceKey फ़ील्ड की वैल्यू मिलती है. अलग-अलग फ़ील्ड वापस पाने के लिए, चुनिंदा फ़ील्ड वापस पाना लेख पढ़ें.

फ़ाइल का मालिकाना हक

Drive API का इस्तेमाल करके कोई फ़ाइल बनाने पर, मालिकाना हक इस बात पर निर्भर करता है कि ऐप्लिकेशन ने पुष्टि करने के लिए किस तरह के क्रेडेंशियल इस्तेमाल किए हैं. यह इन तरीकों से तय होता है:

  • उपयोगकर्ता खाता (OAuth 2.0): अगर ऐप्लिकेशन, किसी उपयोगकर्ता की ओर से पुष्टि करता है, तो वह उपयोगकर्ता फ़ाइल का मालिक बन जाता है. इसके बाद, फ़ाइल उनके My Drive फ़ोल्डर या चुने गए फ़ोल्डर में सेव हो जाती है. इससे उनके स्टोरेज कोटे का इस्तेमाल होता है.

  • सेवा खाता: अगर ऐप्लिकेशन, सेवा खाते का इस्तेमाल करके पुष्टि करता है, तो सेवा खाता फ़ाइल का मालिक होता है. इसके बाद, फ़ाइल सेवा खाते के Drive स्टोरेज में सेव हो जाती है. जब तक साफ़ तौर पर शेयर न किया जाए, तब तक फ़ाइलें Drive के अन्य स्टोरेज खातों में नहीं दिखतीं. अगर सेवा खाता मिटा दिया जाता है, तो उससे जुड़ी सभी फ़ाइलें तुरंत मिटा दी जाती हैं.

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

फ़ाइल की अनुमतियों के बारे में ज़्यादा जानने के लिए, फ़ाइलें, फ़ोल्डर, और ड्राइव शेयर करना लेख पढ़ें.

अपनी फ़ाइलों के साथ इस्तेमाल करने के लिए आईडी जनरेट करना

files रिसॉर्स पर मौजूद generateIds तरीके का इस्तेमाल करके, यूनीक फ़ाइल आईडी पहले से जनरेट किए जा सकते हैं. इनका इस्तेमाल Drive में फ़ाइलें और फ़ोल्डर बनाते या कॉपी करते समय किया जा सकता है. यह तब काम आ सकता है, जब आपको Drive को फ़ाइल आईडी अपने-आप असाइन करने की अनुमति देने के बजाय, अपने ऐप्लिकेशन से फ़ाइल आईडी कंट्रोल करने हों.

count क्वेरी पैरामीटर का इस्तेमाल करके, जनरेट किए गए आईडी की संख्या सेट की जा सकती है. अगर count सेट नहीं है, तो डिफ़ॉल्ट रूप से 10 वैल्यू दिखती हैं. ज़्यादा से ज़्यादा 1,000 आईडी का अनुरोध किया जा सकता है.

इसके अलावा, यह भी तय किया जा सकता है कि आईडी का इस्तेमाल किस space में किया जा सकता है और आईडी का इस्तेमाल किन type के लिए किया जा सकता है.

आईडी जनरेट होने के बाद, इसे id फ़ील्ड के ज़रिए create या copy तरीके से पास किया जा सकता है. इससे यह पक्का होता है कि बनाई गई या कॉपी की गई फ़ाइल में, पहले से तय किया गया आईडी इस्तेमाल किया गया हो.

अगर फ़ाइल बन जाती है या कॉपी हो जाती है, तो बाद में फिर से कोशिश करने पर, 409 Conflict एचटीटीपी स्टेटस कोड का रिस्पॉन्स मिलता है. साथ ही, डुप्लीकेट फ़ाइलें नहीं बनती हैं.

ध्यान दें कि पहले से जनरेट किए गए आईडी, Google Workspace फ़ाइलें बनाने के लिए इस्तेमाल नहीं किए जा सकते. हालांकि, application/vnd.google-apps.drive-sdk और application/vnd.google-apps.folder MIME टाइप के लिए इनका इस्तेमाल किया जा सकता है. इसी तरह, Google Workspace फ़ाइल फ़ॉर्मैट में बदलने के लिए किए गए अपलोड भी काम नहीं करते.

सिर्फ़ मेटाडेटा वाली फ़ाइलें बनाना

सिर्फ़ मेटाडेटा वाली फ़ाइलों में कोई कॉन्टेंट नहीं होता. मेटाडेटा, फ़ाइल के बारे में जानकारी देने वाला डेटा होता है. जैसे, name, mimeType, और createdTime. name जैसे फ़ील्ड, उपयोगकर्ता के हिसाब से नहीं होते और हर उपयोगकर्ता के लिए एक जैसे दिखते हैं. वहीं, viewedByMeTime जैसे फ़ील्ड में उपयोगकर्ता के हिसाब से वैल्यू होती हैं.

सिर्फ़ मेटाडेटा वाली फ़ाइल का एक उदाहरण, MIME टाइप application/vnd.google-apps.folder वाला फ़ोल्डर है. ज़्यादा जानकारी के लिए, फ़ोल्डर बनाना और उनमें डेटा डालना लेख पढ़ें. एक और उदाहरण, Drive पर मौजूद किसी ऐसी फ़ाइल का शॉर्टकट है जिसका MIME टाइप application/vnd.google-apps.shortcut है. ज़्यादा जानकारी के लिए, Drive में मौजूद किसी फ़ाइल का शॉर्टकट बनाना लेख पढ़ें.

थंबनेल इमेज मैनेज करना

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

किसी मौजूदा फ़ाइल को कॉपी करना

किसी फ़ाइल को कॉपी करने और अनुरोध किए गए अपडेट लागू करने के लिए, files संसाधन पर copy तरीके का इस्तेमाल करें. कॉपी करने के लिए fileId ढूंढने के लिए, list तरीके का इस्तेमाल करें.

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

generateIds तरीके का इस्तेमाल करके, कॉपी की गई फ़ाइल का आईडी पहले से सेट किया जा सकता है. ज़्यादा जानकारी के लिए, अपनी फ़ाइलों के साथ इस्तेमाल करने के लिए आईडी जनरेट करना लेख पढ़ें.

ध्यान दें कि कॉल को अनुमति देने के लिए, आपको सही Drive API स्कोप का इस्तेमाल करना होगा. Drive के स्कोप के बारे में ज़्यादा जानने के लिए, Google Drive API के स्कोप चुनना लेख पढ़ें.

सीमाएं और ज़रूरी बातें

फ़ाइलों को कॉपी करने से पहले, इन सीमाओं और बातों का ध्यान रखें:

  • अनुमतियां:

    • files रिसॉर्स के DownloadRestrictionsMetadata ऑब्जेक्ट से यह तय होता है कि फ़ाइल को कौन कॉपी कर सकता है. ज़्यादा जानकारी के लिए, लोगों को, आपकी फ़ाइल डाउनलोड करने, प्रिंट करने या उसे कॉपी करने से रोकना लेख पढ़ें.
    • capabilities.canCopy फ़ील्ड रिसॉर्स से यह तय होता है कि उपयोगकर्ता किसी फ़ाइल को कॉपी कर सकता है या नहीं. ज़्यादा जानकारी के लिए, फ़ाइल की सुविधाओं के बारे में जानकारी लेख पढ़ें.
    • कॉपी की गई फ़ाइल का मालिकाना हक, कॉपी बनाने वाले उपयोगकर्ता के पास होता है. सोर्स फ़ाइल की अन्य शेयरिंग सेटिंग कॉपी नहीं की जाती हैं. अगर कॉपी को शेयर किए गए किसी फ़ोल्डर में बनाया जाता है, तो उस पर फ़ोल्डर की अनुमतियां लागू होती हैं.
    • कॉपी की गई फ़ाइल का मालिकाना हक बदल सकता है. साथ ही, कॉपी की गई फ़ाइल में, ओरिजनल फ़ाइल को शेयर करने की सेटिंग लागू नहीं हो सकती हैं. इन सेटिंग को रीसेट करने की ज़रूरत पड़ सकती है.

  • फ़ाइल मैनेजमेंट:

    • कुछ फ़ाइलों को कभी कॉपी नहीं किया जा सकता. जैसे, तीसरे पक्ष के शॉर्टकट.
    • किसी फ़ाइल को सिर्फ़ एक पैरंट फ़ोल्डर में कॉपी किया जा सकता है. एक से ज़्यादा पैरंट एट्रिब्यूट की वैल्यू नहीं दी जा सकती. अगर parents फ़ील्ड के बारे में जानकारी नहीं दी गई है, तो फ़ाइल को सोर्स फ़ाइल से, खोजे जा सकने वाले पैरंट फ़ोल्डर की अनुमतियां मिल जाती हैं.
    • फ़ोल्डर एक तरह की फ़ाइल होता है. हालांकि, इसे कॉपी नहीं किया जा सकता. इसके बजाय, डेस्टिनेशन फ़ोल्डर बनाएं और मौजूदा फ़ाइलों के parents फ़ील्ड को डेस्टिनेशन फ़ोल्डर पर सेट करें. इसके बाद, ओरिजनल सोर्स फ़ोल्डर को मिटाया जा सकता है.
    • जब तक कोई नया फ़ाइल नाम नहीं दिया जाता, तब तक copy तरीके से बनाई गई फ़ाइल का नाम, ओरिजनल फ़ाइल के नाम जैसा ही होता है.
    • copy का बहुत ज़्यादा इस्तेमाल करने से, Drive API के कोटे की सीमाएं पार हो सकती हैं. ज़्यादा जानकारी के लिए, इस्तेमाल की सीमाएं देखें.

यहां कुछ ऐसे तरीके दिए गए हैं जिन्हें आज़माया जा सकता है: