ডেটা সংরক্ষণ করা হচ্ছে

ডেটা সংরক্ষণের উপায়

রাখুন একটি নির্দিষ্ট পাথে ডেটা লিখুন বা প্রতিস্থাপন করুন, যেমন fireblog/users/user1/<data>
প্যাচ সমস্ত ডেটা প্রতিস্থাপন না করে একটি নির্দিষ্ট পথের জন্য কিছু কী আপডেট করুন।
পোস্ট আমাদের Firebase ডাটাবেসের ডেটা তালিকায় যোগ করুন । আমরা যখনই POST অনুরোধ পাঠাই, Firebase ক্লায়েন্ট একটি অনন্য কী তৈরি করে, যেমন fireblog/users/<unique-id>/<data>
মুছে ফেলুন নির্দিষ্ট Firebase ডাটাবেস রেফারেন্স থেকে ডেটা সরান।

PUT দিয়ে ডেটা লেখা

REST API এর মাধ্যমে মৌলিক লেখার কাজ হল PUT । ডেটা সংরক্ষণের বিষয়টি প্রদর্শনের জন্য, আমরা পোস্ট এবং ব্যবহারকারীদের নিয়ে একটি ব্লগিং অ্যাপ্লিকেশন তৈরি করব। আমাদের অ্যাপ্লিকেশনের সমস্ত ডেটা Firebase ডাটাবেস URL `https://docs-examples.firebaseio.com/fireblog`-এ `fireblog`-এর পথের নীচে সংরক্ষণ করা হবে।

আমাদের Firebase ডাটাবেসে কিছু ব্যবহারকারীর তথ্য সংরক্ষণ করে শুরু করা যাক। আমরা প্রতিটি ব্যবহারকারীর একটি অনন্য ব্যবহারকারীর নাম দিয়ে সংরক্ষণ করব, এবং আমরা তাদের পুরো নাম এবং জন্ম তারিখও সংরক্ষণ করব। যেহেতু প্রতিটি ব্যবহারকারীর একটি অনন্য ব্যবহারকারীর নাম থাকবে, তাই এখানে POST এর পরিবর্তে PUT ব্যবহার করা যুক্তিসঙ্গত কারণ আমাদের কাছে ইতিমধ্যেই কী আছে এবং একটি তৈরি করার প্রয়োজন নেই।

PUT ব্যবহার করে, আমরা আমাদের Firebase ডাটাবেসে একটি স্ট্রিং, সংখ্যা, বুলিয়ান, অ্যারে বা যেকোনো JSON অবজেক্ট লিখতে পারি। এই ক্ষেত্রে আমরা এটিকে একটি অবজেক্ট পাস করব:

curl -X PUT -d '{
  "alanisawesome": {
    "name": "Alan Turing",
    "birthday": "June 23, 1912"
  }
}' 'https://docs-examples.firebaseio.com/fireblog/users.json'

যখন একটি JSON অবজেক্ট ডাটাবেসে সংরক্ষণ করা হয়, তখন অবজেক্টের বৈশিষ্ট্যগুলি স্বয়ংক্রিয়ভাবে একটি নেস্টেড পদ্ধতিতে চাইল্ড লোকেশনে ম্যাপ করা হয়। যদি আমরা নতুন তৈরি নোডে নেভিগেট করি, তাহলে আমরা "Alan Turing" মানটি দেখতে পাব। আমরা সরাসরি চাইল্ড লোকেশনেও ডেটা সংরক্ষণ করতে পারি:

curl -X PUT -d '"Alan Turing"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/name.json'
curl -X PUT -d '"June 23, 1912"' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome/birthday.json'

উপরের দুটি উদাহরণ - একটি বস্তুর সাথে একই সময়ে মান লেখা এবং চাইল্ড লোকেশনে আলাদাভাবে লেখা - এর ফলে একই ডেটা আমাদের Firebase ডাটাবেসে সংরক্ষণ করা হবে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing"
    }
  }
}

