इस पेज का अनुवाद 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'

ऊपर दिए गए अनुरोध से, हमारे 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"
    }
  }
}

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

डेटा को उसकी मौजूदा स्थिति के हिसाब से अपडेट करने के लिए, कंडीशनल रिक्वेस्ट का इस्तेमाल किया जा सकता है. यह लेन-देन के बराबर का REST है. उदाहरण के लिए, अगर आपको किसी कॉन्टेंट को पसंद करने की संख्या बढ़ानी है और यह पक्का करना है कि एक साथ कई लोगों ने उसे पसंद किया है, तो कॉन्टेंट को पसंद करने की संख्या बढ़ाने के लिए, शर्त के साथ अनुरोध का इस्तेमाल करें. काउंटर को एक ही नंबर पर बदलने वाले दो लिखने के बजाय, लिखने का एक अनुरोध पूरा नहीं होता. इसके बाद, नई वैल्यू के साथ अनुरोध को फिर से आज़माया जा सकता है.

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

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

डेटा सेव करने के तरीके

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

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

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

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

डेटा हटाना

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

auth

प्रिंट करें

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

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

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

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