इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

डेटा बचाने के तरीके
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` के पाथ में सेव किया जाएगा.

आइए, 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'

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

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

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

if-match अनुरोध के लिए, सिर्फ़ एक ETag वैल्यू दी जा सकती है. एक से ज़्यादा वैल्यू नहीं दी जा सकतीं.
स्टैंडर्ड के मुताबिक, सभी अनुरोधों के साथ ETags वापस भेजे जाने चाहिए. हालांकि, Realtime Database सिर्फ़ उन अनुरोधों के साथ ETags वापस भेजता है जिनमें 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 अनुरोध भेज सकते हैं. इसमें उस पाथ का यूआरएल शामिल होता है जिससे हमें डेटा मिटाना है. नीचे दिए गए उदाहरण में, Alan को हमारे 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 ऐप्लिकेशन के सीक्रेट या पुष्टि करने वाले टोकन का इस्तेमाल किया जा सकता है. इसके बारे में हम उपयोगकर्ता की अनुमति वाले सेक्शन में बताएंगे. यहां दिए गए उदाहरण में, हमने 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", सर्वर से मिली वैल्यू है. यह UNIX epoch के बाद से मिलीसेकंड में बीता हुआ समय है.

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

अगर हमें डेटाबेस में बड़ी मात्रा में डेटा लिखना है, तो हम 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 डेटाबेस से डेटा वापस पाने का तरीका जानेंगे.

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

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

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

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

शर्त के साथ किए गए अनुरोधों के ज़रिए डेटा अपडेट करना

डेटा की सूचियां सेव करना

डेटा हटाना

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

auth

प्रिंट करें

सर्वर वैल्यू लिखना

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

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

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