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

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

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

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

PUT का इस्तेमाल करके, हम किसी स्ट्रिंग, संख्या, बूलियन, अरे या किसी JSON ऑब्जेक्ट को हमारा Firebase डेटाबेस. इस मामले में हम इसे एक ऑब्जेक्ट पास करेंगे:

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 इसके बराबर है 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 चाइल्ड खातों को मिटाए बिना. ध्यान दें कि अगर हमारे इसके बजाय, name और birthday ने यहां PUT अनुरोध जारी किया उन्हें मिटा दिया जाएगा, क्योंकि उन्हें अनुरोध में शामिल नहीं किया गया था. 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 के अलावा अन्य तरीका. इस उदाहरण में, GET अनुरोध का इस्तेमाल किया गया है.

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

   विशेष रूप से हेडर में 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 की शुरुआती फ़ेच की गई वैल्यू से 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
   

   अगर जगह की जानकारी 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 पर आधारित कंडिशनल रिक्वेस्ट, एचटीटीपी को लागू करती हैं अगर मैच होता है मानक. हालांकि, वे इन मामलों में स्टैंडर्ड से अलग होते हैं:

• अगर मैच होने वाले हर अनुरोध के लिए, सिर्फ़ एक 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 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=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.