আপনার পছন্দের ভাষায় কন্টেন্ট অনুবাদ করতে Google তার AI প্রযুক্তি ব্যবহার করে। AI-এর মাধ্যমে করা অনুবাদে ভুল থাকতে পারে।

ডেটা সেভ করা

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

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

PUT-এর মাধ্যমে ডেটা লেখা

REST API-এর মাধ্যমে বেসিক রাইট অপারেশন হল PUT। ডেটা সেভ করার পদ্ধতি দেখাতে, আমরা পোস্ট ও ব্যবহারকারী সহ একটি ব্লগিং অ্যাপ্লিকেশন তৈরি করব। আমাদের অ্যাপ্লিকেশনের সব ডেটা `fireblog` পাথে, Firebase ডেটাবেস URL `https://docs-examples.firebaseio.com/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 স্ট্যাটাস কোড দেখানো হবে এবং উত্তরে ডেটাবেসে লেখা ডেটা থাকবে। প্রথম উদাহরণটি শুধুমাত্র ডেটা দেখছে এমন ক্লায়েন্টদের উপর একটি ইভেন্ট ট্রিগার করবে, যেখানে দ্বিতীয় উদাহরণটি দুটি ট্রিগার করবে। মনে রাখবেন, ব্যবহারকারীর পাথে আগে থেকেই ডেটা থাকলে, প্রথম পদ্ধতিটি সেটি ওভাররাইট করবে, কিন্তু দ্বিতীয় পদ্ধতিটি প্রতিটি আলাদা চাইল্ড নোডের ভ্যালু শুধু পরিবর্তন করবে এবং অন্যান্য চাইল্ড নোড অপরিবর্তিত রাখবে। আমাদের জাভাস্ক্রিপ্ট SDK-তে PUT-এর সমতুল্য হল set()।

PATCH-এর মাধ্যমে ডেটা আপডেট করা হচ্ছে

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

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 স্ট্যাটাস কোড দেখানো হবে এবং উত্তরে ডেটাবেসে লেখা আপডেট করা ডেটা থাকবে।

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

কোনও লোকেশনে শর্তসাপেক্ষ অনুরোধ করতে, সেই লোকেশনে বর্তমান ডেটার জন্য অনন্য শনাক্তকারী বা 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]'
```
নির্দিষ্ট লোকেশনে ডেটার মান এখনও ১০ হলে, PUT অনুরোধে ETag মিলে যায় এবং অনুরোধটি সফল হয়, ডেটাবেসে ১১ লেখা হয়।
```
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 ফেরত পাঠানো উচিত, Realtime Database শুধুমাত্র X-Firebase-ETag হেডার সহ অনুরোধের সাথে ETag ফেরত পাঠায়। এটি স্ট্যান্ডার্ড অনুরোধের জন্য বিলিং খরচ কমায়।

এছাড়াও, শর্তসাপেক্ষ অনুরোধের ক্ষেত্রে সাধারণ 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"}

ডেটা সরানো হচ্ছে

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

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

DELETE অনুরোধ সফল হলে, 200 OK HTTP স্ট্যাটাস কোড দেখানো হবে এবং উত্তরে JSON null থাকবে।

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'

টোকেন debug ফ্ল্যাগ সেট করা থাকলে, উত্তরের X-Firebase-Auth-Debug হেডারে ডিবাগিং ইনফরমেশন পাওয়া যাবে।

প্রিন্ট

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 epoch থেকে মিলিসেকেন্ডে সময়।

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

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

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

সমস্যা সংক্রান্ত শর্তাবলী

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

HTTP স্ট্যাটাস কোড
400 ত্রুটিযুক্ত অনুরোধ	নিম্নলিখিত সমস্যার মধ্যে কোনও একটি: `PUT` বা `POST` ডেটা পার্স করা যায়নি। `PUT` বা `POST` ডেটা নেই। অনুরোধটি `PUT` বা `POST` করার চেষ্টা করে এমন ডেটা যা খুব বড়। REST API কলে পাথের অংশ হিসেবে ভুল চাইল্ড নাম আছে। REST API কল পাথ অনেক বড়। অনুরোধে একটি অপরিচিত সার্ভার মান রয়েছে। আপনার Firebase Realtime Database Security Rules-এ কোয়েরির ইন্ডেক্স সংজ্ঞায়িত করা নেই। অনুরোধে উল্লেখ করা কোয়েরি প্যারামিটারগুলির মধ্যে একটি কাজ করে না। অনুরোধটি একটি অগভীর `GET` অনুরোধের সাথে কোয়েরি প্যারামিটারগুলিকে মিশ্রিত করে।
401 অননুমোদিত	নিম্নলিখিত সমস্যার মধ্যে কোনও একটি: auth টোকেনের মেয়াদ শেষ হয়ে গেছে। অনুরোধে ব্যবহৃত অথেন্টিকেশন টোকেনটি সঠিক নয়। access_token-এর মাধ্যমে যাচাই করা যায়নি। অনুরোধটি আপনার Firebase Realtime Database Security Rules লঙ্ঘন করে।
404 পাওয়া যায়নি	নির্দিষ্ট করা Firebase ডেটাবেস খুঁজে পাওয়া যায়নি।
500 ইন্টার্নাল সার্ভারে সমস্যা	সার্ভার থেকে একটি সমস্যা ফেরত পাঠানো হয়েছে। আরও বিবরণের জন্য ত্রুটি মেসেজ দেখুন।
503 পরিষেবা উপলভ্য নেই	নির্দিষ্ট Firebase রিয়েলটাইম ডেটাবেস সাময়িকভাবে উপলভ্য নেই, যার অর্থ হল অনুরোধের চেষ্টা করা হয়নি।

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

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

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