একটি সফল অনুরোধ 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে এবং প্রতিক্রিয়ায় আমরা ডাটাবেসে যে ডেটা লিখেছি তা থাকবে। প্রথম উদাহরণটি কেবলমাত্র একটি ইভেন্ট ট্রিগার করবে যারা ডেটা দেখছে এমন ক্লায়েন্টদের উপর, যেখানে দ্বিতীয় উদাহরণটি দুটি ট্রিগার করবে। এটি মনে রাখা গুরুত্বপূর্ণ যে যদি ডেটা ইতিমধ্যেই ব্যবহারকারীর পথে বিদ্যমান থাকে, তবে প্রথম পদ্ধতিটি এটিকে ওভাররাইট করবে, তবে দ্বিতীয় পদ্ধতিটি কেবলমাত্র প্রতিটি পৃথক চাইল্ড নোডের মান পরিবর্তন করবে এবং অন্যান্য চাইল্ড নোড অপরিবর্তিত রাখবে। PUT আমাদের JavaScript SDK-তে set() এর সমতুল্য।

PATCH ব্যবহার করে ডেটা আপডেট করা হচ্ছে

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

curl -X PATCH -d '{
  "nickname": "Alan The Machine"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

উপরের অনুরোধটি আমাদের alanisawesome অবজেক্টে nickname লিখবে, name বা birthday শিশু মুছে না ফেলে। মনে রাখবেন যে আমরা যদি এখানে একটি PUT অনুরোধ জারি করতাম, তাহলে name এবং birthday মুছে ফেলা হত কারণ সেগুলি অনুরোধে অন্তর্ভুক্ত ছিল না। আমাদের Firebase ডাটাবেসের ডেটা এখন এইরকম দেখাচ্ছে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    }
  }
}

একটি সফল অনুরোধ 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে এবং প্রতিক্রিয়াটিতে ডাটাবেসে লেখা আপডেট করা ডেটা থাকবে।

ফায়ারবেস মাল্টি-পাথ আপডেটগুলিকেও সমর্থন করে। এর অর্থ হল PATCH এখন একই সময়ে আপনার ফায়ারবেস ডাটাবেসের একাধিক স্থানে মান আপডেট করতে পারে, এটি একটি শক্তিশালী বৈশিষ্ট্য যা আপনাকে আপনার ডেটা ডিনরমালাইজ করতে সাহায্য করে। মাল্টি-পাথ আপডেট ব্যবহার করে, আমরা একই সময়ে অ্যালান এবং গ্রেস উভয়ের ডাকনাম যোগ করতে পারি:

curl -X PATCH -d '{
  "alanisawesome/nickname": "Alan The Machine",
  "gracehopper/nickname": "Amazing Grace"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

এই আপডেটের পর, অ্যালান এবং গ্রেস উভয়েরই ডাকনাম যুক্ত করা হয়েছে:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "date_of_birth": "December 9, 1906",
      "full_name": "Grace Hopper",
      "nickname": "Amazing Grace"
    }
  }
}

মনে রাখবেন যে, পাথ সহ অবজেক্ট লিখে অবজেক্ট আপডেট করার চেষ্টা করলে ভিন্ন আচরণ দেখা দেবে। আসুন দেখে নেওয়া যাক যদি আমরা গ্রেস এবং অ্যালানকে এভাবে আপডেট করার চেষ্টা করি তাহলে কী হবে:

curl -X PATCH -d '{
  "alanisawesome": {"nickname": "Alan The Machine"},
  "gracehopper": {"nickname": "Amazing Grace"}
}' \
  'https://docs-examples.firebaseio.com/fireblog/users.json'

এর ফলে ভিন্ন আচরণ দেখা দেয়, যেমন সম্পূর্ণ /fireblog/users নোড ওভাররাইট করা:

{
  "users": {
    "alanisawesome": {
      "nickname": "Alan The Machine"
    },
    "gracehop": {
      "nickname": "Amazing Grace"
    }
  }
}

শর্তসাপেক্ষ অনুরোধের মাধ্যমে ডেটা আপডেট করা

আপনি শর্তসাপেক্ষ অনুরোধ, লেনদেনের সমতুল্য REST ব্যবহার করে ডেটা তার বিদ্যমান অবস্থা অনুসারে আপডেট করতে পারেন। উদাহরণস্বরূপ, যদি আপনি একটি আপভোট কাউন্টার বাড়াতে চান এবং নিশ্চিত করতে চান যে গণনাটি একাধিক, একযোগে আপভোটগুলি সঠিকভাবে প্রতিফলিত করে, তাহলে কাউন্টারে নতুন মান লেখার জন্য একটি শর্তসাপেক্ষ অনুরোধ ব্যবহার করুন। দুটি লেখার পরিবর্তে যা কাউন্টারটিকে একই সংখ্যায় পরিবর্তন করে, একটি লেখার অনুরোধ ব্যর্থ হয় এবং আপনি তারপরে নতুন মান দিয়ে অনুরোধটি পুনরায় চেষ্টা করতে পারেন।
  1. কোনও স্থানে শর্তসাপেক্ষ অনুরোধ সম্পাদন করতে, সেই স্থানে বর্তমান ডেটার জন্য অনন্য শনাক্তকারী, অথবা ETag পান। যদি সেই স্থানে ডেটা পরিবর্তন হয়, তাহলে ETagও পরিবর্তিত হয়। আপনি PATCH ছাড়া অন্য যেকোনো পদ্ধতি ব্যবহার করে ETag অনুরোধ করতে পারেন। নিম্নলিখিত উদাহরণে একটি GET অনুরোধ ব্যবহার করা হয়েছে।
    curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
    বিশেষ করে হেডারে ETag কল করলে HTTP রেসপন্সে নির্দিষ্ট অবস্থানের ETag ফেরত আসে।
    HTTP/1.1 200 OK
    Content-Length: 6
    Content-Type: application/json; charset=utf-8
    Access-Control-Allow-Origin: *
    ETag: [ETAG_VALUE]
    Cache-Control: no-cache
    
    10 // Current value of the data at the specified location
  2. আপনার পরবর্তী PUT অথবা DELETE অনুরোধে রিটার্ন করা ETag অন্তর্ভুক্ত করুন যাতে সেই ETag মানের সাথে বিশেষভাবে মেলে এমন ডেটা আপডেট করা যায়। আমাদের উদাহরণ অনুসরণ করে, কাউন্টারটিকে ১১-এ আপডেট করতে, অথবা প্রাথমিকভাবে আনা ১০ মানের চেয়ে ১-এ বড় করতে, এবং যদি মানটি আর মেলে না, তাহলে অনুরোধটি ব্যর্থ করতে, নিম্নলিখিত কোডটি ব্যবহার করুন:
    curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match:[ETAG_VALUE]'
    যদি নির্দিষ্ট স্থানে ডেটার মান এখনও 10 হয়, তাহলে PUT অনুরোধে ETag মিলবে এবং অনুরোধটি সফল হবে, ডাটাবেসে 11 লেখা হবে।
    HTTP/1.1 200 OK
    Content-Length: 6
    Content-Type: application/json; charset=utf-8
    Access-Control-Allow-Origin: *
    Cache-Control: no-cache
    
    11 // New value of the data at the specified location, written by the conditional request
    যদি অবস্থানটি আর ETag এর সাথে না মেলে, যা অন্য ব্যবহারকারী ডাটাবেসে একটি নতুন মান লিখে ফেললে ঘটতে পারে, তাহলে অবস্থানটি না লিখে অনুরোধটি ব্যর্থ হয়। রিটার্ন প্রতিক্রিয়ায় নতুন মান এবং ETag অন্তর্ভুক্ত থাকে।
    HTTP/1.1 412 Precondition Failed
    Content-Length: 6
    Content-Type: application/json; charset=utf-8
    Access-Control-Allow-Origin: *
    ETag: [ETAG_VALUE]
    Cache-Control: no-cache
    
    12 // New value of the data at the specified location
  3. যদি আপনি অনুরোধটি পুনরায় চেষ্টা করার সিদ্ধান্ত নেন, তাহলে নতুন তথ্য ব্যবহার করুন। Realtime Database ব্যর্থ শর্তাধীন অনুরোধগুলি স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করে না। তবে, ব্যর্থ প্রতিক্রিয়া দ্বারা ফেরত আসা তথ্য দিয়ে আপনি নতুন মান এবং ETag ব্যবহার করে একটি নতুন শর্তাধীন অনুরোধ তৈরি করতে পারেন।

