CardDAV প্রোটোকলের সাথে পরিচিতিগুলি পরিচালনা করুন

আপনি Google এর CardDAV প্রোটোকল ব্যবহার করে আপনার পরিচিতিগুলি দেখতে এবং পরিচালনা করতে পারেন৷

পরিচিতিগুলি ব্যবহারকারীর Google অ্যাকাউন্টে সংরক্ষণ করা হয়; বেশিরভাগ Google পরিষেবার যোগাযোগ তালিকায় অ্যাক্সেস আছে। আপনার ক্লায়েন্ট অ্যাপ্লিকেশন নতুন পরিচিতি তৈরি করতে, বিদ্যমান পরিচিতিগুলি সম্পাদনা করতে বা মুছতে এবং নির্দিষ্ট মানদণ্ডের সাথে মেলে এমন পরিচিতিগুলির জন্য অনুসন্ধান করতে CardDAV API ব্যবহার করতে পারে৷

স্পেসিফিকেশন

সম্পূর্ণ স্পেসিফিকেশন বাস্তবায়িত হয়নি, তবে অনেক ক্লায়েন্ট যেমন Apple iOS™ পরিচিতি এবং macOS সঠিকভাবে ইন্টারঅপারেটিং করা উচিত।

প্রতিটি প্রাসঙ্গিক স্পেসিফিকেশনের জন্য, Google এর CardDAV সমর্থন নিম্নরূপ:

• rfc2518: বিতরণকৃত অথরিংয়ের জন্য HTTP এক্সটেনশন (ওয়েবডিএভি)
  • HTTP পদ্ধতিগুলি GET , PUT , DELETE , OPTIONS , এবং PROPFIND সমর্থন করে।
  • LOCK , UNLOCK , COPY , MOVE বা MKCOL HTTP পদ্ধতিগুলিকে সমর্থন করে না ।
  • নির্বিচারে (ব্যবহারকারী-সংজ্ঞায়িত) WebDAV বৈশিষ্ট্য সমর্থন করে না ।
  • WebDAV অ্যাক্সেস কন্ট্রোল (rfc3744) সমর্থন করে না ।
• rfc5995: WebDAV সংগ্রহে সদস্যদের যোগ করতে POST ব্যবহার করা
  • একটি আইডি নির্দিষ্ট না করেই নতুন পরিচিতি তৈরি করতে সহায়তা করে।
• rfc6352: CardDAV: ওয়েব ডিস্ট্রিবিউটেড অথরিং এবং সংস্করণে vCard এক্সটেনশন (ওয়েবডিএভি)
  • HTTP পদ্ধতি REPORT সমর্থন করে, কিন্তু সমস্ত সংজ্ঞায়িত রিপোর্ট বাস্তবায়িত হয় না।
  • একটি প্রধান সংগ্রহ এবং একটি পরিচিতি সংগ্রহ প্রদান সমর্থন করে।
• rfc6578: WebDAV-এর জন্য সংগ্রহ সিঙ্ক্রোনাইজেশন
  • প্রাথমিক সিঙ্কের পরে ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে অবশ্যই এই মোডে স্যুইচ করতে হবে৷
• rfc6749: OAuth 2.0 অনুমোদন ফ্রেমওয়ার্ক এবং rfc6750: OAuth 2.0 অনুমোদন ফ্রেমওয়ার্ক: বহনকারী টোকেন ব্যবহার
  • OAuth 2.0 HTTP প্রমাণীকরণ ব্যবহার করে CardDAV ক্লায়েন্ট প্রোগ্রামের প্রমাণীকরণ সমর্থন করে। Google অন্য কোনো প্রমাণীকরণ পদ্ধতি সমর্থন করে না। যোগাযোগের ডেটার নিরাপত্তার জন্য, HTTPS ব্যবহার করার জন্য আমাদের CardDAV সংযোগ প্রয়োজন।
• rfc6764: WebDAV (CalDAV) এ ক্যালেন্ডারিং এক্সটেনশন এবং WebDAV (CardDAV) এ vCard এক্সটেনশনের জন্য লোকেটিং পরিষেবা
  • CardDAV URL-এর বুটস্ট্র্যাপিং অবশ্যই 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 সার্ভারের সাথে সংযোগ করা হচ্ছে

