CardDAV प्रोटोकॉल से संपर्क प्रबंधित करें

Google के CardDAV प्रोटोकॉल का इस्तेमाल करके, अपने संपर्कों को देखा और मैनेज किया जा सकता है.

संपर्क, उपयोगकर्ता के Google खाते में सेव किए जाते हैं; Google की ज़्यादातर सेवाओं में संपर्क सूची को ऐक्सेस करने की अनुमति दें. आपका क्लाइंट ऐप्लिकेशन CardDAV API का इस्तेमाल इन कामों के लिए कर सकता है नए संपर्क बनाएँ, मौजूदा संपर्कों में बदलाव करें या उन्हें मिटाएं, और संपर्कों के लिए क्वेरी करें जो कुछ खास शर्तों से मेल खाते हों.

विशेषताएं

पूरी जानकारी लागू नहीं की गई है, लेकिन जैसे कई क्लाइंट Apple iOSTM संपर्क और macOS को सही तरीके से इंटरऑपरेट करना चाहिए.

हर ज़रूरी जानकारी के लिए, Google का CardDAV सपोर्ट यहां दिया गया है:

• rfc2518: डिस्ट्रिब्यूटेड ऑथरिंग के लिए एचटीटीपी एक्सटेंशन (WebDAV)
  • एचटीटीपी तरीकों GET, PUT, DELETE, OPTIONS, और PROPFIND.
  • क्या को एचटीटीपी तरीकों के साथ काम नहीं करता LOCK, UNLOCK, COPY, MOVE या MKCOL.
  • आर्बिट्रेरी (उपयोगकर्ता के तय किए गए) WebDAV प्रॉपर्टी के साथ काम नहीं किया जा सकता.
  • WebDAV ऐक्सेस कंट्रोल (rfc3744) के साथ काम नहीं होता है.
• rfc5995: WebDAV कलेक्शन में सदस्यों को जोड़ने के लिए, POST का इस्तेमाल करना
  • कोई आईडी दर्ज किए बिना नए संपर्क बनाने का समर्थन करता है.
• RFC6352: CardDAV: वेब पर डिस्ट्रिब्यूट किए गए ऑथरिंग के लिए vCard एक्सटेंशन और वर्शन (WebDAV)
  • एचटीटीपी तरीके REPORT पर काम करता है. हालांकि, बताई गई सभी रिपोर्ट लागू किया गया.
  • मुख्य कलेक्शन और संपर्कों का कलेक्शन उपलब्ध कराने की सुविधा उपलब्ध है.
• RFC6578: WebDAV के लिए कलेक्शन सिंक्रोनाइज़ेशन
  • क्लाइंट ऐप्लिकेशन को कार्रवाई के इस मोड में निम्न के बाद स्विच करना होगा सिंक करने के लिए कहें.
• RFC6749: OAuth 2.0 ऑथराइज़ेशन फ़्रेमवर्क और rfc6750: OAuth 2.0 ऑथराइज़ेशन फ़्रेमवर्क: बेयरर टोकन का इस्तेमाल
  • OAuth 2.0 एचटीटीपी का इस्तेमाल करके CardDAV क्लाइंट प्रोग्राम की पुष्टि करने की सुविधा उपलब्ध है पुष्टि करना. Google, पुष्टि करने के किसी भी दूसरे तरीके के साथ काम नहीं करता है. संपर्क डेटा की सुरक्षा के लिए, हमें CardDAV कनेक्शन का उपयोग करने की आवश्यकता है एचटीटीपीएस.
• rfc6764: WebDAV (CalDAV) पर कैलेंडर एक्सटेंशन के लिए सेवाएं और WebDAV (CardDAV) के लिए vCard एक्सटेंशन का पता लगाना
  • CardDAV यूआरएल की बूटस्ट्रैपिंग, इसके सेक्शन 6 के RFC6764.
