डेटा सहेजा जा रहा है

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

डेटा बचाने के तरीके

रखना डेटा को परिभाषित पथ पर लिखें या बदलें, जैसे fireblog/users/user1/<data>
पैबंद सभी डेटा को बदले बिना परिभाषित पथ के लिए कुछ कुंजियों को अपडेट करें।
पद हमारे फायरबेस डेटाबेस में डेटा की सूची में जोड़ें । हर बार जब हम एक POST अनुरोध भेजते हैं, फायरबेस क्लाइंट एक अनूठी कुंजी उत्पन्न करता है, जैसे fireblog/users/<unique-id>/<data>
मिटाना निर्दिष्ट Firebase डेटाबेस संदर्भ से डेटा निकालें।

PUT के साथ डेटा लिखना

REST API के माध्यम से मूल लेखन कार्य PUT है। बचत डेटा प्रदर्शित करने के लिए, हम पोस्ट और उपयोगकर्ताओं के साथ एक ब्लॉगिंग एप्लिकेशन बनाएंगे। हमारे एप्लिकेशन के सभी डेटा को फायरबेस डेटाबेस यूआरएल `https://docs-examples.firebaseio.com/fireblog` पर `फायरब्लॉग` के पथ के तहत संग्रहीत किया जाएगा।

आइए कुछ उपयोगकर्ता डेटा को अपने Firebase डेटाबेस में सहेज कर प्रारंभ करें। हम प्रत्येक उपयोगकर्ता को एक विशिष्ट उपयोगकर्ता नाम द्वारा संग्रहीत करेंगे, और हम उनका पूरा नाम और जन्म तिथि भी संग्रहीत करेंगे। चूंकि प्रत्येक उपयोगकर्ता के पास एक अद्वितीय उपयोगकर्ता नाम होगा, इसलिए 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 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 को हटा दिया गया होता क्योंकि वे अनुरोध में शामिल नहीं थे। हमारे फायरबेस डेटाबेस में डेटा अब इस तरह दिखता है:

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

एक सफल अनुरोध को 200 OK HTTP स्थिति कोड द्वारा इंगित किया जाएगा, और प्रतिक्रिया में डेटाबेस में लिखे गए अद्यतन डेटा शामिल होंगे।

फायरबेस बहु-पथ अपडेट का भी समर्थन करता है। इसका मतलब यह है कि 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 के अलावा किसी अन्य विधि से 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 मान से मेल खाता हो। हमारे उदाहरण के बाद, काउंटर को 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
    14 यदि स्थान अब 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. यदि आप अनुरोध का पुनः प्रयास करने का निर्णय लेते हैं तो नई जानकारी का उपयोग करें। रीयलटाइम डेटाबेस स्वचालित रूप से असफल सशर्त अनुरोधों का पुनः प्रयास नहीं करता है। हालांकि, आप असफल प्रतिक्रिया द्वारा लौटाई गई जानकारी के साथ एक नया सशर्त अनुरोध बनाने के लिए नए मूल्य और ईटाग का उपयोग कर सकते हैं।

REST- आधारित सशर्त अनुरोध HTTP if-match मानक को लागू करते हैं। हालाँकि, वे निम्नलिखित तरीकों से मानक से भिन्न हैं:

  • आप प्रत्येक इफ-मैच अनुरोध के लिए केवल एक 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 अनुरोध पैरामीटर फायरबेस रीयलटाइम डेटाबेस नियमों द्वारा संरक्षित डेटा तक पहुंच की अनुमति देता है, और सभी अनुरोध प्रकारों द्वारा समर्थित है। तर्क या तो हमारा फायरबेस ऐप रहस्य या प्रमाणीकरण टोकन हो सकता है, जिसे हम उपयोगकर्ता प्राधिकरण अनुभाग में शामिल करेंगे। निम्नलिखित उदाहरण में हम एक 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 स्थिति कोड
400 खराब अनुरोध