REST-ভিত্তিক শর্তসাপেক্ষ অনুরোধগুলি HTTP if-match স্ট্যান্ডার্ড বাস্তবায়ন করে। তবে, তারা নিম্নলিখিত দিক থেকে স্ট্যান্ডার্ড থেকে পৃথক:

  • প্রতিটি if-match অনুরোধের জন্য আপনি কেবল একটি ETag মান সরবরাহ করতে পারবেন, একাধিক নয়।
  • যদিও স্ট্যান্ডার্ডটি পরামর্শ দেয় যে সমস্ত অনুরোধের সাথে ETags ফেরত দেওয়া হবে, রিয়েলটাইম ডেটাবেস কেবল X-Firebase-ETag হেডার সহ অনুরোধ সহ ETags ফেরত দেয়। এটি স্ট্যান্ডার্ড অনুরোধের জন্য বিলিং খরচ হ্রাস করে।

শর্তসাপেক্ষ অনুরোধগুলি সাধারণ REST অনুরোধের চেয়ে ধীর হতে পারে।

ডেটা তালিকা সংরক্ষণ করা হচ্ছে

Firebase ডাটাবেস রেফারেন্সে যোগ করা প্রতিটি শিশুর জন্য একটি অনন্য, টাইমস্ট্যাম্প-ভিত্তিক কী তৈরি করতে আমরা একটি POST অনুরোধ পাঠাতে পারি। আমাদের users পথের জন্য, আমাদের নিজস্ব কীগুলি সংজ্ঞায়িত করা যুক্তিসঙ্গত ছিল কারণ প্রতিটি ব্যবহারকারীর একটি অনন্য ব্যবহারকারীর নাম থাকে। কিন্তু যখন ব্যবহারকারীরা অ্যাপে ব্লগ পোস্ট যোগ করেন, তখন আমরা প্রতিটি ব্লগ পোস্টের জন্য একটি কী স্বয়ংক্রিয়ভাবে তৈরি করতে একটি POST অনুরোধ ব্যবহার করব:

curl -X POST -d '{
  "author": "alanisawesome",
  "title": "The Turing Machine"
}' 'https://docs-examples.firebaseio.com/fireblog/posts.json'

আমাদের posts পাথে এখন নিম্নলিখিত তথ্য রয়েছে:

{
  "posts": {
    "-JSOpn9ZC54A4P4RoqVa": {
      "author": "alanisawesome",
      "title": "The Turing Machine"
    }
  }
}

লক্ষ্য করুন যে -JSOpn9ZC54A4P4RoqVa কীটি আমাদের জন্য স্বয়ংক্রিয়ভাবে তৈরি হয়েছে কারণ আমরা একটি POST অনুরোধ ব্যবহার করেছি। একটি সফল অনুরোধ 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে এবং প্রতিক্রিয়াটিতে নতুন ডেটার কী থাকবে যা যোগ করা হয়েছিল:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

ডেটা অপসারণ

