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

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

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

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

REST API के माध्यम से मूल लेखन कार्य PUT है। डेटा को सहेजना प्रदर्शित करने के लिए, हम पोस्ट और उपयोगकर्ताओं के साथ एक ब्लॉगिंग एप्लिकेशन बनाएंगे। हमारे आवेदन के लिए सभी डेटा 'फ़ायरब्लॉग' के पथ के तहत, फ़ायरबेस डेटाबेस यूआरएल 'https://docs-examples.firebaseio.com/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 स्थिति कोड द्वारा दर्शाया जाएगा, और प्रतिक्रिया में डेटाबेस में लिखा गया अद्यतन डेटा होगा।

फायरबेस बहु-पथ अद्यतनों का भी समर्थन करता है। इसका मतलब यह है कि 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 में लौटाए गए ETag को शामिल करें या उस 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 if-match मानक को लागू करते हैं। हालाँकि, वे निम्नलिखित तरीकों से मानक से भिन्न होते हैं:

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

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 कॉल पथ बहुत लंबा है।
  • अनुरोध में एक अपरिचित सर्वर मान है।
  • क्वेरी के लिए अनुक्रमणिका आपके Firebase रीयलटाइम डेटाबेस नियमों में परिभाषित नहीं है।
  • अनुरोध निर्दिष्ट क्वेरी पैरामीटर में से एक का समर्थन नहीं करता है।
  • अनुरोध उथले GET अनुरोध के साथ क्वेरी पैरामीटर मिलाता है।
401 अनधिकृत

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

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

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

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

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