एपीआई का इस्तेमाल
REST एंडपॉइंट के तौर पर, किसी भी Firebase रीयल टाइम डेटाबेस के यूआरएल का इस्तेमाल किया जा सकता है. आपको बस यही ज़रूरत है
यूआरएल के आखिर में .json
जोड़ें और एक अनुरोध भेजें
अपने पसंदीदा एचटीटीपीएस क्लाइंट से ईमेल पाने का तरीका जानें.
एचटीटीपीएस ज़रूरी है. आपका डेटा सुरक्षित रखने के लिए, Firebase सिर्फ़ एन्क्रिप्ट (सुरक्षित) किए गए ट्रैफ़िक का जवाब देता है.
GET - रीडिंग डेटा
आपके Realtime Database का डेटा, एचटीटीपी जारी करके पढ़ा जा सकता है
एंडपॉइंट को भेजने के लिए GET
अनुरोध. यह उदाहरण
से पता चलता है कि किसी उपयोगकर्ता की
वह नाम जिसे आपने पहले Realtime Database में सेव किया था.
curl 'https://[PROJECT_ID].firebaseio.com/users/jack/name.json'
अनुरोध स्वीकार किए जाने का मतलब 200 OK
एचटीटीपी है
स्टेटस कोड डालें. जवाब में
GET
अनुरोध में पाथ.
{ "first": "Jack", "last": "Sparrow" }
PUT - डेटा लिखना
PUT
का अनुरोध करके, डेटा सेव किया जा सकता है.
curl -X PUT -d '{ "first": "Jack", "last": "Sparrow" }' \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name.json'
अनुरोध स्वीकार किए जाने का मतलब 200 OK
एचटीटीपी है
स्टेटस कोड डालें. रिस्पॉन्स में वह डेटा शामिल होता है जिसे
PUT
अनुरोध.
{ "first": "Jack", "last": "Sparrow" }
POST - डेटा भेजना
JavaScript push()
के बराबर काम करने के लिए
तरीका (डेटा की सूचियां देखें),
आपके पास POST
का अनुरोध करने का विकल्प है.
curl -X POST -d '{"user_id" : "jack", "text" : "Ahoy!"}' \ 'https://[PROJECT_ID].firebaseio.com/message_list.json'
अनुरोध स्वीकार किए जाने का मतलब है कि 200 OK
एचटीटीपी स्टेटस है
कोड. जवाब में नए डेटा का चाइल्ड नाम शामिल होता है
POST
अनुरोध में बताया गया है.
{ "name": "-INOQPH-aV_psbk3ZXEX" }
PATCH - डेटा अपडेट करना
किसी जगह की जानकारी को ओवरराइट किए बिना, खास बच्चों की जानकारी को अपडेट किया जा सकता है
मौजूदा डेटा को ऐक्सेस करने के लिए, PATCH
अनुरोध का इस्तेमाल करें. इसमें नाम वाले बच्चों के नाम हैं
PATCH
के साथ लिखे जा रहे डेटा को ओवरराइट किया गया है, लेकिन इसे छोड़ा गया है
चाइल्ड नहीं मिटाए जाते हैं. यह JavaScript के समान है
update()
फ़ंक्शन का इस्तेमाल करना होगा.
curl -X PATCH -d '{"last":"Jones"}' \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name/.json'
अनुरोध स्वीकार किए जाने का मतलब है कि 200 OK
एचटीटीपी स्टेटस है
कोड. रिस्पॉन्स में वह डेटा शामिल होता है जिसे
PATCH
अनुरोध.
{ "last": "Jones" }
मिटाएं - डेटा हटाया जा रहा है
DELETE
का अनुरोध करके, डेटा मिटाया जा सकता है:
curl -X DELETE \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name/last.json'
DELETE
के सफल अनुरोध का मतलब है
JSON फ़ॉर्मैट के जवाब के साथ 200 OK
एचटीटीपी स्टेटस कोड
null
.
तरीका बदलना
अगर किसी ऐसे ब्राउज़र से REST कॉल किया जाता है जो
में नहीं, बल्कि अनुरोध के तरीके को बदलने के लिए,
POST
का अनुरोध किया जा सकता है और इसका इस्तेमाल करके अपना तरीका सेट किया जा सकता है
X-HTTP-Method-Override
अनुरोध का हेडर.
curl -X POST -H "X-HTTP-Method-Override: DELETE" \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name/last.json'
x-http-method-override
क्वेरी पैरामीटर का इस्तेमाल भी किया जा सकता है.
curl -X POST \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name/last.json?x-http-method-override=DELETE'
शर्तें पूरी होने पर किए गए अनुरोध
शर्तों के हिसाब से किए गए अनुरोध, SDK टूल के ट्रांज़ैक्शन की कार्रवाई के बराबर की REST सेटिंग, किसी खास स्थिति में. वर्कफ़्लो की खास जानकारी देखें और शर्तों वाले अनुरोधों के बारे में ज़्यादा जानें डेटा सेव करना में REST के लिए.
Firebase ईटैग
Firebase ETag, किसी बताई गई जगह पर मौजूदा डेटा के लिए यूनीक आइडेंटिफ़ायर होता है. अगर
उस जगह पर डेटा में बदलाव होता है, तो ईटैग भी बदलता है. Firebase ETag को
शुरुआती REST अनुरोध के लिए हेडर (आम तौर पर
GET
, लेकिन PATCH
के अलावा कुछ भी हो सकता है).
curl -i 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'X-Firebase-ETag: true'
अगर मिलता-जुलता है
if-match
शर्त उस डेटा के लिए ETag वैल्यू तय करती है जिसे आपको अपडेट करना है.
अगर इस शर्त का इस्तेमाल किया जाता है, तो Realtime Database सिर्फ़ उन अनुरोधों को पूरा करता है जिनमें ETag बताया गया है
लिखने का अनुरोध, डेटाबेस में मौजूदा डेटा के ETag से मैच होता है. फ़ेच करें
Firebase ETag अनुरोध के साथ किसी जगह पर ETag. अगर आप कोई ऐसा स्थान ओवरराइट करना चाहते हैं
शून्य, null_etag
का इस्तेमाल करें.
curl -iX PUT -d '11' 'https://[PROJECT_ID].firebaseio.com/posts/12345/upvotes.json' -H 'if-match: [ETAG_VALUE]'
अपेक्षित जवाब
यहां दी गई टेबल में, हर तरह के अनुरोध के लिए अनुमानित जवाबों की खास जानकारी दी गई है, जो ETag मैच के आधार पर जनरेट किए जा सकते हैं.
अनुरोध प्रकार | ‘X-Firebase-ETag: सही' | ETag, if_match: <matching etag> से मेल खाता है |
ईटैग if_match: <no matching etag> से मेल नहीं खाता |
|
---|---|---|---|---|
पाएं | जवाब की स्थिति/कॉन्टेंट | 200: "<data_at_path>" | 400: "...काम नहीं करता.." | 400: "...काम नहीं करता.." |
हेडर जोड़े गए | ETag: <ETag_of_data> | लागू नहीं | लागू नहीं | |
पुट मोड | जवाब की स्थिति/कॉन्टेंट | 200: "<put_data>" | 200: "<put_data>" | 412: "...ईटैग मेल नहीं खाता.." |
हेडर जोड़े गए | ईटैग: <ETag_of_put_data> | लागू नहीं | ETag: <database_ETag> | |
पोस्ट करें | जवाब की स्थिति/कॉन्टेंट | 200: "<post_data>" | 400: "...काम नहीं करता.." | 400: "...काम नहीं करता.." |
हेडर जोड़े गए | ETag: <ETag_of_post_data> | लागू नहीं | लागू नहीं | |
पैच | जवाब की स्थिति/कॉन्टेंट | 400: "...काम नहीं करता.." | 400: "...काम नहीं करता.." | 400: "...काम नहीं करता.." |
हेडर जोड़े गए | लागू नहीं | लागू नहीं | लागू नहीं | |
मिटाएं | जवाब की स्थिति/कॉन्टेंट | 200: शून्य | 200: "<data_ बाद_put>" | 412: "...ईटैग मेल नहीं खाता.." |
हेडर जोड़े गए | ETag: <ETag_of_null> | लागू नहीं | ETag: <database_ETag> |
क्वेरी पैरामीटर
Firebase डेटाबेस REST API इन क्वेरी पैरामीटर को स्वीकार करता है और मान:
access_token
यह सुविधा हर तरह के अनुरोध के साथ काम करती है. यह अनुमति देने के लिए इस अनुरोध की पुष्टि करता है Firebase Realtime Database Security Rules से सुरक्षित किए गए डेटा का ऐक्सेस. देखें ज़्यादा जानकारी के लिए, REST की पुष्टि करने से जुड़ा दस्तावेज़.
curl 'https://[PROJECT_ID].firebaseio/users/jack/name.json?access_token=CREDENTIAL'
शैलो
यह एक बेहतर सुविधा है, जिसे बड़े पैमाने पर काम करने में आपकी मदद करने के लिए डिज़ाइन किया गया है
डेटासेट डाउनलोड करने की ज़रूरत नहीं है. इसे इस पर सेट करें
दिखाए गए डेटा की डेप्थ को सीमित करने के लिए, true
किसी जगह पर. अगर जगह का डेटा JSON प्रिमिटिव है, तो
(स्ट्रिंग, संख्या या बूलियन) का इस्तेमाल करते हैं, तो इसका मान बस दिखाया जाएगा. अगर
जगह का डेटा स्नैपशॉट एक JSON ऑब्जेक्ट है,
हर कुंजी के मान को छोटा करके true
कर दिया जाएगा.
तर्क | REST के तरीके | ब्यौरा |
---|---|---|
शलो | GET | जवाब कम शब्दों में दें. |
curl 'https://[PROJECT_ID].firebaseio/.json?shallow=true'
ध्यान दें कि shallow
को किसी दूसरी क्वेरी के साथ नहीं मिलाया जा सकता
पैरामीटर का इस्तेमाल करें.
प्रिंट करें
सर्वर से रिस्पॉन्स के तौर पर मिले डेटा को फ़ॉर्मैट करता है.
तर्क | REST के तरीके | ब्यौरा |
---|---|---|
सुंदर | पाएं, डालें, पोस्ट करें, पैच करें, मिटाएं | डेटा को ऐसे फ़ॉर्मैट में देखें जिसे कोई भी व्यक्ति आसानी से पढ़ सके. |
साइलेंट | ऐप्लिकेशन पाना, डालना, पोस्ट करना, और पैच करना |
डेटा लिखते समय, सर्वर से मिलने वाले आउटपुट को बंद करने के लिए इस्तेमाल किया जाता है.
मिलने वाला जवाब खाली होगा और इसे
204 No Content एचटीटीपी स्टेटस कोड.
|
curl 'https://[PROJECT_ID].firebaseio.com/users/jack/name.json?print=pretty'
curl -X PUT -d '{ "first": "Jack", "last": "Sparrow" }' \ 'https://[PROJECT_ID].firebaseio.com/users/jack/name.json?print=silent'
कॉलबैक
यह सुविधा सिर्फ़ GET
के साथ काम करती है. वेब ब्राउज़र से REST कॉल करने के लिए
तो जवाब को JavaScript में रैप करने के लिए JSONP का इस्तेमाल किया जा सकता है
कॉलबैक फ़ंक्शन. REST API रैप पाने के लिए callback=
जोड़ें
आपके तय किए गए कॉलबैक फ़ंक्शन में लौटाया गया डेटा.
<script> function gotData(data) { console.log(data); } </script> <script src="https://[PROJECT_ID].firebaseio.com/.json?callback=gotData"></script>
फ़ॉर्मैट
अगर export
पर सेट किया जाता है, तो सर्वर प्राथमिकताओं को
जवाब.
तर्क | REST के तरीके | ब्यौरा |
---|---|---|
एक्सपोर्ट करना | GET | जवाब में ज़रूरी जानकारी शामिल करें. |
curl 'https://[PROJECT_ID].firebaseio.com/.json?format=export'
डाउनलोड करें
यह सुविधा सिर्फ़ GET
के साथ काम करती है. अगर आप किसी फ़ाइल को
वेब ब्राउज़र से अपना डेटा डाउनलोड करने के लिए, download=
जोड़ें.
इससे REST सेवा सही हेडर जोड़ती है, ताकि
ब्राउज़र डेटा को फ़ाइल में सेव करना जानते हैं.
curl 'https://[PROJECT_ID].firebaseio/.json?download=myfilename.txt'
टाइम आउट
सर्वर साइड पर पढ़ने में लगने वाला समय सीमित करने के लिए इसका इस्तेमाल करें. अगर अनुरोध दिए गए समय में पूरा नहीं होता. यह एक एचटीटीपी से खत्म होता है 400 कोड वाली गड़बड़ी. यह खास तौर पर तब फ़ायदेमंद होता है, जब आपको छोटे डेटा ट्रांसफ़र की उम्मीद हो साथ ही, आपको एक बड़ी सबट्री को फ़ेच करने के लिए, ज़्यादा इंतज़ार करने की ज़रूरत नहीं है. वास्तविक पढ़ने में लगने वाला समय, डेटा के साइज़ और कैश मेमोरी के हिसाब से अलग-अलग हो सकता है.
timeouts
के बारे में बताने के लिए, इस फ़ॉर्मैट का इस्तेमाल करें: 3ms
,
नंबर और यूनिट के साथ 3s
या 3min
. अगर नहीं
तय किए गए, 15min
का ज़्यादा से ज़्यादा timeout
होगा
लागू किया गया. अगर timeout
पॉज़िटिव नहीं है या तय सीमा से ज़्यादा है, तो
अनुरोध को एचटीटीपी 400 वाली गड़बड़ी के साथ अस्वीकार कर दिया जाएगा.
लिखने के लिए साइज़ की सीमा
किसी राइटिंग का साइज़ सीमित करने के लिए,
writeSizeLimit
क्वेरी पैरामीटर को इस तौर पर तय कर सकता है
tiny
(टारगेट=1s), small
(टारगेट=10s),
medium
(टारगेट=30s), large
(टारगेट=60s).
रीयलटाइम डेटाबेस, लिखने के हर अनुरोध के साइज़ का अनुमान लगाता है और रद्द करता है
ऐसे अनुरोध जो टारगेट किए गए समय से ज़्यादा समय लेंगे.
अगर unlimited
की जानकारी दी जाती है, तो बहुत ज़्यादा बड़ा कॉन्टेंट लिखा जाएगा (256 एमबी तक के पेलोड के साथ)
की अनुमति है, जिससे बाद में आने वाले अनुरोधों को ब्लॉक किया जा सकता है. ऐसा तब होता है, जब डेटाबेस
मौजूदा कार्रवाई. सर्वर पर पहुंचने के बाद, राइटिंग की प्रोसेस रद्द नहीं की जा सकती.
curl -X DELETE 'https://docs-examples.firebaseio.com/rest/delete-data.json?writeSizeLimit=medium'
अगर डेटा का साइज़ बहुत बड़ा है, तो आपको गड़बड़ी का यह मैसेज दिखेगा:
Error: WRITE_TOO_BIG: Data to write exceeds the maximum size that can be modified with a single request.
इसके अलावा, पूरे डेटाबेस के लिए defaultWriteSizeLimit
को सेट किया जा सकता है
इंस्टेंस, जो Firebase सीएलआई का इस्तेमाल करके बनाया गया है. यह सीमा सभी अनुरोधों पर लागू होती है. इनमें SDK टूल से मिलने वाले अनुरोध भी शामिल हैं.
नए डेटाबेस बनाए जाते हैं, जिनमें defaultWriteSizeLimit
को large
पर सेट किया जाता है.
Firebase सीएलआई का इस्तेमाल करके, defaultWriteSizeLimit
को tiny
पर सेट नहीं किया जा सकता.
firebase database:settings:set defaultWriteSizeLimit large
orderBy
गाइड में दिए गए सेक्शन को यहां देखें ऑर्डर किया गया डेटा हमारा वीडियो देखें.
सीमाके लिए पहली, सीमा
गाइड में दिए गए सेक्शन को यहां देखें डेटा को फ़िल्टर करने की सुविधा ज़्यादा जानकारी देखें.
REST API से स्ट्रीमिंग
Firebase REST एंडपॉइंट EventSource / सर्वर से भेजे गए इवेंट प्रोटोकॉल का इस्तेमाल करना चाहिए. अपने Realtime Database में किसी एक जगह में किए गए बदलावों को स्ट्रीम करने के लिए, आपको कुछ काम करने होंगे:
-
क्लाइंट के स्वीकार करें हेडर को
"text/event-stream"
पर सेट करें - एचटीटीपी रीडायरेक्ट का पालन करें, खास तौर पर एचटीटीपी स्टेटस कोड 307
-
अगर जगह की जानकारी को पढ़ने की अनुमति ज़रूरी है, तो आपको
auth
पैरामीटर
इसके बदले में, सर्वर नाम वाले इवेंट को
अनुरोध किए गए यूआरएल में हुए बदलाव. इन मैसेज का स्ट्रक्चर,
EventSource
प्रोटोकॉल.
event: event name data: JSON encoded data payload
सर्वर नीचे दिए गए इवेंट भेज सकता है:
रखें
JSON कोड में बदला गया डेटा, दो कुंजियों वाला एक ऑब्जेक्ट होता है: path और data. पाथ की अहम जानकारी अनुरोध यूआरएल के मुताबिक जगह की जानकारी. क्लाइंट को सभी उस जगह का डेटा के साथ कैश मेमोरी में सेव किया गया डेटा.
पैच
JSON कोड में बदला गया डेटा, दो कुंजियों वाला एक ऑब्जेक्ट होता है: path और data. पाथ की अहम जानकारी अनुरोध यूआरएल के मुताबिक जगह की जानकारी. हर कुंजी के लिए data, तो क्लाइंट को कुंजी के डेटा से मेल खाती हो.
कीप-अलाइव
इस इवेंट का डेटा null
है. कोई कार्रवाई ज़रूरी नहीं है.
रद्द करें
अचानक होने वाली कुछ गड़बड़ियां, `cancel` इवेंट भेज सकती हैं और कनेक्शन को खत्म कर सकती हैं. इस इवेंट के लिए दिए गए डेटा में इसकी वजह बताई गई है. इसकी कुछ संभावित वजहें हैं अनुसरण करता है: 1. Firebase Realtime Database Security Rules अब अनुरोध की गई जगह पर पढ़ने की अनुमति नहीं देता. कॉन्टेंट बनाने इस वजह के लिए `डेटा` की जानकारी में "अनुमति नहीं मिली" है. 2. किसी राइट ने इवेंट स्ट्रीमर को ट्रिगर किया, जिसने हमारी सीमा से ज़्यादा बड़ा JSON ट्री भेजा, 512 एमबी. इस वजह का `डेटा` "तय किया गया पेलोड बहुत बड़ा है, कृपया कम डेटा वाला स्थान."
auth_Revoked
इस इवेंट का डेटा एक ऐसी स्ट्रिंग है जो बताती है कि
यह खत्म हो गया है. इस इवेंट को तब भेजा गया, जब auth
पैरामीटर अब मान्य नहीं है.
यहां उन इवेंट के सेट के उदाहरण दिए गए हैं जिन्हें सर्वर भेज सकता है:
// Set your entire cache to {"a": 1, "b": 2} event: put data: {"path": "/", "data": {"a": 1, "b": 2}} // Put the new data in your cache under the key 'c', so that the complete cache now looks like: // {"a": 1, "b": 2, "c": {"foo": true, "bar": false}} event: put data: {"path": "/c", "data": {"foo": true, "bar": false}} // For each key in the data, update (or add) the corresponding key in your cache at path /c, // for a final cache of: {"a": 1, "b": 2, "c": {"foo": 3, "bar": false, "baz": 4}} event: patch data: {"path": "/c", "data": {"foo": 3, "baz": 4}}
प्राथमिकताएं
किसी जगह की प्राथमिकता की जानकारी को
"वर्चुअल चाइल्ड" .priority
नाम दिया गया. प्राथमिकताओं को पढ़ने के लिए,
GET
अनुरोध करें और उन्हें PUT
अनुरोधों के साथ लिखें.
उदाहरण के लिए, नीचे दिया गया अनुरोध
users/tom
नोड:
curl 'https://[PROJECT_ID].firebaseio/users/tom/.priority.json'
प्राथमिकता और डेटा एक साथ लिखने के लिए,
JSON पेलोड में .priority
चाइल्ड:
curl -X PUT -d '{"name": {"first": "Tom"}, ".priority": 1.0}' \ 'https://[PROJECT_ID].firebaseio/users/tom.json'
प्राथमिकता और किसी शुरुआती वैल्यू (जैसे, स्ट्रिंग) को एक साथ लिखने के लिए,
आपके पास .priority
चाइल्ड जोड़ने और बुनियादी वैल्यू सेट करने का विकल्प है
.value
बच्चे में:
curl -X PUT -d '{".value": "Tom", ".priority": 1.0}' \ 'https://[PROJECT_ID].firebaseio/users/tom/name/first.json'
यह 1.0
की प्राथमिकता के साथ "Tom"
को लिखता है.
प्राथमिकताओं को JSON पेलोड में किसी भी गहराई पर शामिल किया जा सकता है.
सर्वर वैल्यू
आप एक प्लेसहोल्डर वैल्यू का इस्तेमाल करके, किसी जगह पर सर्वर वैल्यू लिख सकते हैं
एक ऑब्जेक्ट है, जिसमें एक .sv
बटन है. उस कुंजी का मान यह है
सर्वर वैल्यू का वह टाइप जिसे आपको सेट करना है. उदाहरण के लिए, निम्न
अनुरोध, नोड के मान को Firebase सर्वर के वर्तमान मान पर सेट करता है
टाइमस्टैंप:
curl -X PUT -d '{".sv": "timestamp"}' \ 'https://[PROJECT_ID].firebaseio/users/tom/startedAtTime.json'
सर्वर वैल्यू का इस्तेमाल करके भी प्राथमिकताएं लिखी जा सकती हैं. इसके लिए, "वर्चुअल चाइल्ड" पाथ का इस्तेमाल करें.
ये सर्वर वैल्यू इस्तेमाल की जा सकती हैं:
सर्वर मान | |
---|---|
टाइमस्टैंप | UNIX epoch के बाद से समय, मिलीसेकंड में. |
बढ़ोतरी | इस फ़ॉर्म में, पूर्णांक या फ़्लोटिंग पॉइंट डेल्टा वैल्यू दें
{ ".sv": {"increment": <delta_value> }} , जिससे शुरू से ही
मौजूदा डेटाबेस वैल्यू को बढ़ाएं. अगर डेटा अभी तक मौजूद नहीं है, तो अपडेट सेट हो जाएगा
डेटा को डेल्टा वैल्यू तक ले जाना. अगर डेल्टा वैल्यू या मौजूदा डेटा में से कोई एक फ़्लोटिंग हो
पॉइंट नंबर, दोनों वैल्यू को फ़्लोटिंग पॉइंट नंबर के रूप में लिया जाएगा और
बैक-एंड का इस्तेमाल डबल वैल्यू के तौर पर करें. दोहरा अंकगणित और दो मानों के निरूपण का पालन किया जाता है
आईईईई 754 सिमेंटिक्स. अगर पॉज़िटिव/नेगेटिव पूर्णांक ओवरफ़्लो होता है, तो कुल योग का हिसाब लगाया जाता है
डबल के तौर पर. |
Firebase Realtime Database Security Rules को लाया और अपडेट किया जा रहा है
REST API का इस्तेमाल, इसके लिए Firebase Realtime Database Security Rules: आपका Firebase प्रोजेक्ट. इसके लिए, आपको अपने Firebase प्रोजेक्ट के सीक्रेट की ज़रूरत होगी आपको आपके Firebase प्रोजेक्ट के सेवा खाते पैनल सेटिंग.
curl 'https://[PROJECT_ID].firebaseio/.settings/rules.json?auth=FIREBASE_SECRET' curl -X PUT -d '{ "rules": { ".read": true } }' 'https://[PROJECT_ID].firebaseio/.settings/rules.json?auth=FIREBASE_SECRET'
अनुरोधों की पुष्टि करें
डिफ़ॉल्ट रूप से, REST के अनुरोध पुष्टि किए बिना लागू किए जाते हैं और सिर्फ़ तब ही सफल होते हैं, जब
Realtime Database नियम सार्वजनिक तौर पर, इन्हें पढ़ने या लिखने का ऐक्सेस देते हैं
के लिए इस्तेमाल किया जा सकता है. अपने अनुरोध की पुष्टि करने के लिए,
access_token=
या auth=
क्वेरी पैरामीटर.
इसमें REST API के ज़रिए पुष्टि करने के बारे में ज़्यादा जानें REST के अनुरोधों की पुष्टि करें.
गड़बड़ी की शर्तें
Firebase डेटाबेस REST API, नीचे दिए गए गड़बड़ी के कोड दिखा सकता है.
एचटीटीपी स्टेटस कोड | |
---|---|
400 गलत अनुरोध |
गड़बड़ी की इन शर्तों में से कोई एक:
|
401 अनुमति नहीं है |
गड़बड़ी की इन शर्तों में से कोई एक:
|
404 दस्तावेज़ नहीं मिला | बताया गया Realtime Database नहीं मिला. |
500 सर्वर में गड़बड़ी | सर्वर ने एक गड़बड़ी दिखाई. ज़्यादा जानकारी के लिए गड़बड़ी का मैसेज देखें विवरण. |
503 सेवा उपलब्ध नहीं है | तय किया गया Firebase रीयल टाइम डेटाबेस कुछ समय के लिए उपलब्ध नहीं है, इसका मतलब है कि अनुरोध नहीं किया गया. |
412 पहले से तय की गई शर्त पूरी नहीं हुई | अगर मैच होने वाले हेडर में अनुरोध के लिए तय की गई ETag वैल्यू है, तो वह सर्वर की वैल्यू से मैच नहीं हुई. |