ডাটাবেস থেকে ডেটা মুছে ফেলার জন্য, আমরা যে পাথ থেকে ডেটা মুছে ফেলতে চাই তার URL সহ একটি DELETE অনুরোধ পাঠাতে পারি। নিম্নলিখিতটি আমাদের users পাথ থেকে অ্যালানকে মুছে ফেলবে:

curl -X DELETE \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

একটি সফল DELETE অনুরোধ JSON null ধারণকারী একটি 200 OK HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে।

URI প্যারামিটার

ডাটাবেসে ডেটা লেখার সময় REST API নিম্নলিখিত URI প্যারামিটারগুলি গ্রহণ করে:

প্রমাণীকরণ

auth অনুরোধ প্যারামিটারটি Firebase Realtime Database Security Rules দ্বারা সুরক্ষিত ডেটা অ্যাক্সেসের অনুমতি দেয় এবং সকল ধরণের অনুরোধ দ্বারা সমর্থিত। আর্গুমেন্টটি আমাদের Firebase অ্যাপ সিক্রেট অথবা একটি প্রমাণীকরণ টোকেন হতে পারে, যা আমরা ব্যবহারকারীর অনুমোদন বিভাগে কভার করব। নিম্নলিখিত উদাহরণে আমরা একটি auth প্যারামিটার সহ একটি POST অনুরোধ পাঠাই, যেখানে CREDENTIAL হল আমাদের Firebase অ্যাপ সিক্রেট অথবা একটি প্রমাণীকরণ টোকেন:

curl -X POST -d '{"Authenticated POST request"}' \
  'https://docs-examples.firebaseio.com/auth-example.json?auth=CREDENTIAL'

ছাপা

print প্যারামিটার আমাদের ডাটাবেস থেকে আমাদের প্রতিক্রিয়ার ফর্ম্যাট নির্দিষ্ট করতে সাহায্য করে। আমাদের অনুরোধে print=pretty যোগ করলে ডেটা মানুষের পঠনযোগ্য ফর্ম্যাটে ফিরে আসবে। print=pretty GET , PUT , POST , PATCH , এবং DELETE অনুরোধ দ্বারা সমর্থিত।

ডেটা লেখার সময় সার্ভার থেকে আউটপুট দমন করার জন্য, আমরা আমাদের অনুরোধে print=silent যোগ করতে পারি। অনুরোধ সফল হলে ফলাফলটি খালি থাকবে এবং 204 No Content HTTP স্ট্যাটাস কোড দ্বারা নির্দেশিত হবে। print=silent GET , PUT , POST , এবং PATCH অনুরোধ দ্বারা সমর্থিত।

সার্ভার মান লেখা

সার্ভারের মানগুলি একটি প্লেসহোল্ডার মান ব্যবহার করে একটি স্থানে লেখা যেতে পারে, যা একটি একক ".sv" কী সহ একটি বস্তু। সেই কীটির মান হল সেই ধরণের সার্ভার মানের যা আমরা সেট করতে চাই। উদাহরণস্বরূপ, ব্যবহারকারী তৈরি করার সময় একটি টাইমস্ট্যাম্প সেট করার জন্য আমরা নিম্নলিখিতগুলি করতে পারি:

curl -X PUT -d '{".sv": "timestamp"}' \
  'https://docs-examples.firebaseio.com/alanisawesome/createdAt.json'

"timestamp" হল একমাত্র সমর্থিত সার্ভার মান, এবং মিলিসেকেন্ডে UNIX যুগের পর থেকে সময়কাল।

লেখার কর্মক্ষমতা উন্নত করা

