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

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

ध्यान दें कि सभी उदाहरणों में रीड-ओनली Firebase Realtime Database, docs-example.firebaseio.com का इस्तेमाल किया गया है. इस Realtime Database यूआरएल को, Firebase कंसोल के उस यूआरएल से बदलें जिसका ऐक्सेस आपके पास है.

PUT का इस्तेमाल करके डेटा लिखना

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

अगर हम किसी ऐसे ब्राउज़र से REST कॉल कर रहे हैं जो ऊपर दिए गए कुछ तरीकों के साथ काम नहीं करता, तो Firebase, X-HTTP-Method-Override हेडर के साथ काम करता है.

आइए, अपने 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 ऑब्जेक्ट डेटाबेस में सेव किया जाता है, तो ऑब्जेक्ट प्रॉपर्टी अपने-आप नेस्ट किए गए तरीके से चाइल्ड लोकेशन पर मैप हो जाती हैं. अगर हम नए बनाए गए नोड पर नेविगेट करते हैं, तो हमें "एलन ट्यूरिंग" वैल्यू दिखेगी. हम डेटा को सीधे बच्चे की जगह की जानकारी में भी सेव कर सकते हैं:

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 एचटीटीपी स्टेटस कोड दिखेगा. साथ ही, रिस्पॉन्स में वह डेटा दिखेगा जिसे हमने डेटाबेस में डाला है. पहला उदाहरण, डेटा को देखने वाले क्लाइंट पर सिर्फ़ एक इवेंट को ट्रिगर करेगा, जबकि दूसरा उदाहरण दो इवेंट को ट्रिगर करेगा. इस बात का ध्यान रखना ज़रूरी है कि अगर उपयोगकर्ता पाथ में पहले से ही डेटा मौजूद है, तो पहला तरीका उसे ओवरराइट कर देगा. हालांकि, दूसरा तरीका सिर्फ़ हर अलग चाइल्ड नोड की वैल्यू में बदलाव करेगा, जबकि दूसरे चाइल्ड नोड में कोई बदलाव नहीं करेंगे. PUT, हमारे JavaScript SDK में set() के बराबर है.

PUT का इस्तेमाल करने पर, तय की गई जगह पर मौजूद डेटा को बदल दिया जाएगा. इसमें, चाइल्ड नोड भी शामिल हैं.

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 एचटीटीपी स्टेटस कोड के तौर पर दिखाया जाएगा. साथ ही, रिस्पॉन्स के तौर पर डेटाबेस में लिखा गया अपडेट किया गया डेटा भी शामिल होगा.

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 को कॉल करने से, एचटीटीपी रिस्पॉन्स में बताई गई जगह का 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. उस ETag वैल्यू से मैच करने वाले डेटा को अपडेट करने के लिए, अपने अगले PUT या DELETE अनुरोध में, दिखाया गया ETag शामिल करें. हमारे उदाहरण के मुताबिक, काउंटर को 11 या 1 को, शुरुआती फ़ेच की गई वैल्यू 10 से ज़्यादा पर अपडेट करने और वैल्यू के मेल न खाने पर अनुरोध को पूरा न करने के लिए, इस कोड का इस्तेमाल करें:

   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. अगर आपको अनुरोध फिर से सबमिट करना है, तो नई जानकारी का इस्तेमाल करें. Realtime Database उन शर्तों के साथ किए गए अनुरोधों को अपने-आप नहीं करता है जो पूरे नहीं हो पाते हैं. हालांकि, नई वैल्यू और ETag का इस्तेमाल करके, कुछ शर्तों के साथ नया अनुरोध बनाया जा सकता है. इसके लिए, अनुरोध पूरा न होने पर मिली जानकारी का इस्तेमाल किया जाता है.

REST-आधारित शर्तों वाले अनुरोध, एचटीटीपी if-match स्टैंडर्ड को लागू करते हैं. हालांकि, ये स्टैंडर्ड से इन तरीकों से अलग होते हैं:

• हर if-match अनुरोध के लिए, सिर्फ़ एक ETag वैल्यू दी जा सकती है, एक से ज़्यादा नहीं.
• स्टैंडर्ड के मुताबिक, सभी अनुरोधों के साथ ETag दिखाए जाने चाहिए. हालांकि, Realtime Database सिर्फ़ उन अनुरोधों के साथ ETag दिखाता है जिनमें X-Firebase-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 एचटीटीपी स्टेटस कोड दिखेगा. साथ ही, जवाब में जोड़े गए नए डेटा की कुंजी दिखेगी:

{"name":"-JSOpn9ZC54A4P4RoqVa"}

क्या आपको पुश कुंजियों के जनरेट होने के तरीके के बारे में ज़्यादा जानना है? यह ब्लॉग पोस्ट पढ़ें.

डेटा हटाना

डेटाबेस से डेटा हटाने के लिए, हम उस पाथ के यूआरएल के साथ DELETE अनुरोध भेज सकते हैं जहां से हमें डेटा मिटाना है. इन निर्देशों से, हमारे users पाथ से Alan को मिटा दिया जाएगा:

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

DELETE अनुरोध पूरा होने पर, 200 OK एचटीटीपी स्टेटस कोड के साथ JSON null वाला रिस्पॉन्स दिखेगा.

यूआरआई पैरामीटर

डेटाबेस में डेटा लिखते समय, REST API इन यूआरआई पैरामीटर को स्वीकार करता है:

auth

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 एचटीटीपी स्टेटस कोड से दिखाया जाएगा. 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 तय करने पर, डेटा मिलने के बाद सर्वर तुरंत कनेक्शन बंद कर देता है. इससे बैंडविड्थ का इस्तेमाल कम हो जाता है.

जिन मामलों में हम डेटाबेस से कई अनुरोध कर रहे हैं उनमें एचटीटीपीएस कनेक्शन का फिर से इस्तेमाल किया जा सकता है. इसके लिए, एचटीटीपी हेडर में Keep-Alive अनुरोध भेजना होगा.

गड़बड़ी की स्थितियां

REST API, इन स्थितियों में गड़बड़ी के कोड दिखाएगा:

एचटीटीपी स्टेटस कोड
400 गलत अनुरोध	गड़बड़ी की इनमें से कोई एक स्थिति: PUT या POST डेटा को पार्स नहीं किया जा सका. PUT या POST का डेटा मौजूद नहीं है. अनुरोध में बहुत ज़्यादा डेटा के लिए PUT या POST का इस्तेमाल किया गया है. REST API कॉल में, पाथ के हिस्से के तौर पर अमान्य चाइल्ड नेम शामिल हैं. REST API कॉल पाथ बहुत लंबा है. अनुरोध में, सर्वर की ऐसी वैल्यू शामिल है जिसे पहचाना नहीं जा सका. आपके Firebase Realtime Database Security Rules में, क्वेरी के लिए इंडेक्स तय नहीं किया गया है. अनुरोध में, बताए गए क्वेरी पैरामीटर में से किसी एक के साथ काम नहीं करता. अनुरोध, क्वेरी पैरामीटर को शैलो GET अनुरोध के साथ मिला देता है.
401 अनुमति नहीं है	गड़बड़ी की इनमें से कोई एक स्थिति: पुष्टि करने वाले टोकन की समयसीमा खत्म हो गई है. अनुरोध में इस्तेमाल किया गया पुष्टि करने वाला टोकन अमान्य है. access_token की मदद से पुष्टि नहीं हो सकी. अनुरोध, आपके Firebase Realtime Database Security Rules का उल्लंघन करता है.
404 पेज नहीं मिला	बताया गया Firebase डेटाबेस नहीं मिला.
500 सर्वर में गड़बड़ी	सर्वर से गड़बड़ी का मैसेज मिला. ज़्यादा जानकारी के लिए, गड़बड़ी का मैसेज देखें.
503 सेवा उपलब्ध नहीं है	आपने जिस Firebase रीयलटाइम डेटाबेस का इस्तेमाल करने के लिए अनुरोध किया है वह फ़िलहाल उपलब्ध नहीं है. इसका मतलब है कि आपके अनुरोध को प्रोसेस नहीं किया गया.

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

Firebase में एक सुरक्षा भाषा होती है. इसकी मदद से, हम यह तय कर सकते हैं कि किन उपयोगकर्ताओं के पास हमारे डेटा के अलग-अलग नोड को पढ़ने और उनमें बदलाव करने का ऐक्सेस है. इस बारे में ज़्यादा जानने के लिए, Realtime Database Security Rules पढ़ें.

हमने डेटा सेव करने के बारे में बात कर ली है. अब हम अगले सेक्शन में, REST API के ज़रिए Firebase डेटाबेस से अपने डेटा को वापस पाने का तरीका सीख सकते हैं.