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

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

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

आइए, अपने Firebase डेटाबेस में उपयोगकर्ता का कुछ डेटा सेव करके शुरू करते हैं. हम हर उपयोगकर्ता को एक यूनीक उपयोगकर्ता नाम से सेव करेंगे. साथ ही, हम उनका पूरा नाम और जन्म की तारीख भी सेव करेंगे. हर उपयोगकर्ता का उपयोगकर्ता नाम यूनीक होगा. इसलिए, यहां PUT के बजाय POST का इस्तेमाल करना सही है, क्योंकि हमारे पास पहले से ही कुंजी है और हमें नई कुंजी बनाने की ज़रूरत नहीं है.

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

   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 मिलने चाहिए. हालांकि, रीयलटाइम डेटाबेस सिर्फ़ उन अनुरोधों के साथ 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 पाथ से ऐलन का डेटा मिट जाएगा:

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 ऐप्लिकेशन का सीक्रेट या ऑथेंटिकेशन टोकन इस्तेमाल किया जा सकता है. इसके बारे में हम उपयोगकर्ता के ऑथराइज़ेशन सेक्शन में बताएंगे. यहां दिए गए उदाहरण में, हम POST अनुरोध भेजते हैं. इसमें auth पैरामीटर, जहां CREDENTIAL हमारे Firebase ऐप्लिकेशन का सीक्रेट या ऑथेंटिकेशन टोकन है:

curl -X POST -d '{"Authenticated POST request"}' \
  'https://docs-examples.firebaseio.com/auth-example.json?auth=CREDENTIAL'

print

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" सर्वर की सिर्फ़ एक वैल्यू है. यह वैल्यू, Unix epoch के बाद से मिलीसेकंड में समय दिखाती है.

डेटा लिखने की परफ़ॉर्मेंस बेहतर बनाना

अगर हम डेटाबेस में ज़्यादा डेटा लिख रहे हैं, तो print=silent पैरामीटर का इस्तेमाल करके, डेटा लिखने की परफ़ॉर्मेंस बेहतर बनाई जा सकती है और बैंडविथ का इस्तेमाल कम किया जा सकता है. डेटा लिखने के सामान्य तरीके में, सर्वर उस JSON डेटा के साथ जवाब देता है जिसे लिखा गया था. print=silent तय करने पर, डेटा मिलने के बाद सर्वर तुरंत कनेक्शन बंद कर देता है. इससे बैंडविथ का इस्तेमाल कम हो जाता है.

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

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

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

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

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