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 कॉन्सेप्ट का इस्तेमाल करता है. क्लाइंट ऐप्लिकेशन, उन रिसॉर्स पर काम करते हैं जिन्हें उनके यूआरआई के हिसाब से तय किया जाता है. मौजूदा यूआरआई स्ट्रक्चर यहां बताया गया है, ताकि डेवलपर नीचे दिए गए सेक्शन के कॉन्सेप्ट को समझ सकें. स्ट्रक्चर बदल सकता है और उसे हार्डकोड नहीं किया जाना चाहिए. इसके बजाय, संसाधनों की आरएफ़सी के मुताबिक खोज होनी चाहिए.
- प्रिंसिपल
- https://www.googleapis.com/carddav/v1/principals/
userEmail
- https://www.googleapis.com/carddav/v1/principals/
- होम सेट
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists
- https://www.googleapis.com/carddav/v1/principals/
- पते की किताब
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists/default
- https://www.googleapis.com/carddav/v1/principals/
- संपर्क करें
- https://www.googleapis.com/carddav/v1/principals/
userEmail
/lists/default/contactId
- https://www.googleapis.com/carddav/v1/principals/
संपर्कों को सिंक करना
नीचे उन कार्रवाइयों का सामान्य ब्यौरा दिया गया है जिनका इस्तेमाल किया जा सकता है. डेवलपर जानकारी को सही आरएफ़सी में देखें. अनुरोध और रिस्पॉन्स, ज़्यादातर एक्सएमएल में एन्कोड किए जाते हैं. क्लाइंट ऐप्लिकेशन, सिंक करने के लिए इन मुख्य फ़ंक्शन का इस्तेमाल करते हैं:
- 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
अनुरोध जारी करते हैं. जवाब में नए संपर्क का आईडी शामिल होगा.
- क्लाइंट ऐप्लिकेशन, नए संपर्क के साथ VCard
3.0 फ़ॉर्मैट में
- किसी संपर्क को अपडेट करना
- क्लाइंट ऐप्लिकेशन, अपडेट किए गए संपर्क के साथ
PUT
अनुरोध भेजते हैं. यह अनुरोध उन्हें Vcard 3.0 फ़ॉर्मैट में उपलब्ध कराता है. अगर संपर्क पहले से पता पुस्तिका में मौजूद है, तो संपर्क को अपडेट कर दिया जाता है. - क्लाइंट ऐप्लिकेशन में एक
If-Match
हेडर होना चाहिए. साथ ही, संपर्क काETag
हेडर होना चाहिए. इसके बाद, अगर सर्वर पर मौजूदाETag
, क्लाइंट प्रोग्राम से भेजे गएETag
से अलग है, तो सर्वरPUT
अनुरोध (HTTP 412
के साथ) को अस्वीकार कर देगा. इससे अपडेट को आशावादी क्रम से लगाने में मदद मिलती है.
- क्लाइंट ऐप्लिकेशन, अपडेट किए गए संपर्क के साथ
- संपर्क को मिटाना
- क्लाइंट ऐप्लिकेशन, संपर्क यूआरआई के लिए
DELETE
अनुरोध जारी करके, किसी संपर्क को मिटा देते हैं.
- क्लाइंट ऐप्लिकेशन, संपर्क यूआरआई के लिए