निम्न त्रुटि स्थितियों में से एक:

  • PUT या POST डेटा पार्स करने में असमर्थ।
  • PUT या POST डेटा गुम है।
  • अनुरोध बहुत बड़े डेटा को PUT या POST करने का प्रयास करता है।
  • पथ के भाग के रूप में REST API कॉल में अमान्य चाइल्ड नाम हैं।
  • REST API कॉल पथ बहुत लंबा है।
  • अनुरोध में एक अपरिचित सर्वर मान है।
  • क्वेरी के लिए अनुक्रमणिका को आपके फायरबेस रीयलटाइम डेटाबेस नियम में परिभाषित नहीं किया गया है।
  • अनुरोध निर्दिष्ट क्वेरी पैरामीटर में से एक का समर्थन नहीं करता है।
  • अनुरोध क्वेरी पैरामीटर को उथले GET अनुरोध के साथ मिलाता है।
401 अनधिकृत

निम्न त्रुटि स्थितियों में से एक:

404 नहीं मिला निर्दिष्ट फायरबेस डेटाबेस नहीं मिला।
500 आंतरिक सर्वर त्रुटि सर्वर ने एक त्रुटि लौटाई। अधिक जानकारी के लिए त्रुटि संदेश देखें।
503 सेवा अनुपलब्ध निर्दिष्ट फायरबेस रीयलटाइम डेटाबेस अस्थायी रूप से अनुपलब्ध है, जिसका अर्थ है कि अनुरोध का प्रयास नहीं किया गया था।

डेटा सुरक्षित करना

फायरबेस के पास एक सुरक्षा भाषा है जो हमें यह परिभाषित करने देती है कि किन उपयोगकर्ताओं ने हमारे डेटा के विभिन्न नोड्स को पढ़ा और लिखा है। आप इसके बारे में रीयलटाइम डेटाबेस नियम में अधिक पढ़ सकते हैं।

अब जब हमने डेटा सहेजना कवर कर लिया है, तो हम अगले अनुभाग में REST API के माध्यम से Firebase डेटाबेस से अपना डेटा पुनर्प्राप्त करना सीख सकते हैं।

,

डेटा बचाने के तरीके

रखना डेटा को परिभाषित पथ पर लिखें या बदलें, जैसे fireblog/users/user1/<data>
पैबंद सभी डेटा को बदले बिना परिभाषित पथ के लिए कुछ कुंजियों को अपडेट करें।
पद हमारे फायरबेस डेटाबेस में डेटा की सूची में जोड़ें । हर बार जब हम एक POST अनुरोध भेजते हैं, फायरबेस क्लाइंट एक अनूठी कुंजी उत्पन्न करता है, जैसे fireblog/users/<unique-id>/<data>
मिटाना निर्दिष्ट Firebase डेटाबेस संदर्भ से डेटा निकालें।

PUT के साथ डेटा लिखना

REST API के माध्यम से मूल लेखन कार्य PUT है। बचत डेटा प्रदर्शित करने के लिए, हम पोस्ट और उपयोगकर्ताओं के साथ एक ब्लॉगिंग एप्लिकेशन बनाएंगे। हमारे एप्लिकेशन के सभी डेटा को फायरबेस डेटाबेस यूआरएल `https://docs-examples.firebaseio.com/fireblog` पर `फायरब्लॉग` के पथ के तहत संग्रहीत किया जाएगा।

आइए कुछ उपयोगकर्ता डेटा को अपने Firebase डेटाबेस में सहेज कर प्रारंभ करें। हम प्रत्येक उपयोगकर्ता को एक विशिष्ट उपयोगकर्ता नाम द्वारा संग्रहीत करेंगे, और हम उनका पूरा नाम और जन्म तिथि भी संग्रहीत करेंगे। चूंकि प्रत्येक उपयोगकर्ता के पास एक अद्वितीय उपयोगकर्ता नाम होगा, इसलिए 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 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 को हटा दिया गया होता क्योंकि वे अनुरोध में शामिल नहीं थे। हमारे फायरबेस डेटाबेस में डेटा अब इस तरह दिखता है:

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

