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

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

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

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() के बराबर है.

PATCH का इस्तेमाल करके डेटा अपडेट करना

PATCH अनुरोध का इस्तेमाल करके, हम किसी जगह पर मौजूद बच्चों की जानकारी को अपडेट कर सकते हैं. ऐसा करने पर, मौजूदा डेटा को बदला नहीं जाएगा. आइए, PATCH अनुरोध की मदद से, टूरिंग के उपयोगकर्ता डेटा में उसका कोई दूसरा नाम जोड़ें:

curl -X PATCH -d '{
  "nickname": "Alan The Machine"
}' \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

ऊपर दिए गए अनुरोध से, हमारे alanisawesome ऑब्जेक्ट में nickname लिखा जाएगा. ऐसा करने पर, name या birthday बच्चों को मिटाया नहीं जाएगा. ध्यान दें कि अगर हमने यहां 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"
    }
  }
}

शर्तों के साथ अनुरोध करके डेटा अपडेट करना

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 पर अपडेट करने के लिए या फ़ेच की गई शुरुआती वैल्यू 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. अगर आपको अनुरोध फिर से सबमिट करना है, तो नई जानकारी का इस्तेमाल करें. 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'

प्रिंट करें

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 इन स्थितियों में गड़बड़ी के कोड दिखाएगा:

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

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