গুগল হেলথ এপিআই-তে ডেটা ব্যবস্থাপনা

গুগল হেলথ এপিআই-তে ডেটা নিয়ে কাজ করার মূল ভিত্তি হলো ক্লাউডে থাকা গুগল হেলথ এপিআই ডেটাস্টোর এবং আপনার নিজের অ্যাপ বা ব্যাকএন্ড ডেটাস্টোরের মধ্যে ডেটা সিঙ্ক করার একটি চক্র। তবে, বিভিন্ন কারণের উপর নির্ভর করে এই চক্রটি ভিন্ন রূপ নিতে পারে:

  • আপনি কি গুগল হেলথ এপিআই-তে ডেটা লিখছেন? শুধু পড়ছেন? নাকি দুটোই করছেন?
  • আপনার ডেটাস্টোরটি কি অ্যাপ বা ডিভাইসে স্থানীয়ভাবে অবস্থিত? নাকি আপনার নিজস্ব ক্লাউডে?
  • ব্যবহারকারীর অ্যাপ এবং পরিধানযোগ্য ডিভাইসের মধ্যে কি গুগল হেলথ এপিআই ডেটা সিঙ্ক করার প্রয়োজন আছে? আপনি কত ঘন ঘন ডিভাইসগুলো সিঙ্ক করেন?
  • আপনি কী ধরনের ডেটা নিয়ে কাজ করছেন? সাধারণ গণনা? পরিমাপের একক? নাকি বিভিন্ন স্যাম্পলিং হারযুক্ত সিরিজ?
  • আপনার অ্যাপটি ব্যাকগ্রাউন্ডে থাকা অবস্থায় আপনি কি ডেটা পড়ার পরিকল্পনা করছেন?
  • আপনার অ্যাপ ব্যবহারকারীর অনুমতি পাওয়ার আগে রেকর্ড করা ঐতিহাসিক ডেটা নিয়ে কাজ করার পরিকল্পনা কি আপনার আছে?

এই সবকিছু কীভাবে একসাথে কাজ করে তা বোঝার জন্য, গুগল হেলথ এপিআই সিঙ্ক লাইফসাইকেলটি দেখুন। এই লাইফসাইকেলের দুটি সংস্করণ রয়েছে: স্ট্যান্ডার্ড (পড়া এবং লেখার ক্ষমতা) এবং রিড-অনলি।

স্ট্যান্ডার্ড সিঙ্ক জীবনচক্র

গুগল হেলথ এপিআই-তে স্ট্যান্ডার্ড সিঙ্ক লাইফসাইকেল
চিত্র ১: গুগল হেলথ এপিআই-এর স্ট্যান্ডার্ড সিঙ্ক লাইফসাইকেল

গুগল হেলথ এপিআই-এর সাথে ইন্টিগ্রেট করার অর্থ হলো কোনো অ্যাপ বা ব্যাকএন্ড ডেটাস্টোরে ডেটা কপি করা। এই ডকুমেন্টেশনে ব্যবহারের সুবিধার জন্য, আমরা এই ডেটাস্টোরটিকে ‘ডেভেলপার ডেটাস্টোর’ বলব।

এখানে "কপি" বলতে যেকোনো স্বতন্ত্র কার্যকলাপকে বোঝানো হতে পারে, যেমন গুগল হেলথ এপিআই থেকে ডেটা পড়া (ডেভেলপার ডেটাস্টোরে কপি করা) অথবা গুগল হেলথ এপিআই-তে ডেটা লেখা (গুগল হেলথ এপিআই-তে কপি করা)। একটি নির্দিষ্ট ক্রমে এই কাজগুলো বারবার করাই হলো সিঙ্ক লাইফসাইকেল।

চিত্র ১-এ আদর্শ সিঙ্ক জীবনচক্রটি দেখানো হয়েছে, যেখানে পূর্বে উল্লিখিত কোনো বিষয় বিবেচনা না করেই পঠন ও লিখন কার্যক্রম অন্তর্ভুক্ত রয়েছে।

