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

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

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

विशेषताएं

पूरी खास शर्त लागू नहीं की गई है. हालांकि, Apple iOS™ Contacts और macOS जैसे कई क्लाइंट सही तरीके से काम करने चाहिए.

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

• rfc2518: डिस्ट्रिब्यूटेड ऑथरिंग (WebDAV) के लिए एचटीटीपी एक्सटेंशन
  • यह एचटीटीपी के इन तरीकों के साथ काम करता है: GET, PUT, DELETE, OPTIONS, और PROPFIND.
  • क्या को एचटीटीपी तरीकों के साथ काम नहीं करता LOCK, UNLOCK, COPY, MOVE या MKCOL.
  • आर्बिट्रेरी (उपयोगकर्ता के तय किए गए) WebDAV प्रॉपर्टी के साथ काम नहीं किया जा सकता.
  • WebDAV ऐक्सेस कंट्रोल (rfc3744) के साथ काम नहीं करता.
• rfc5995: WebDAV कलेक्शन में सदस्यों को जोड़ने के लिए, POST का इस्तेमाल करना
  • आईडी डाले बिना नए संपर्क बनाने की सुविधा.
• rfc6352: CardDAV: वेब डिस्ट्रिब्यूटेड ऑथरिंग और वर्शनिंग (WebDAV) के लिए vCard एक्सटेंशन
  • एचटीटीपी प्रोटोकॉल REPORT के साथ काम करता है. हालांकि, तय की गई सभी रिपोर्ट लागू नहीं की जाती हैं.
  • मुख्य संग्रह और संपर्कों का एक संग्रह उपलब्ध कराने का समर्थन करता है.
• rfc6578: WebDAV के लिए कलेक्शन सिंक करना
  • शुरुआती सिंक के बाद, क्लाइंट ऐप्लिकेशन को इस मोड में स्विच करना होगा.
• RFC6749: OAuth 2.0 ऑथराइज़ेशन फ़्रेमवर्क और rfc6750: OAuth 2.0 ऑथराइज़ेशन फ़्रेमवर्क: बेयरर टोकन का इस्तेमाल
  • OAuth 2.0 एचटीटीपी की पुष्टि करने की सुविधा का इस्तेमाल करके, CardDAV क्लाइंट प्रोग्राम की पुष्टि करने की सुविधा. Google, पुष्टि करने के किसी भी दूसरे तरीके के साथ काम नहीं करता है. संपर्क डेटा की सुरक्षा के लिए, हमें CardDAV कनेक्शन का उपयोग करने की आवश्यकता है एचटीटीपीएस.
• rfc6764: WebDAV (CalDAV) पर कैलेंडर एक्सटेंशन के लिए सेवाएं और WebDAV (CardDAV) के लिए vCard एक्सटेंशन का पता लगाना
  • CardDAV यूआरएल को बूस्टरैप करने के लिए, rfc6764 के सेक्शन 6 का पालन करना ज़रूरी है.
• काम करता है 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 शामिल होगा.
• ई-टैग इस्तेमाल करना
  • क्लाइंट ऐप्लिकेशन, Address Book संसाधन पर getetag PROPFIND अनुरोध जारी करते हैं. इसमें DEPTH हेडर, DEPTH_1 के बराबर होता है. हर संपर्क की 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 अनुरोध जारी करके किसी संपर्क को मिटा देते हैं संपर्क यूआरआई के हिसाब से बदलें.