डेटा सेव करने के तरीके |
|
---|---|
रखें | डेटा को किसी तय पाथ में बदलें या लिखें, जैसे कि fireblog/users/user1/<data> |
पैच | पूरा डेटा बदले बिना, तय किए गए पाथ के लिए कुछ कुंजियां अपडेट करें. |
पोस्ट करें | हमारे Firebase डेटाबेस में डेटा की सूची में जोड़ें. जब भी हम POST का अनुरोध भेजते हैं, तो Firebase क्लाइंट एक यूनीक कुंजी जनरेट करता है, जैसे कि fireblog/users/<unique-id>/<data> |
मिटाएं | दिए गए 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, लेन-देन के बराबर होता है. उदाहरण के लिए, अगर आपको पक्ष में वोट करने का एक काउंटर बढ़ाना है और यह पक्का करना है कि हर बार अपवोट वाले जवाब की संख्या एक साथ कई बार सटीक रूप से दिखे, तो काउंटर में नई वैल्यू लिखने के लिए, शर्तों के साथ अनुरोध करें. काउंटर को बराबर संख्या में लिखने वाले दो रिक्वेस्ट के बजाय, एक राइट रिक्वेस्ट फ़ेल हो जाता है. इसके बाद, नई वैल्यू का इस्तेमाल करके फिर से अनुरोध किया जा सकता है.- किसी जगह पर शर्तें पूरी करने वाला अनुरोध करने के लिए, उस जगह के मौजूदा डेटा का यूनीक आइडेंटिफ़ायर
या 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
- लौटाए गए 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
- अगर आपको फिर से अनुरोध करना है, तो नई जानकारी का इस्तेमाल करें. रीयलटाइम डेटाबेस, शर्तें पूरी करने वाले उन अनुरोधों को अपने-आप नहीं भेजता है जो पूरे नहीं हो पाते हैं. हालांकि, नई वैल्यू और 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, इन स्थितियों में गड़बड़ी के कोड दिखाएगा:
एचटीटीपी स्टेटस कोड | |
---|---|
400 गलत अनुरोध |
गड़बड़ी की इन शर्तों में से कोई एक:
|
401 अनुमति नहीं है |
गड़बड़ी की इन शर्तों में से कोई एक:
|
404 दस्तावेज़ नहीं मिला | चुना गया Firebase डेटाबेस नहीं मिला. |
500 सर्वर में गड़बड़ी | सर्वर ने एक गड़बड़ी दिखाई. ज़्यादा जानकारी के लिए गड़बड़ी का मैसेज देखें. |
503 सेवा उपलब्ध नहीं है | चुना गया Firebase रीयल टाइम डेटाबेस, कुछ समय के लिए उपलब्ध नहीं है. इसका मतलब है कि अनुरोध नहीं किया गया. |
डेटा की सुरक्षा करना
Firebase में एक सुरक्षा भाषा है, जो हमें यह तय करने देती है कि किन उपयोगकर्ताओं के पास हमारे डेटा के अलग-अलग नोड को पढ़ने और उनमें बदलाव करने का ऐक्सेस है. इसके बारे में ज़्यादा जानने के लिए, रीयल टाइम डेटाबेस सुरक्षा के नियम देखें.
हमने डेटा सेव करने के बारे में बात कर ली है. अब हम अगले सेक्शन में, REST API के ज़रिए Firebase डेटाबेस से अपने डेटा को वापस पाने का तरीका सीख सकते हैं.