লিখুন

  1. লেখার জন্য নতুন ডেটা প্রস্তুত করুন — একটি বাহ্যিক ডিভাইস বা অ্যাপ থেকে ডেটা স্থানান্তর করুন এবং ডেটা পয়েন্টগুলিকে Google Health API ডেটা টাইপের সাথে সামঞ্জস্যপূর্ণ JSON উপস্থাপনায় ফরম্যাট করুন। উল্লেখ্য যে, এই মুহূর্তে Health API-তে লেখার জন্য ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি সমর্থিত নয়। এই ধরনের আইডি একটি POST মাধ্যমে প্রদান করা যেতে পারে, কিন্তু সেগুলি উপেক্ষা করা হয়।
  2. রেকর্ড আপসার্ট করুন — REST এন্ডপয়েন্ট ব্যবহার করে Google Health API-তে ডেটা পয়েন্ট জমা দিন। রেকর্ড তৈরি করার জন্য POST এবং বিদ্যমান রেকর্ড ইনসার্ট ও আপডেট করার জন্য PATCH ব্যবহার করুন। PATCH অপারেশনের জন্য প্রয়োজনীয় আইডিগুলো পূর্ববর্তী কোনো POST অপারেশন (পূর্ববর্তী চক্রের পরবর্তী ধাপ) থেকে আসবে।
  3. ফেরত আসা রিসোর্স আইডিগুলো প্রসেস করুন — সার্ভার-জেনারেটেড আইডি ব্যবহার করার সময়, ভবিষ্যতের আপডেট ( PATCH ) বা ডিলিট ( DELETE ) সক্ষম করার জন্য সার্ভার থেকে ফেরত আসা রিসোর্সের name বা আইডি আপনার ডেভেলপার ডেটাস্টোরে এক্সট্র্যাক্ট এবং পারসিস্ট করুন। এই দুই প্রকার সম্পর্কে আরও তথ্যের জন্য আইডেন্টিফিকেশন স্ট্র্যাটেজিস দেখুন।

পড়ুন

  1. রেকর্ড পড়ুন — REST এন্ডপয়েন্ট ( filter কোয়েরি প্যারামিটার এবং pageToken পেজিনেশন সহ GET , অথবা rollUp এবং dailyRollUp মতো অ্যাগ্রিগেশন এন্ডপয়েন্ট) ব্যবহার করে Google Health API থেকে নতুন ডেটা এবং বিদ্যমান ডেটার পরিবর্তনগুলি সংগ্রহ করুন, অথবা ওয়েবহুক সাবস্ক্রিপশন ( projects.subscribers ) ব্যবহার করে রিয়েল-টাইম নোটিফিকেশন পান। একটি নোটিফিকেশন শুধুমাত্র নতুন ডেটা উপলব্ধ হওয়ার বিষয়টি নির্দেশ করে, কিন্তু প্রকৃত ডেটা কী তা জানায় না।
  2. ডেভেলপার ডেটাস্টোর সমন্বয় করুন — আপনার ডেভেলপার ডেটাস্টোরে নতুন এবং আপডেট করা ডেটা সমন্বয় করুন।

এরপর বাহ্যিক ডিভাইস বা অ্যাপের নির্দিষ্ট প্রয়োজন অনুযায়ী এই চক্রটি উপযুক্ত বিরতিতে পুনরাবৃত্ত হয়। আপনার নিজস্ব ডেটাস্টোর এবং গুগল হেলথ এপিআই-এর মধ্যে ডেটা সিঙ্ক করার জন্য আমরা সাধারণত এই ক্রমটিই সুপারিশ করি।

শনাক্তকরণ কৌশল

