Check out what’s new from Firebase at Google I/O 2022. Learn more

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

ডাটা সেভ করার উপায়

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

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

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

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

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

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

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

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'

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

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

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

প্যাচ দিয়ে ডেটা আপডেট করা হচ্ছে

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

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

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

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

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

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

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 অনুরোধ করতে পারেন। নিম্নলিখিত উদাহরণ একটি 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 এ ফেরত দেওয়া ETag অন্তর্ভুক্ত করুন বা DELETE মানের সাথে বিশেষভাবে মেলে এমন ডেটা আপডেট করার অনুরোধ করুন। আমাদের উদাহরণ অনুসরণ করে, কাউন্টারটিকে 11-এ আপডেট করতে বা 10-এর প্রারম্ভিক আনা মান থেকে 1 বড়, এবং যদি মানটি আর মেলে না, তাহলে অনুরোধটি ব্যর্থ করতে, নিম্নলিখিত কোডটি ব্যবহার করুন:
    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. আপনি অনুরোধটি পুনরায় চেষ্টা করার সিদ্ধান্ত নিলে নতুন তথ্য ব্যবহার করুন৷ রিয়েলটাইম ডেটাবেস স্বয়ংক্রিয়ভাবে ব্যর্থ হওয়া শর্তসাপেক্ষ অনুরোধগুলির পুনরায় চেষ্টা করে না। যাইহোক, আপনি ব্যর্থ প্রতিক্রিয়া দ্বারা ফিরে আসা তথ্যের সাথে একটি নতুন শর্তাধীন অনুরোধ তৈরি করতে নতুন মান এবং ETag ব্যবহার করতে পারেন।

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

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

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

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

ফায়ারবেস ডাটাবেস রেফারেন্সে যোগ করা প্রতিটি শিশুর জন্য একটি অনন্য, টাইমস্ট্যাম্প-ভিত্তিক কী তৈরি করতে আমরা একটি 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 রিয়েলটাইম ডেটাবেস নিয়ম দ্বারা সুরক্ষিত ডেটাতে অ্যাক্সেসের অনুমতি দেয় এবং সমস্ত ধরনের অনুরোধ দ্বারা সমর্থিত। যুক্তিটি হয় আমাদের 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" হল একমাত্র সমর্থিত সার্ভার মান, এবং এটি মিলিসেকেন্ডে ইউনিক্স যুগের পরের সময়।

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

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

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

ত্রুটি শর্ত

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

HTTP স্ট্যাটাস কোড
400 খারাপ অনুরোধ

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

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

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

404 পাওয়া যায়নি নির্দিষ্ট ফায়ারবেস ডাটাবেস পাওয়া যায়নি।
500 অভ্যন্তরীণ সার্ভার ত্রুটি৷ সার্ভার একটি ত্রুটি ফিরিয়ে দিয়েছে৷ আরো বিস্তারিত জানার জন্য ত্রুটি বার্তা দেখুন.
503 পরিষেবা অনুপলব্ধ৷ নির্দিষ্ট ফায়ারবেস রিয়েলটাইম ডেটাবেস সাময়িকভাবে অনুপলব্ধ, যার মানে অনুরোধের চেষ্টা করা হয়নি।

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

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

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