এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

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

উল্লেখ্য যে, সমস্ত উদাহরণে একটি রিড-অনলি Firebase Realtime Database ( docs-example.firebaseio.com ) ব্যবহার করা হয়েছে। এই Realtime Database URL-টি আপনার অ্যাক্সেস আছে এমন Firebase কনসোলের URL দিয়ে প্রতিস্থাপন করুন।

PUT ব্যবহার করে ডেটা লেখা

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

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

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'

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

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

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

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

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

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

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

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

শর্তসাপেক্ষ অনুরোধগুলো সাধারণ 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 অনুরোধ 200 OK HTTP স্ট্যাটাস কোড এবং JSON null সম্বলিত একটি প্রতিক্রিয়ার মাধ্যমে নির্দেশিত হবে।

ইউআরআই প্যারামিটার

ডাটাবেসে ডেটা লেখার সময় 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'

যদি টোকেন debug ফ্ল্যাগ সেট করা থাকে, তাহলে রেসপন্সের X-Firebase-Auth-Debug হেডারে ডিবাগ তথ্য পাওয়া যাবে।

প্রিন্ট

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

ডেটা লেখার সময় সার্ভারের আউটপুট বন্ধ করতে, আমরা আমাদের অনুরোধে 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 স্ট্যাটাস কোড
৪০০টি ত্রুটিপূর্ণ অনুরোধ	নিম্নলিখিত ত্রুটি অবস্থাগুলির মধ্যে একটি: `PUT` বা `POST` ডেটা পার্স করা সম্ভব নয়। `PUT` বা `POST` ডেটা অনুপস্থিত। অনুরোধটি প্রয়োজনের চেয়ে বড় ডেটা `PUT` বা `POST` চেষ্টা করছে। REST API কলটির পাথের অংশ হিসেবে অবৈধ চাইল্ড নাম রয়েছে। REST API কল পাথটি অনেক দীর্ঘ। অনুরোধটিতে একটি অপরিচিত সার্ভার মান রয়েছে। আপনার Firebase Realtime Database Security Rules কোয়েরিটির জন্য ইনডেক্স সংজ্ঞায়িত করা নেই। অনুরোধটি নির্দিষ্ট করা কোয়েরি প্যারামিটারগুলোর মধ্যে একটিকে সমর্থন করে না। অনুরোধটিতে কোয়েরি প্যারামিটারের সাথে একটি শ্যালো `GET` অনুরোধ মিশ্রিত করা হয়েছে।
৪০১ অননুমোদিত	নিম্নলিখিত ত্রুটি অবস্থাগুলির মধ্যে একটি: প্রমাণীকরণ টোকেনটির মেয়াদ শেষ হয়ে গেছে। অনুরোধে ব্যবহৃত প্রমাণীকরণ টোকেনটি অবৈধ। অ্যাক্সেস টোকেন দিয়ে প্রমাণীকরণ ব্যর্থ হয়েছে। অনুরোধটি আপনার Firebase Realtime Database Security Rules লঙ্ঘন করে।
৪০৪ পাওয়া যায়নি	নির্দিষ্ট ফায়ারবেস ডাটাবেসটি খুঁজে পাওয়া যায়নি।
৫০০ অভ্যন্তরীণ সার্ভার ত্রুটি	সার্ভার থেকে একটি ত্রুটি পাওয়া গেছে। আরও বিস্তারিত জানতে ত্রুটির বার্তাটি দেখুন।
৫০৩ পরিষেবা অনুপলব্ধ	নির্দিষ্ট ফায়ারবেস রিয়েলটাইম ডেটাবেসটি সাময়িকভাবে অনুপলব্ধ, যার কারণে অনুরোধটি চেষ্টা করা হয়নি।

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

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

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

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

PUT ব্যবহার করে ডেটা লেখা

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

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

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

ডেটা অপসারণ

ইউআরআই প্যারামিটার

কর্তৃপক্ষ

প্রিন্ট

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

লেখার পারফরম্যান্স উন্নত করা

ত্রুটির অবস্থা

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