আপনি যদি গুগল হেলথ এপিআই-তে ডেটা লিখতে চান, তবে গুগল হেলথ এপিআই-এর সাথে আপনার ইন্টিগ্রেশন তৈরি করার আগে, ডেটা পয়েন্ট (ডেটার মৌলিক একক) তৈরি করার সময় আপনাকে অবশ্যই একটি রিসোর্স আইডেন্টিফিকেশন স্ট্র্যাটেজি বেছে নিতে হবে।

বর্তমানে হেলথ এপিআই-তে রাইট (write) এর জন্য ক্লায়েন্ট-নির্ধারিত আইডি সমর্থিত নয়। এই ধরনের আইডি একটি POST মাধ্যমে প্রদান করা যেতে পারে, কিন্তু সেগুলি উপেক্ষা করা হয়। এই বিকল্পটির বিশদ বিবরণ শুধুমাত্র তথ্যের জন্য এখানে দেওয়া হয়েছে।

  1. সার্ভার-জেনারেটেড আইডি (ডিফল্ট অপশন) : ক্লায়েন্ট আইডি ছাড়া ডেটা জমা দেয় এবং গুগল হেলথ এপিআই ব্যাকএন্ড একটি অনন্য সিস্টেম আইডেন্টিফায়ার তৈরি করে ফেরত দেয়।
  2. ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি ( AIP-133 অনুযায়ী, এখনও সমর্থিত নয়) : ক্লায়েন্ট অ্যাপ একটি অনন্য শনাক্তকারী (যেমন, একটি UUID বা স্থানীয় ডেটাবেস প্রাইমারি কী) তৈরি করে এবং রিসোর্স তৈরির সময় পাথে তা সরবরাহ করে।

আপনার ইন্টিগ্রেশনের জন্য সঠিক পদ্ধতিটি বেছে নিতে সাহায্য করার উদ্দেশ্যে, নিম্নলিখিত সারণিতে উভয় শনাক্তকরণ কৌশলের তুলনা করা হয়েছে:

বৈশিষ্ট্য সার্ভার-উত্পাদিত আইডি ক্লায়েন্ট-নির্ধারিত কাস্টম আইডি
আইডি জেনারেশন POST নির্বাহের সময় সার্ভার একটি র‍্যান্ডম সিস্টেম আইডি তৈরি করে। ক্লায়েন্ট লেখার আগে স্থানীয়ভাবে একটি স্থিতিশীল আইডি (UUID v4 / অভ্যন্তরীণ PK) তৈরি করে।
রিসোর্স পাথ .../dataPoints/{server_id} (প্রতিক্রিয়ায় ফেরত দেওয়া হয়েছে) .../dataPoints/{custom_id}
পোস্ট-রাইট লোকাল স্টেপ আবশ্যক। ভবিষ্যতে আপডেট/ডিলিট করার জন্য প্রাপ্ত server_id অবশ্যই স্থানীয় ডেটাবেসে সংরক্ষণ করতে হবে। কোনোটিই নয়। অ্যাপটির কাছে আইডিটি আগে থেকেই রয়েছে।
আইডি ম্যাপিং টেবিল আবশ্যক। ক্লায়েন্টকে অবশ্যই একটি দ্বি-মুখী ম্যাপিং ( local_idserver_id ) বজায় রাখতে হবে। প্রয়োজন নেই। ক্লায়েন্ট সরাসরি তার নিজস্ব প্রাইমারি কী ব্যবহার করে।
পুনরায় চেষ্টার আচরণ (দুর্বল নেটওয়ার্ক) ডুপ্লিকেট হওয়ার ঝুঁকি। টাইম-আউট হয়ে যাওয়া একটি POST অনুরোধ পুনরায় চেষ্টা করলে একটি নতুন সার্ভার আইডি সহ একটি ডুপ্লিকেট রেকর্ড তৈরি হয়। নিরাপদ ও আইডম্পোটেন্ট। একই custom_id দিয়ে পুনরায় POST চেষ্টা করলে ডুপ্লিকেট তৈরি হওয়া প্রতিরোধ করা যায় ( 409 ALREADY_EXISTS রিটার্ন করে)।
অফলাইন সিঙ্ক সমর্থন সীমিত। অফিসিয়াল রিসোর্স আইডিগুলো ব্যবহার করার আগে অবশ্যই সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করতে হবে। সম্পূর্ণ। সত্তাগুলোকে স্থিতিশীল আইডি দিয়ে অফলাইনে তৈরি ও পরিবর্তন করা যায়, এবং পুনরায় সংযোগ স্থাপন করলে সেগুলো নির্বিঘ্নে সিঙ্ক হয়ে যায়।
বিন্যাস সীমাবদ্ধতা সম্পূর্ণভাবে সার্ভার দ্বারা পরিচালিত। অবশ্যই ^[a-z0-9-]{4,63}$ (৪-৬৩টি ছোট হাতের অক্ষর, সংখ্যা ও হাইফেন) অনুসরণ করতে হবে।
কখন বেছে নিতে হবে

