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

PUT के साथ डेटा लिखना

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

आइए कुछ उपयोगकर्ता डेटा को अपने फायरबेस डेटाबेस में सहेजकर प्रारंभ करें। हम प्रत्येक उपयोगकर्ता को एक अद्वितीय उपयोगकर्ता नाम से संग्रहीत करेंगे, और हम उनका पूरा नाम और जन्मतिथि भी संग्रहीत करेंगे। चूंकि प्रत्येक उपयोगकर्ता के पास एक अद्वितीय उपयोगकर्ता नाम होगा, इसलिए यहां POST के बजाय PUT उपयोग करना समझ में आता है क्योंकि हमारे पास पहले से ही कुंजी है और हमें एक बनाने की आवश्यकता नहीं है।

PUT उपयोग करके, हम अपने फायरबेस डेटाबेस में एक स्ट्रिंग, संख्या, बूलियन, सरणी या कोई 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'

उपरोक्त दो उदाहरण - एक ऑब्जेक्ट के रूप में एक ही समय में मान लिखना और उन्हें चाइल्ड स्थानों पर अलग से लिखना - परिणामस्वरूप वही डेटा हमारे फायरबेस डेटाबेस में सहेजा जाएगा:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing"
    }
  }
}

एक सफल अनुरोध को 200 OK HTTP स्टेटस कोड द्वारा दर्शाया जाएगा, और प्रतिक्रिया में वह डेटा शामिल होगा जो हमने डेटाबेस में लिखा था। पहला उदाहरण उन ग्राहकों पर केवल एक घटना को ट्रिगर करेगा जो डेटा देख रहे हैं, जबकि दूसरा उदाहरण दो को ट्रिगर करेगा। यह ध्यान रखना महत्वपूर्ण है कि यदि डेटा पहले से ही उपयोगकर्ता पथ पर मौजूद है, तो पहला दृष्टिकोण इसे अधिलेखित कर देगा, लेकिन दूसरी विधि केवल प्रत्येक अलग चाइल्ड नोड के मान को संशोधित करेगी जबकि अन्य चाइल्ड नोड को अपरिवर्तित छोड़ देगी। 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 हटा दिया गया होता क्योंकि वे अनुरोध में शामिल नहीं थे। हमारे फायरबेस डेटाबेस में डेटा अब इस तरह दिखता है:

{
  "users": {
    "alanisawesome": {
      "date_of_birth": "June 23, 1912",
      "full_name": "Alan Turing",
      "nickname": "Alan The Machine"
    }
  }
}

एक सफल अनुरोध को 200 OK HTTP स्थिति कोड द्वारा इंगित किया जाएगा, और प्रतिक्रिया में डेटाबेस में लिखा गया अद्यतन डेटा शामिल होगा।

फायरबेस मल्टी-पाथ अपडेट का भी समर्थन करता है। इसका मतलब यह है कि PATCH अब एक ही समय में आपके फायरबेस डेटाबेस में कई स्थानों पर मूल्यों को अपडेट कर सकता है, एक शक्तिशाली सुविधा जो आपको अपने डेटा को असामान्य बनाने में मदद करती है। मल्टी-पाथ अपडेट का उपयोग करके, हम एक ही समय में एलन और ग्रेस दोनों में उपनाम जोड़ सकते हैं:

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. किसी स्थान पर सशर्त अनुरोध करने के लिए, उस स्थान पर वर्तमान डेटा के लिए विशिष्ट पहचानकर्ता, या ईटैग प्राप्त करें। यदि उस स्थान पर डेटा बदलता है, तो ईटैग भी बदल जाता है। आप PATCH के अलावा किसी अन्य विधि से ETag का अनुरोध कर सकते हैं। निम्नलिखित उदाहरण GET अनुरोध का उपयोग करता है।

   curl -i 'https://test.example.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
   

   हेडर में ईटैग को विशेष रूप से कॉल करने से HTTP प्रतिक्रिया में निर्दिष्ट स्थान का ईटैग वापस आ जाता है।

   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. उस डेटा को अपडेट करने के लिए अपने अगले PUT या DELETE अनुरोध में लौटाए गए ETag को शामिल करें जो विशेष रूप से उस 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
   

   यदि स्थान अब ईटैग से मेल नहीं खाता है, जो तब हो सकता है जब कोई अन्य उपयोगकर्ता डेटाबेस में एक नया मान लिखता है, तो स्थान पर लिखे बिना अनुरोध विफल हो जाता है। वापसी प्रतिक्रिया में नया मान और ईटैग शामिल है।

   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-आधारित सशर्त अनुरोध HTTP if-match मानक को लागू करते हैं। हालाँकि, वे निम्नलिखित तरीकों से मानक से भिन्न हैं:

