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

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

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

जानकारी

पूरी जानकारी लागू नहीं की गई है. हालांकि, Apple iOSTM Contacts और 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) पर कैलेंडरिंग एक्सटेंशन और vCard एक्सटेंशन को WebDAV (CardDAV) में खोजने की सेवाएं
  • CardDAV यूआरएल की बूटस्ट्रैपिंग, RFC6764 के सेक्शन 6 के मुताबिक होनी चाहिए.
• CalDAV में, caldav-ctag-02: Calendar कलेक्शन एंटिटी टैग (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 प्रोटोकॉल, यूआरएल की पता पुस्तिका और संपर्क संसाधन खोजने की अनुमति देता है. आपको किसी भी यूआरआई को हार्डकोड नहीं करना चाहिए, क्योंकि वह किसी भी समय बदल सकता है.

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

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

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

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

जाने-पहचाने यूआरआई पर PROPFIND के ज़रिए, HTTP 301 रिस्पॉन्स में दिए गए रीडायरेक्ट पाथ को हमेशा के लिए कैश मेमोरी में नहीं किया जाना चाहिए (rfc6764 के मुताबिक). डिवाइस को समय-समय पर लोकप्रिय यूआरआई पता लगाने की कोशिश करनी चाहिए, ताकि यह पुष्टि की जा सके कि कैश मेमोरी में सेव किया गया पाथ अब भी अप-टू-डेट है या नहीं. साथ ही, पाथ में कभी कोई बदलाव होने पर, उसे फिर से सिंक किया जाना चाहिए. 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

संपर्कों को सिंक करना

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

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