কার্ডডিএভি প্রোটোকল ঠিকানা বই এবং যোগাযোগ সংস্থান ইউআরআই আবিষ্কার করতে দেয়। আপনি অবশ্যই কোনো URI হার্ডকোড করবেন না কারণ সেগুলি যেকোনো সময় পরিবর্তন হতে পারে।

ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে অবশ্যই HTTPS ব্যবহার করতে হবে এবং ব্যবহারকারীর Google অ্যাকাউন্টের জন্য OAuth 2.0 প্রমাণীকরণ প্রদান করতে হবে৷ একটি Google অ্যাকাউন্টের OAuth 2.0 প্রমাণীকরণ সহ HTTPS-এ না আসা পর্যন্ত CardDAV সার্ভার কোনও অনুরোধকে প্রমাণীকরণ করবে না এবং আপনার আবেদনটি DevConsole-এ নিবন্ধিত হয়। বেসিক প্রমাণীকরণের সাথে বা একটি Google অ্যাকাউন্টের সাথে মেলে না এমন একটি ইমেল/পাসওয়ার্ডের সাথে HTTP এর সাথে সংযোগ করার যে কোনো প্রচেষ্টা একটি HTTP 401 Unauthorized প্রতিক্রিয়া কোডে পরিণত হয়।

CardDAV ব্যবহার করার জন্য, আপনার ক্লায়েন্ট প্রোগ্রামকে প্রাথমিকভাবে একটি HTTP 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 দেখুন।

সুপরিচিত URI-তে একটি PROPFIND এর মাধ্যমে HTTP 301 প্রতিক্রিয়াতে ফিরে আসা পুনঃনির্দেশিত পথটি অবশ্যই স্থায়ীভাবে ক্যাশে করা যাবে না ( rfc6764 অনুযায়ী)। ক্যাশ করা পাথ এখনও আপ টু ডেট আছে কিনা তা যাচাই করতে ডিভাইসগুলিকে পর্যায়ক্রমে সুপরিচিত URI আবিষ্কারের পুনরায় চেষ্টা করা উচিত এবং যদি পাথ কখনও পরিবর্তন হয় তবে পুনরায় সিঙ্ক করা উচিত। Google প্রতি 2-4 সপ্তাহে একটি হার সুপারিশ করে।

সম্পদ

CardDAV REST ধারণা ব্যবহার করে। ক্লায়েন্ট অ্যাপ্লিকেশনগুলি তাদের ইউআরআই দ্বারা মনোনীত সংস্থানগুলির উপর কাজ করে। বর্তমান URI কাঠামোটি এখানে উল্লেখ করা হয়েছে যাতে বিকাশকারীদের নিম্নলিখিত বিভাগে ধারণাগুলি বুঝতে সহায়তা করা হয়। গঠন পরিবর্তন হতে পারে এবং হার্ডকোড করা উচিত নয়. বরং RFC অনুযায়ী সম্পদ আবিষ্কার করতে হবে।

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-তে বিস্তারিত খোঁজা উচিত। অনুরোধ এবং প্রতিক্রিয়াগুলি বেশিরভাগ XML-এ এনকোড করা হয়। এইগুলি সিঙ্ক্রোনাইজেশনের জন্য ক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা ব্যবহৃত প্রধান ক্রিয়াকলাপগুলি:

• CTag ব্যবহার করে
  • ক্লায়েন্ট প্রোগ্রামগুলি সার্ভারে কোন পরিচিতি পরিবর্তিত হয়েছে কিনা এবং সেইজন্য একটি সিঙ্ক্রোনাইজেশন প্রয়োজন কিনা তা নির্ধারণ করতে ঠিকানা পুস্তকের রিসোর্সে getctag PROPFIND অনুরোধ ব্যবহার করে। এই সম্পত্তির মান পরিবর্তনের গ্যারান্টি দেওয়া হয় যদি কোনো যোগাযোগের পরিবর্তন হয়। ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে এই মানটি সংরক্ষণ করা উচিত এবং এটি শুধুমাত্র প্রাথমিক সিঙ্কে এবং একটি ফলব্যাক হিসাবে ব্যবহার করা উচিত যখন একটি sync-token অবৈধ হয়৷ পর্যায়ক্রমে getctag সম্পত্তির জন্য পোলিং এর ফলে থ্রটলিং হবে।