• काम करता है caldav-ctag-02: CalDAV में कैलेंडर कलेक्शन इकाई टैग (CTag, इसे CardDAV और CalDAV की विशेषताओं के बीच शेयर किया गया है. संपर्क ctag एक संसाधन ETag की तरह है; संपर्क में कुछ भी बदलने पर यह बदल जाता है पता पुस्तिका बदल गई है. इससे क्लाइंट प्रोग्राम को यह समझने में मदद मिलती है कि कि उसे किसी भी बदले गए संपर्कों को सिंक करने की ज़रूरत नहीं है.
• Google, संपर्क को कोड में बदलने के तरीके के तौर पर Vcard 3.0 का इस्तेमाल करता है. देखें: rfc6350: Vcard 3.0.

Google के CardDAV को OAuth 2.0 की आवश्यकता है

Google के CardDAV इंटरफ़ेस को OAuth 2.0 की आवश्यकता है. लिंक की गई जानकारी देखें Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करने के बारे में जानकारी के लिए नीचे दिया गया दस्तावेज़:

• Google API ऐक्सेस करने के लिए, OAuth 2.0 का इस्तेमाल करना
• इंस्टॉल किए गए ऐप्लिकेशन के लिए, OAuth 2.0 का इस्तेमाल करना

Google के CardDAV सर्वर से कनेक्ट करना

CardDAV प्रोटोकॉल, पता पुस्तिका और संपर्क संसाधनों को खोजने देता है यूआरआई. आपको किसी भी यूआरआई को हार्डकोड नहीं करना चाहिए, क्योंकि वे कभी भी बदल सकते हैं.

क्लाइंट ऐप्लिकेशन को एचटीटीपीएस का इस्तेमाल करना चाहिए और OAuth 2.0 की पुष्टि करना ज़रूरी है उपयोगकर्ता के Google खाते के लिए दिया जाता है. CardDAV सर्वर अनुरोध की तब तक पुष्टि करें, जब तक वह OAuth 2.0 वाले एचटीटीपीएस पर न पहुंच जाए की पुष्टि करता है, और आपका ऐप्लिकेशन इस पर रजिस्टर है DevConsole. बुनियादी पुष्टि या पुष्टि करने की सुविधा का इस्तेमाल करके, एचटीटीपी से कनेक्ट करने की कोई भी कोशिश ऐसा ईमेल/पासवर्ड जो Google खाते से मेल नहीं खाता है, 401 Unauthorized रिस्पॉन्स कोड.

CardDAV का इस्तेमाल करने के लिए, आपके क्लाइंट प्रोग्राम को शुरुआत में कैननिकल से कनेक्ट करना होगा इन पर एचटीटीपी PROPFIND लागू करके डिस्कवरी पाथ:

https://www.googleapis.com/.well-known/carddav

(HTTP 301) को पता बुक के संसाधन पर रीडायरेक्ट करने के बाद, आपका क्लाइंट प्रोग्राम इसके बाद, उस पर PROPFIND चलाकर, DAV:current-user-principal, DAV:principal-URL, और addressbook-home-set प्रॉपर्टी. इसके बाद, आपका क्लाइंट प्रोग्राम addressbook-home-set पर PROPFIND किया जा रहा है और addressbook और collection संसाधन. इस प्रोसेस की पूरी जानकारी के दायरे में नहीं आता. यहां जाएं: ज़्यादा जानकारी के लिए rfc6352.

रीडायरेक्ट पाथ, HTTP 301 रिस्पॉन्स में PROPFIND के ज़रिए दिखाया गया जाने-पहचाने यूआरआई को हमेशा के लिए कैश मेमोरी में सेव नहीं किया जाना चाहिए (जैसा कि rfc6764). डिवाइस को जाने-पहचाने डिवाइसों को फिर से कोशिश करनी चाहिए समय-समय पर यूआरआई खोजने की सुविधा का इस्तेमाल करके, यह पुष्टि करता है कि कैश मेमोरी में सेव किया गया पाथ अब भी अप-टू-डेट है या नहीं और reसिंक करें. Google हर दो से चार हफ़्तों में ऐसा करने का सुझाव देता है.

संसाधन

CardDAV, REST के सिद्धांतों का इस्तेमाल करता है. क्लाइंट ऐप्लिकेशन इन संसाधनों पर काम करते हैं: जिन्हें उनके यूआरआई द्वारा निर्दिष्ट किया गया है. आपकी मदद के लिए, मौजूदा यूआरआई की जानकारी यहां दी गई है डेवलपर नीचे दिए गए सेक्शन में दिए गए कॉन्सेप्ट को समझते हैं. स्ट्रक्चर हो सकता है बदलें और हार्डकोड नहीं किया जाना चाहिए. इसके बजाय, संसाधनों को ढूंढना और उन्हें आरएफ़सी के मुताबिक.

1. प्रिंसिपल
   • https://www.googleapis.com/carddav/v1/principals/userEmail
2. घर का सेट
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists
3. अड्रेस बुक
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default
4. संपर्क करना
   • https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default/contactId

संपर्कों को सिंक्रोनाइज़ किया जा रहा है

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

• CTag का इस्तेमाल करना
  • क्लाइंट प्रोग्राम, अड्रेस बुक पर मौजूद getctag PROPFIND अनुरोध का इस्तेमाल करते हैं यह तय करने के लिए संसाधन कि क्या सर्वर पर किसी संपर्क में बदलाव हुआ है और इसलिए, देखें कि क्या सिंक करने की ज़रूरत है. इस प्रॉपर्टी की वैल्यू संपर्क में बदलाव होने पर उसके बदलाव की गारंटी है. क्लाइंट ऐप्लिकेशन को यह मान संग्रहित करना चाहिए और इसका उपयोग केवल शुरुआती सिंक पर और sync-token के अमान्य होने पर फ़ॉलबैक. इस तारीख के लिए समय-समय पर होने वाले मतदान getctag प्रॉपर्टी की वजह से थ्रॉटलिंग हो जाएगी.
• सिंक-टोकन का इस्तेमाल करना
  • क्लाइंट प्रोग्राम, पते पर मौजूद sync-token PROPFIND अनुरोध का इस्तेमाल करते हैं मौजूदा स्थिति दिखाने वाले sync-token को पाने के लिए बुक करें. क्लाइंट ऐप्लिकेशन को यह मान संग्रहित करना होगा और सामयिक sync-collection जारी करना होगा पिछली बार जारी किए जाने के बाद से बदलावों को तय करने के लिए REPORT अनुरोध sync-token. जारी किए गए टोकन 29 दिनों के लिए मान्य होते हैं और REPORT जवाब में नया sync-token शामिल होगा.
• ई-टैग इस्तेमाल करना
  • क्लाइंट ऐप्लिकेशन, इस पते पर getetag PROPFIND का अनुरोध जारी करते हैं किताब का संसाधन (DEPTH_1 के बराबर DEPTH हेडर के साथ). रखरखाव करके हर संपर्क की ETag वैल्यू. क्लाइंट प्रोग्राम इस वैल्यू का अनुरोध कर सकता है संपर्कों के ETag बदल गए.
• संपर्कों को वापस पाना
  • क्लाइंट ऐप्लिकेशन addressbook-multiget REPORT का अनुरोध. संपर्क यूआरआई की सूची दी गई है. यह रिपोर्ट, अनुरोध किए गए सभी संपर्कों को Vकार्ड 3.0 की वैल्यू के तौर पर दिखाती है. हर एंट्री में संपर्क के लिए ETag शामिल है.
• संपर्क जोड़ना
  • क्लाइंट ऐप्लिकेशन, Vcard में नए संपर्क के साथ POST का अनुरोध जारी करते हैं 3.0 फ़ॉर्मैट में होना चाहिए. जवाब में नए संपर्क का आईडी शामिल होगा.
• संपर्क अपडेट करना
  • क्लाइंट ऐप्लिकेशन, अपडेट किए गए संपर्क के साथ PUT अनुरोध जारी करता है Vcard 3.0 फ़ॉर्मैट. अगर संपर्क पहले से मौजूद है, तो संपर्क अपडेट कर दिया जाएगा डालें.
  • क्लाइंट ऐप्लिकेशन में, If-Match हेडर शामिल होना चाहिए संपर्क की जानकारी फ़िलहाल ETag को दी गई है. इसके बाद सर्वर, PUT को अस्वीकार कर देगा अनुरोध (HTTP 412 के साथ) अगर सर्वर पर मौजूदा ETag है यह क्लाइंट प्रोग्राम से भेजे जाने वाले ETag से अलग होता है. इससे आपको अपडेट को उम्मीद के हिसाब से क्रम में लगाना.
• किसी संपर्क को मिटाना
  • क्लाइंट ऐप्लिकेशन, DELETE अनुरोध जारी करके किसी संपर्क को मिटा देते हैं संपर्क यूआरआई के हिसाब से बदलें.