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

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"
    }
  }
}

शर्तें पूरी होने पर किए गए अनुरोधों के लिए डेटा अपडेट करना

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

   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
   

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

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

• अगर मैच होने वाले हर अनुरोध के लिए, सिर्फ़ एक 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 अनुरोध पैरामीटर की मदद से, Firebase रीयल टाइम डेटाबेस के सुरक्षा नियमों के तहत सुरक्षित किए गए डेटा को ऐक्सेस किया जा सकता है. यह डेटा हर तरह के अनुरोध के लिए इस्तेमाल किया जा सकता है. तर्क हमारा 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" इस्तेमाल किया जा सकने वाला सर्वर वैल्यू है. यह UNIX epoch के बाद से मिलीसेकंड में सेट किया गया समय है.

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

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

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

गड़बड़ी की शर्तें

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

डेटा की सुरक्षा करना

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