• সিঙ্ক-টোকেন ব্যবহার করে
  • ক্লায়েন্ট প্রোগ্রামগুলি তার বর্তমান অবস্থার প্রতিনিধিত্ব করে sync-token পেতে ঠিকানা বইতে sync-token PROPFIND অনুরোধ ব্যবহার করে। ক্লায়েন্ট অ্যাপ্লিকেশনগুলিকে অবশ্যই এই মান সঞ্চয় করতে হবে এবং পর্যায়ক্রমিক sync-collection REPORT অনুরোধগুলি ইস্যু করতে হবে যা শেষ জারি করা sync-token থেকে পরিবর্তনগুলি নির্ধারণ করতে হবে৷ ইস্যু করা টোকেনগুলি 29 দিনের জন্য বৈধ, এবং REPORT প্রতিক্রিয়াতে একটি নতুন sync-token থাকবে৷
• ETags ব্যবহার করে
  • ক্লায়েন্ট অ্যাপ্লিকেশন অ্যাড্রেস বুক রিসোর্সে ( DEPTH_1 এর সমান DEPTH হেডার সহ) একটি getetag PROPFIND অনুরোধ জারি করে৷ প্রতিটি পরিচিতির ETag মান বজায় রাখার মাধ্যমে, একটি ক্লায়েন্ট প্রোগ্রাম তাদের ETag পরিবর্তিত পরিচিতিগুলির মান অনুরোধ করতে পারে।
• পরিচিতি পুনরুদ্ধার করা হচ্ছে
  • ক্লায়েন্ট অ্যাপ্লিকেশন addressbook-multiget REPORT অনুরোধ জারি করে পরিচিতিগুলি পুনরুদ্ধার করে। যোগাযোগের URI-এর একটি তালিকা দেওয়া হলে, প্রতিবেদনটি ভিকার্ড 3.0 মান হিসাবে অনুরোধ করা সমস্ত পরিচিতি ফেরত দেয়। প্রতিটি এন্ট্রি যোগাযোগের জন্য একটি ETag অন্তর্ভুক্ত.
• একটি পরিচিতি সন্নিবেশ করা হচ্ছে
  • ক্লায়েন্ট অ্যাপ্লিকেশন VCard 3.0 বিন্যাসে নতুন পরিচিতির সাথে একটি POST অনুরোধ জারি করে। প্রতিক্রিয়াতে নতুন পরিচিতির আইডি থাকবে।
• একটি পরিচিতি আপডেট করা হচ্ছে
  • ক্লায়েন্ট অ্যাপ্লিকেশনগুলি VCard 3.0 বিন্যাসে আপডেট হওয়া পরিচিতির সাথে একটি PUT অনুরোধ জারি করে। পরিচিতি আপডেট করা হয় যদি পরিচিতিটি ঠিকানা বইতে আগে থেকেই থাকে।
  • ক্লায়েন্ট অ্যাপ্লিকেশনে পরিচিতির বর্তমানে পরিচিত ETag সহ একটি If-Match শিরোনাম অন্তর্ভুক্ত করা উচিত। সার্ভার তখন PUT অনুরোধ ( HTTP 412 সহ) প্রত্যাখ্যান করবে যদি সার্ভারে বর্তমান ETag ক্লায়েন্ট প্রোগ্রামের পাঠানো ETag থেকে আলাদা হয়। এটি আপডেটের আশাবাদী ক্রমিককরণের অনুমতি দেয়।
• একটি পরিচিতি মুছে ফেলা হচ্ছে
  • ক্লায়েন্ট অ্যাপ্লিকেশনগুলি পরিচিতি URI-এর বিরুদ্ধে একটি DELETE অনুরোধ জারি করে একটি পরিচিতি মুছে দেয়।