সার্ভার-জেনারেটেড আইডি বেছে নিন যদি:

  • আপনার অ্যাপটি শুধুমাত্র লেখার বা যুক্ত করার সুবিধাযুক্ত (যেমন, টেলিমেট্রি বা পদক্ষেপের সংখ্যা পাঠানো যা কখনও আপডেট করা হয় না বা পরে মুছে ফেলা হয়)।
  • আপনার অ্যাপটি স্বতন্ত্র ডেটা পয়েন্টগুলোর কোনো স্থানীয় স্থায়ী ডেটাবেস রক্ষণাবেক্ষণ করে না।
  • আপনি স্ট্রিং ভ্যালিডেশনের সীমাবদ্ধতা (যেমন 4-63 অক্ষর) পরিচালনা না করে সরলতা পছন্দ করেন।

নিম্নলিখিত ক্ষেত্রে কাস্টম আইডি বেছে নিন:

  • আপনি একটি দ্বি-মুখী সিঙ্ক অ্যাপ পরিচালনা করেন যা বিভিন্ন ডিভাইসের মধ্যে স্বাস্থ্য রেকর্ড পড়ে, লেখে এবং আপডেট করে।
  • আপনার অ্যাপে একটি স্থানীয় ডেটাবেস (যেমন Room বা SQLite) আছে, যেখানে স্থানীয় প্রাইমারি কী ব্যবহার করে রেকর্ড সংরক্ষণ করা হয়।
  • আপনার ব্যবহারকারীরা অফলাইনে অথবা বিচ্ছিন্ন মোবাইল সংযোগের মাধ্যমে ডেটা রেকর্ড করেন, যেখানে নিরাপদ পুনঃপ্রচেষ্টার প্রয়োজন হয়।
  • আপনি আপনার ব্যাকএন্ড ডেটাবেস এবং এপিআই-এর মধ্যে আইডি ম্যাপিং টেবিলগুলো বাদ দিতে চান।

রিড-অনলি সিঙ্ক জীবনচক্র

গুগল হেলথ এপিআই-তে রিড-অনলি সিঙ্ক লাইফসাইকেল
চিত্র ২: গুগল হেলথ এপিআই-তে রিড-অনলি সিঙ্কের জীবনচক্র

যে অ্যাপ শুধুমাত্র গুগল হেলথ এপিআই থেকে ডেটা পড়তে চায়, তাকে অবশ্যই ডেটাগুলো তাদের ডেভেলপার ডেটাস্টোরে কপি করতে হবে এবং লাইফসাইকেলের রিকনসিলিয়েশন অংশটি পরিচালনা করতে হবে।

'পড়া' অংশে আলোচিত কাজগুলো এখানেও প্রযোজ্য।

চিত্র ২-এ পঠন-যোগ্য জীবনচক্রটি দেখানো হয়েছে।