एक सफल अनुरोध को 200 OK HTTP स्थिति कोड द्वारा इंगित किया जाएगा, और प्रतिक्रिया में डेटाबेस में लिखे गए अद्यतन डेटा शामिल होंगे।

फायरबेस बहु-पथ अपडेट का भी समर्थन करता है। इसका मतलब यह है कि 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 के अलावा किसी अन्य विधि से 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 मान से मेल खाता हो। हमारे उदाहरण के बाद, काउंटर को 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
    14 यदि स्थान अब 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. यदि आप अनुरोध का पुनः प्रयास करने का निर्णय लेते हैं तो नई जानकारी का उपयोग करें। रीयलटाइम डेटाबेस स्वचालित रूप से असफल सशर्त अनुरोधों का पुनः प्रयास नहीं करता है। हालांकि, आप असफल प्रतिक्रिया द्वारा लौटाई गई जानकारी के साथ एक नया सशर्त अनुरोध बनाने के लिए नए मूल्य और ईटाग का उपयोग कर सकते हैं।

REST- आधारित सशर्त अनुरोध HTTP if-match मानक को लागू करते हैं। हालाँकि, वे निम्नलिखित तरीकों से मानक से भिन्न हैं:

  • आप प्रत्येक इफ-मैच अनुरोध के लिए केवल एक 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 अनुरोध पैरामीटर फायरबेस रीयलटाइम डेटाबेस नियमों द्वारा संरक्षित डेटा तक पहुंच की अनुमति देता है, और सभी अनुरोध प्रकारों द्वारा समर्थित है। तर्क या तो हमारा फायरबेस ऐप रहस्य या प्रमाणीकरण टोकन हो सकता है, जिसे हम उपयोगकर्ता प्राधिकरण अनुभाग में शामिल करेंगे। निम्नलिखित उदाहरण में हम एक 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 स्थिति कोड
400 खराब अनुरोध

निम्न त्रुटि स्थितियों में से एक:

  • PUT या POST डेटा पार्स करने में असमर्थ।
  • PUT या POST डेटा गुम है।
  • अनुरोध बहुत बड़े डेटा को PUT या POST करने का प्रयास करता है।
  • पथ के भाग के रूप में REST API कॉल में अमान्य चाइल्ड नाम हैं।
  • REST API कॉल पथ बहुत लंबा है।
  • अनुरोध में एक अपरिचित सर्वर मान है।
  • क्वेरी के लिए अनुक्रमणिका को आपके फायरबेस रीयलटाइम डेटाबेस नियम में परिभाषित नहीं किया गया है।
  • अनुरोध निर्दिष्ट क्वेरी पैरामीटर में से एक का समर्थन नहीं करता है।
  • अनुरोध क्वेरी पैरामीटर को उथले GET अनुरोध के साथ मिलाता है।
401 अनधिकृत

निम्न त्रुटि स्थितियों में से एक:

404 नहीं मिला निर्दिष्ट फायरबेस डेटाबेस नहीं मिला।
500 आंतरिक सर्वर त्रुटि सर्वर ने एक त्रुटि लौटाई। अधिक जानकारी के लिए त्रुटि संदेश देखें।
503 सेवा अनुपलब्ध निर्दिष्ट फायरबेस रीयलटाइम डेटाबेस अस्थायी रूप से अनुपलब्ध है, जिसका अर्थ है कि अनुरोध का प्रयास नहीं किया गया था।

डेटा सुरक्षित करना

फायरबेस के पास एक सुरक्षा भाषा है जो हमें यह परिभाषित करने देती है कि किन उपयोगकर्ताओं ने हमारे डेटा के विभिन्न नोड्स को पढ़ा और लिखा है। आप इसके बारे में रीयलटाइम डेटाबेस नियम में अधिक पढ़ सकते हैं।

अब जब हमने डेटा सहेजना कवर कर लिया है, तो हम अगले अनुभाग में REST API के माध्यम से Firebase डेटाबेस से अपना डेटा पुनर्प्राप्त करना सीख सकते हैं।