• आप प्रत्येक इफ-मैच अनुरोध के लिए केवल एक ईटैग मान प्रदान कर सकते हैं, एकाधिक नहीं।
• जबकि मानक सुझाव देता है कि ETags को सभी अनुरोधों के साथ लौटाया जाना चाहिए, रीयलटाइम डेटाबेस केवल X-Firebase-ETag हेडर सहित अनुरोधों के साथ ETags लौटाता है। इससे मानक अनुरोधों के लिए बिलिंग लागत कम हो जाती है।

सशर्त अनुरोध सामान्य REST अनुरोधों की तुलना में धीमे भी हो सकते हैं।

डेटा की सूची सहेजना

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

{"name":"-JSOpn9ZC54A4P4RoqVa"}

डेटा हटाना

डेटाबेस से डेटा हटाने के लिए, हम उस पथ के URL के साथ एक DELETE अनुरोध भेज सकते हैं जिससे हम डेटा हटाना चाहते हैं। निम्नलिखित एलन को हमारे users पथ से हटा देगा:

curl -X DELETE \
  'https://docs-examples.firebaseio.com/fireblog/users/alanisawesome.json'

एक सफल DELETE अनुरोध को JSON null युक्त प्रतिक्रिया के साथ 200 OK HTTP स्थिति कोड द्वारा दर्शाया जाएगा।

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

डेटाबेस में डेटा लिखते समय REST API निम्नलिखित URI पैरामीटर स्वीकार करता है:

प्रमाणन

auth अनुरोध पैरामीटर फ़ायरबेस रीयलटाइम डेटाबेस सुरक्षा नियमों द्वारा संरक्षित डेटा तक पहुंच की अनुमति देता है, और सभी अनुरोध प्रकारों द्वारा समर्थित है। तर्क या तो हमारा फायरबेस ऐप सीक्रेट या प्रमाणीकरण टोकन हो सकता है, जिसे हम उपयोगकर्ता प्राधिकरण अनुभाग में शामिल करेंगे। निम्नलिखित उदाहरण में हम एक auth पैरामीटर के साथ एक POST अनुरोध भेजते हैं, जहां CREDENTIAL या तो हमारा फायरबेस ऐप रहस्य है या प्रमाणीकरण टोकन है:

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 HTTP स्थिति कोड द्वारा इंगित की जाएगी। print=silent GET , PUT , POST और PATCH अनुरोधों द्वारा समर्थित है।

सर्वर मान लिखना

सर्वर मान को प्लेसहोल्डर मान का उपयोग करके किसी स्थान पर लिखा जा सकता है, जो एकल ".sv" कुंजी वाला एक ऑब्जेक्ट है। उस कुंजी का मान सर्वर मान का प्रकार है जिसे हम सेट करना चाहते हैं। उदाहरण के लिए, जब कोई उपयोगकर्ता बनाया जाता है तो टाइमस्टैम्प सेट करने के लिए हम निम्नलिखित कार्य कर सकते हैं:

curl -X PUT -d '{".sv": "timestamp"}' \
  'https://docs-examples.firebaseio.com/alanisawesome/createdAt.json'

"timestamp" एकमात्र समर्थित सर्वर मान है, और मिलीसेकंड में UNIX युग के बाद का समय है।

लेखन प्रदर्शन में सुधार

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

ऐसे मामलों में जहां हम डेटाबेस के लिए कई अनुरोध कर रहे हैं, हम HTTP हेडर में Keep-Alive अनुरोध भेजकर HTTPS कनेक्शन का पुन: उपयोग कर सकते हैं।

त्रुटि स्थितियाँ

REST API इन परिस्थितियों में त्रुटि कोड लौटाएगा:

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

फायरबेस में एक सुरक्षा भाषा है जो हमें यह परिभाषित करने देती है कि किन उपयोगकर्ताओं के पास हमारे डेटा के विभिन्न नोड्स तक पढ़ने और लिखने की पहुंच है। आप इसके बारे में रीयलटाइम डेटाबेस सुरक्षा नियमों में अधिक पढ़ सकते हैं।