যদি আমরা ডাটাবেসে প্রচুর পরিমাণে ডেটা লিখি, তাহলে আমরা আমাদের লেখার কর্মক্ষমতা উন্নত করতে এবং ব্যান্ডউইথের ব্যবহার কমাতে print=silent প্যারামিটার ব্যবহার করতে পারি। স্বাভাবিক লেখার আচরণে, সার্ভারটি লেখা JSON ডেটা দিয়ে প্রতিক্রিয়া জানায়। যখন print=silent নির্দিষ্ট করা হয়, তখন ডেটা পাওয়ার সাথে সাথে সার্ভার সংযোগটি বন্ধ করে দেয়, যার ফলে ব্যান্ডউইথের ব্যবহার কমে যায়।

যেসব ক্ষেত্রে আমরা ডাটাবেসে অনেক অনুরোধ করছি, সেখানে HTTP হেডারে Keep-Alive অনুরোধ পাঠিয়ে আমরা HTTPS সংযোগটি পুনরায় ব্যবহার করতে পারি।

ত্রুটির শর্তাবলী

REST API এই পরিস্থিতিতে ত্রুটি কোডগুলি ফেরত দেবে:

HTTP স্থিতি কোড
৪০০ খারাপ অনুরোধ

নিম্নলিখিত ত্রুটির শর্তগুলির মধ্যে একটি:

  • PUT অথবা POST ডেটা পার্স করা যাচ্ছে না।
  • PUT অথবা POST ডেটা অনুপস্থিত।
  • অনুরোধটি খুব বড় ডেটা PUT বা POST করার চেষ্টা করে।
  • REST API কলটিতে পাথের অংশ হিসেবে অবৈধ শিশু নাম রয়েছে।
  • REST API কল পাথটি খুব দীর্ঘ।
  • অনুরোধটিতে একটি অচেনা সার্ভার মান রয়েছে।
  • আপনার Firebase Realtime Database Security Rules কোয়েরির সূচক সংজ্ঞায়িত করা হয়নি।
  • অনুরোধটি নির্দিষ্ট করা কোয়েরি প্যারামিটারগুলির একটিও সমর্থন করে না।
  • অনুরোধটি একটি অগভীর GET অনুরোধের সাথে কোয়েরি প্যারামিটারগুলিকে মিশ্রিত করে।
401 অননুমোদিত

নিম্নলিখিত ত্রুটির শর্তগুলির মধ্যে একটি:

  • প্রমাণীকরণ টোকেনের মেয়াদ শেষ হয়ে গেছে।
  • অনুরোধে ব্যবহৃত প্রমাণীকরণ টোকেনটি অবৈধ।
  • একটি access_token দিয়ে প্রমাণীকরণ ব্যর্থ হয়েছে।
  • অনুরোধটি আপনার Firebase Realtime Database Security Rules লঙ্ঘন করে।
৪০৪ খুঁজে পাওয়া যায়নি নির্দিষ্ট Firebase ডাটাবেসটি পাওয়া যায়নি।
৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি সার্ভারটি একটি ত্রুটি ফেরত দিয়েছে। আরও বিস্তারিত জানার জন্য ত্রুটি বার্তাটি দেখুন।
৫০৩ পরিষেবা অনুপলব্ধ নির্দিষ্ট Firebase রিয়েলটাইম ডেটাবেসটি সাময়িকভাবে অনুপলব্ধ, যার অর্থ অনুরোধটি চেষ্টা করা হয়নি।

ডেটা সুরক্ষিত করা

ফায়ারবেসের একটি নিরাপত্তা ভাষা রয়েছে যা আমাদের নির্ধারণ করতে দেয় যে কোন ব্যবহারকারীরা আমাদের ডেটার বিভিন্ন নোডে পড়ার এবং লেখার অ্যাক্সেস পেয়েছে। আপনি Realtime Database Security Rules এটি সম্পর্কে আরও পড়তে পারেন।

এখন যেহেতু আমরা ডেটা সংরক্ষণের বিষয়টি আলোচনা করেছি, আমরা পরবর্তী বিভাগে REST API এর মাধ্যমে Firebase ডাটাবেস থেকে কীভাবে আমাদের ডেটা পুনরুদ্ধার করতে হয় তা শিখতে পারি।