इस पेज का अनुवाद Cloud Translation API से किया गया है.

लेगसी FCM एपीआई से एचटीटीपी v1 पर माइग्रेट करें

एचटीटीपी और XMPP के लिए, बंद किए गए FCM लेगसी एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन को जल्द से जल्द एचटीटीपी v1 एपीआई पर माइग्रेट करना चाहिए. इन एपीआई का इस्तेमाल करके मैसेज भेजने की सुविधा (इसमें अपस्ट्रीम मैसेज भी शामिल हैं) 20 जून, 2023 को बंद कर दी गई थी. साथ ही, इन्हें 22 जुलाई, 2024 से बंद कर दिया जाएगा.

जिन सुविधाओं पर असर पड़ा है उनके बारे में ज़्यादा जानें.

HTTP v1 API में, पुराने एपीआई की तुलना में ये फ़ायदे मिलते हैं. साथ ही, इसमें मौजूदा सहायता और नई सुविधाएं भी मिलती हैं:

ऐक्सेस टोकन के ज़रिए बेहतर सुरक्षा HTTP v1 API, OAuth2 सुरक्षा मॉडल के मुताबिक कम समय के लिए ऐक्सेस टोकन का इस्तेमाल करता है. अगर किसी वजह से ऐक्सेस टोकन सार्वजनिक हो जाता है, तो इसका गलत इस्तेमाल सिर्फ़ एक घंटे तक किया जा सकता है. इसके बाद, इसकी समयसीमा खत्म हो जाती है. लेगसी एपीआई में इस्तेमाल की गई सुरक्षा कुंजियों की तुलना में, रीफ़्रेश टोकन को बार-बार ट्रांसमिट नहीं किया जाता. इसलिए, इनके कैप्चर होने की संभावना बहुत कम होती है.
सभी प्लैटफ़ॉर्म पर मैसेज को ज़्यादा आसानी से पसंद के मुताबिक बनाना मैसेज के मुख्य हिस्से के लिए, HTTP v1 API में ऐसी सामान्य कुंजियां होती हैं जो टारगेट किए गए सभी इंस्टेंस पर जाती हैं. साथ ही, इसमें प्लैटफ़ॉर्म के हिसाब से कुंजियां होती हैं, जिनकी मदद से सभी प्लैटफ़ॉर्म पर मैसेज को पसंद के मुताबिक बनाया जा सकता है. इसकी मदद से, "बदलाव" किए जा सकते हैं. बदलाव करने पर, एक ही मैसेज में अलग-अलग क्लाइंट प्लैटफ़ॉर्म को थोड़ा अलग पेलोड भेजा जाता है.
नए क्लाइंट प्लैटफ़ॉर्म वर्शन के लिए, ज़्यादा बेहतर और आने वाले समय के हिसाब से तैयार HTTP v1 API, Apple प्लैटफ़ॉर्म, Android, और वेब पर उपलब्ध मैसेजिंग के सभी विकल्पों के साथ काम करता है. हर प्लैटफ़ॉर्म के लिए, JSON पेलोड में अलग ब्लॉक तय किया गया है. इसलिए, FCM एपीआई को ज़रूरत के हिसाब से नए वर्शन और नए प्लैटफ़ॉर्म के लिए बढ़ाया जा सकता है.

सर्वर एंडपॉइंट अपडेट करना

एचटीटीपी v1 एपीआई के एंडपॉइंट यूआरएल और लेगसी एंडपॉइंट में ये अंतर हैं:

यह वर्शन किया गया है. इसके पाथ में /v1 है.
पाथ में, आपके ऐप्लिकेशन के Firebase प्रोजेक्ट का प्रोजेक्ट आईडी होता है. यह /projects/myproject-ID/ फ़ॉर्मैट में होता है. यह आईडी, Firebase कंसोल के प्रोजेक्ट की सामान्य सेटिंग टैब में उपलब्ध होता है.
इसमें send के तरीके को :send के तौर पर साफ़ तौर पर बताया गया है.

एचटीटीपी v1 के लिए सर्वर एंडपॉइंट अपडेट करने के लिए, अपने अनुरोधों के हेडर में एंडपॉइंट में ये एलिमेंट जोड़ें.

एचटीटीपी अनुरोध

POST https://fcm.googleapis.com/fcm/send

XMPP अनुरोध पहले

लेगसी XMPP मैसेज, इस एंडपॉइंट से कनेक्ट करके भेजे जाते हैं:

fcm-xmpp.googleapis.com:5235

इसके बाद

POST https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send

भेजने के अनुरोधों की अनुमति अपडेट करना

लेगसी अनुरोधों में इस्तेमाल की गई सर्वर कुंजी स्ट्रिंग के बजाय, HTTP v1 के अनुरोध भेजने के लिए OAuth 2.0 ऐक्सेस टोकन की ज़रूरत होती है. अगर मैसेज भेजने के लिए Admin SDK का इस्तेमाल किया जा रहा है, तो लाइब्रेरी आपके लिए टोकन को मैनेज करती है. अगर रॉ प्रोटोकॉल का इस्तेमाल किया जा रहा है, तो इस सेक्शन में बताए गए तरीके से टोकन पाएं और इसे हेडर में Authorization: Bearer <valid Oauth 2.0 token> के तौर पर जोड़ें.

चेतावनी: लेगसी एपीआई की तरह ही, एचटीटीपी v1 मैसेज भरोसेमंद एनवायरमेंट से भेजे जाने चाहिए. जैसे, एचटीटीपी प्रोटोकॉल या Admin SDK का इस्तेमाल करके, मैसेज के अनुरोध बनाने के लिए, आपका ऐप्लिकेशन सर्वर या Cloud Functions for Firebase. क्लाइंट ऐप्लिकेशन के लॉजिक से सीधे तौर पर डेटा भेजने पर, सुरक्षा से जुड़ा गंभीर जोखिम होता है. इसलिए, ऐसा करने की अनुमति नहीं है.

पहला हिस्सा

Authorization: key=AIzaSyZ-1u...0GBYzPu7Udno5aA

इसके बाद

Authorization: Bearer ya29.ElqKBGN2Ri_Uz...HnS_uNreA

आपके सर्वर एनवायरमेंट की जानकारी के आधार पर, Firebase सेवाओं के लिए सर्वर के अनुरोधों को अनुमति देने के लिए, इन रणनीतियों के कॉम्बिनेशन का इस्तेमाल करें:

Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल (एडीसी)
सेवा खाते की JSON फ़ाइल
सेवा खाते से मिला, कम समय के लिए मान्य OAuth 2.0 ऐक्सेस टोकन

अगर आपका ऐप्लिकेशन Compute Engine, Google Kubernetes Engine, App Engine या Cloud Functions (इसमें Cloud Functions for Firebase भी शामिल है) पर चल रहा है, तो ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल (एडीसी) का इस्तेमाल करें. एडीसी, अनुरोधों को अनुमति देने के लिए क्रेडेंशियल पाने के लिए, आपके मौजूदा डिफ़ॉल्ट सेवा खाते का इस्तेमाल करता है. साथ ही, एडीसी एनवायरमेंट वैरिएबल GOOGLE_APPLICATION_CREDENTIALS के ज़रिए, स्थानीय टेस्टिंग को आसान बनाता है. अनुमति देने की प्रोसेस को पूरी तरह से ऑटोमेट करने के लिए, Admin SDK सर्वर लाइब्रेरी के साथ एडीसी का इस्तेमाल करें.

अगर आपका ऐप्लिकेशन, Google के सर्वर एनवायरमेंट पर नहीं चल रहा है, तो आपको अपने Firebase प्रोजेक्ट से सेवा खाते की JSON फ़ाइल डाउनलोड करनी होगी. जब तक आपके पास निजी पासकोड वाली फ़ाइल सिस्टम का ऐक्सेस है, तब तक एनवायरमेंट वैरिएबल GOOGLE_APPLICATION_CREDENTIALS का इस्तेमाल करके, मैन्युअल तरीके से हासिल किए गए इन क्रेडेंशियल के साथ अनुरोधों को अनुमति दी जा सकती है. अगर आपके पास फ़ाइल का ऐक्सेस नहीं है, तो आपको अपने कोड में सेवा खाते की फ़ाइल का रेफ़रंस देना होगा. ऐसा बहुत सावधानी से करना चाहिए, क्योंकि इससे आपके क्रेडेंशियल के सार्वजनिक होने का खतरा होता है.

एडीसी का इस्तेमाल करके क्रेडेंशियल देना

Google ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल (एडीसी), आपके क्रेडेंशियल की जांच इस क्रम में करते हैं:

एडीसी यह जांच करता है कि एनवायरमेंट वैरिएबल GOOGLE_APPLICATION_CREDENTIALS सेट है या नहीं. अगर वैरिएबल सेट है, तो एडीसी उस सेवा खाते की फ़ाइल का इस्तेमाल करता है जिसे वैरिएबल पॉइंट करता है.
अगर एनवायरमेंट वैरिएबल सेट नहीं है, तो एडीसी डिफ़ॉल्ट सेवा खाते का इस्तेमाल करता है. यह सेवा खाता, Compute Engine, Google Kubernetes Engine, App Engine, और Cloud Functions, उन ऐप्लिकेशन के लिए उपलब्ध कराते हैं जो इन सेवाओं पर चलते हैं.
अगर एडीसी, ऊपर दिए गए दोनों क्रेडेंशियल का इस्तेमाल नहीं कर सकता, तो सिस्टम में गड़बड़ी का मैसेज दिखता है.

Admin SDK के लिए, यहां दिए गए कोड के उदाहरण में इस रणनीति के बारे में बताया गया है. उदाहरण में, ऐप्लिकेशन के क्रेडेंशियल के बारे में साफ़ तौर पर नहीं बताया गया है. हालांकि, जब तक एनवायरमेंट वैरिएबल सेट है, तब तक एडीसी क्रेडेंशियल का पता लगा सकता है. इसके अलावा, जब तक ऐप्लिकेशन Compute Engine, Google Kubernetes Engine, App Engine या Cloud Functions पर चल रहा है, तब तक भी एडीसी क्रेडेंशियल का पता लगा सकता है.

Node.js

admin.initializeApp({
  credential: admin.credential.applicationDefault(),
});

Java

FirebaseOptions options = FirebaseOptions.builder()
    .setCredentials(GoogleCredentials.getApplicationDefault())
    .setDatabaseUrl("https://<DATABASE_NAME>.firebaseio.com/")
    .build();

FirebaseApp.initializeApp(options);

Python

default_app = firebase_admin.initialize_app()

शुरू करें

app, err := firebase.NewApp(context.Background(), nil)
if err != nil {
	log.Fatalf("error initializing app: %v\n", err)
}init.go

C#

FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.GetApplicationDefault(),
});

मैन्युअल तरीके से क्रेडेंशियल देना

Firebase प्रोजेक्ट, Google के सेवा खातों के साथ काम करते हैं. इनका इस्तेमाल करके, अपने ऐप्लिकेशन सर्वर या भरोसेमंद एनवायरमेंट से Firebase सर्वर एपीआई को कॉल किया जा सकता है. अगर आपको कोड को स्थानीय तौर पर डेवलप करना है या ऐप्लिकेशन को ऑन-प्रिमाइसेस पर डिप्लॉय करना है, तो सर्वर के अनुरोधों को अनुमति देने के लिए, इस सेवा खाते से मिले क्रेडेंशियल का इस्तेमाल किया जा सकता है.

किसी सेवा खाते को प्रमाणित करने और उसे Firebase की सेवाओं को ऐक्सेस करने की अनुमति देने के लिए, आपको JSON फ़ॉर्मैट में एक निजी कुंजी फ़ाइल जनरेट करनी होगी.

अपने सेवा खाते के लिए निजी पासकोड फ़ाइल जनरेट करने के लिए:

Firebase कंसोल में, सेटिंग > सेवा खाते खोलें.
नई निजी कुंजी जनरेट करें पर क्लिक करें. इसके बाद, कुंजी जनरेट करें पर क्लिक करके पुष्टि करें.
कुंजी वाली JSON फ़ाइल को सुरक्षित तरीके से सेव करें.

सेवा खाते के ज़रिए अनुमति देते समय, आपके पास अपने ऐप्लिकेशन को क्रेडेंशियल देने के दो विकल्प होते हैं. GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल सेट किया जा सकता है. इसके अलावा, कोड में सेवा खाते की कुंजी का पाथ साफ़ तौर पर पास किया जा सकता है. पहला विकल्प ज़्यादा सुरक्षित है और इसका सुझाव दिया जाता है.

एनवायरमेंट वैरिएबल सेट करने के लिए:

एनवायरमेंट वैरिएबल GOOGLE_APPLICATION_CREDENTIALS को उस JSON फ़ाइल के फ़ाइल पाथ पर सेट करें जिसमें आपके सेवा खाते की कुंजी मौजूद है. यह वैरिएबल सिर्फ़ आपके मौजूदा शेल सेशन पर लागू होता है. इसलिए, अगर आपको नया सेशन खोलना है, तो वैरिएबल को फिर से सेट करें.

Linux या macOS

export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"

खिड़कियां

PowerShell का इस्तेमाल करके:

$env:GOOGLE_APPLICATION_CREDENTIALS="C:\Users\username\Downloads\service-account-file.json"

ऊपर दिए गए चरणों को पूरा करने के बाद, ऐप्लिकेशन डिफ़ॉल्ट क्रेडेंशियल (एडीसी) आपके क्रेडेंशियल का पता लगा सकता है. इससे आपको Google से बाहर के एनवायरमेंट में टेस्टिंग या चलाने के दौरान, सेवा खाते के क्रेडेंशियल इस्तेमाल करने की अनुमति मिलती है.

ऐक्सेस टोकन जनरेट करने के लिए क्रेडेंशियल का इस्तेमाल करना

कम समय के लिए मान्य OAuth 2.0 ऐक्सेस टोकन पाने के लिए, अपनी पसंद की भाषा के लिए Google Auth Library के साथ-साथ अपने Firebase क्रेडेंशियल का इस्तेमाल करें:

node.js

 function getAccessToken() {
  return new Promise(function(resolve, reject) {
    const key = require('../placeholders/service-account.json');
    const jwtClient = new google.auth.JWT(
      key.client_email,
      null,
      key.private_key,
      SCOPES,
      null
    );
    jwtClient.authorize(function(err, tokens) {
      if (err) {
        reject(err);
        return;
      }
      resolve(tokens.access_token);
    });
  });
}index.js

इस उदाहरण में, Google API क्लाइंट लाइब्रेरी, JSON वेब टोकन या JWT की मदद से अनुरोध की पुष्टि करती है. ज़्यादा जानकारी के लिए, JSON वेब टोकन देखें.

Python

def _get_access_token():
  """Retrieve a valid access token that can be used to authorize requests.

  :return: Access token.
  """
  credentials = service_account.Credentials.from_service_account_file(
    'service-account.json', scopes=SCOPES)
  request = google.auth.transport.requests.Request()
  credentials.refresh(request)
  return credentials.tokenmessaging.py

Java

private static String getAccessToken() throws IOException {
  GoogleCredentials googleCredentials = GoogleCredentials
          .fromStream(new FileInputStream("service-account.json"))
          .createScoped(Arrays.asList(SCOPES));
  googleCredentials.refresh();
  return googleCredentials.getAccessToken().getTokenValue();
}Messaging.java

ऐक्सेस टोकन की समयसीमा खत्म होने के बाद, अपडेट किया गया ऐक्सेस टोकन पाने के लिए, टोकन रीफ़्रेश करने का तरीका अपने-आप कॉल हो जाता है.

FCM को ऐक्सेस करने की अनुमति देने के लिए, स्कोप https://www.googleapis.com/auth/firebase.messaging का अनुरोध करें.

एचटीटीपी अनुरोध के हेडर में ऐक्सेस टोकन जोड़ने के लिए:

टोकन को Authorization हेडर की वैल्यू के तौर पर, इस फ़ॉर्मैट में जोड़ें Authorization: Bearer <access_token>:

node.js

headers: {
  'Authorization': 'Bearer ' + accessToken
}index.js

Python

headers = {
  'Authorization': 'Bearer ' + _get_access_token(),
  'Content-Type': 'application/json; UTF-8',
}messaging.py

Java

URL url = new URL(BASE_URL + FCM_SEND_ENDPOINT);
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setRequestProperty("Authorization", "Bearer " + getServiceAccountAccessToken());
httpURLConnection.setRequestProperty("Content-Type", "application/json; UTF-8");
return httpURLConnection;FirebaseMessagingSnippets.java

भेजे गए अनुरोधों के पेलोड अपडेट करना

FCM HTTP v1 में, JSON मैसेज के पेलोड के स्ट्रक्चर में अहम बदलाव किया गया है. इन बदलावों से यह पक्का किया जाता है कि अलग-अलग क्लाइंट प्लैटफ़ॉर्म पर ईमेल मिलने पर, उन्हें सही तरीके से हैंडल किया जाए. इसके अलावा, इन बदलावों से आपको हर प्लैटफ़ॉर्म के हिसाब से मैसेज फ़ील्ड को पसंद के मुताबिक बनाने या "बदलाव करने" की सुविधा मिलती है.

इस सेक्शन में दिए गए उदाहरणों के अलावा, अलग-अलग प्लैटफ़ॉर्म पर मैसेज को पसंद के मुताबिक बनाना लेख पढ़ें. साथ ही, HTTP v1 के बारे में जानने के लिए, एपीआई का संदर्भ देखें.

उदाहरण: सूचना देने वाला सामान्य मैसेज

यहां एक बहुत ही सामान्य सूचना के पेलोड की तुलना की गई है. इसमें सिर्फ़ title, body, और data फ़ील्ड शामिल हैं. इससे लेगसी और एचटीटीपी v1 पेलोड के बीच बुनियादी अंतर का पता चलता है.

पहला हिस्सा

{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available."
  },
  "data": {
    "story_id": "story_12345"
  }
}

इसके बाद

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    }
  }
}

उदाहरण: नेस्ट किया गया JSON डेटा

लेगसी मैसेजिंग एपीआई के उलट, HTTP v1 API, data फ़ील्ड में नेस्ट की गई JSON वैल्यू का इस्तेमाल नहीं करता. JSON को स्ट्रिंग में बदलना ज़रूरी है.

पहला हिस्सा

{
  ...
  "data": {
    "keysandvalues": {"key1": "value1", "key2": 123}
  }
}

इसके बाद

{
  "message": {
   ...
    "data": {
      "keysandvalues": "{\"key1\": \"value1\", \"key2\": 123}"
    }
  }
}

उदाहरण: एक से ज़्यादा प्लैटफ़ॉर्म को टारगेट करना

एक से ज़्यादा प्लैटफ़ॉर्म को टारगेट करने की सुविधा चालू करने के लिए, लेगसी एपीआई बैकएंड में बदलाव करता था. इसके उलट, HTTP v1 में प्लैटफ़ॉर्म के हिसाब से कुंजियों के ब्लॉक दिए जाते हैं. इससे प्लैटफ़ॉर्म के बीच के अंतर साफ़ तौर पर दिखते हैं और डेवलपर को भी पता चलता है. इसकी मदद से, एक ही अनुरोध में हमेशा कई प्लैटफ़ॉर्म को टारगेट किया जा सकता है. इस बारे में, यहां दिए गए सैंपल में बताया गया है.

पहला हिस्सा

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

इसके बाद

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

उदाहरण: प्लैटफ़ॉर्म ओवरराइड का इस्तेमाल करके कस्टम बनाना

HTTP v1 API, अलग-अलग प्लैटफ़ॉर्म पर मैसेज को टारगेट करने की प्रोसेस को आसान बनाता है. साथ ही, यह हर प्लैटफ़ॉर्म के हिसाब से मैसेज को पसंद के मुताबिक बनाने की सुविधा देता है.

पहला हिस्सा

// Android
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "Check out the Top Story.",
    "click_action": "TOP_STORY_ACTIVITY"
  },
  "data": {
    "story_id": "story_12345"
  }
}
// Apple
{
  "to": "/topics/news",
  "notification": {
    "title": "Breaking News",
    "body": "New news story available.",
    "click_action": "HANDLE_BREAKING_NEWS"
  },
  "data": {
    "story_id": "story_12345"
  }
}

इसके बाद

{
  "message": {
    "topic": "news",
    "notification": {
      "title": "Breaking News",
      "body": "New news story available."
    },
    "data": {
      "story_id": "story_12345"
    },
    "android": {
      "notification": {
        "click_action": "TOP_STORY_ACTIVITY",
        "body": "Check out the Top Story"
      }
    },
    "apns": {
      "payload": {
        "aps": {
          "category" : "NEW_MESSAGE_CATEGORY"
        }
      }
    }
  }
}

उदाहरण: खास डिवाइसों को टारगेट करना

HTTP v1 API की मदद से किसी डिवाइस को टारगेट करने के लिए, token कुंजी के बजाय to कुंजी में डिवाइस का मौजूदा रजिस्ट्रेशन टोकन डालें.

पहला हिस्सा

  { "notification": {
      "body": "This is an FCM notification message!",
      "title": "FCM Message"
    },
    "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..."
  }

इसके बाद

{
   "message":{
      "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
      "notification":{
        "body":"This is an FCM notification message!",
        "title":"FCM Message"
      }
   }
}

FCM HTTP v1 API के बारे में ज़्यादा जानकारी और सैंपल के लिए, यहां जाएं:

HTTP v1 API की मदद से, ऐप्लिकेशन सर्वर से अनुरोध भेजने के तरीके के बारे में दिशा-निर्देश. सभी "REST" स्निपेट, v1 API का इस्तेमाल करते हैं. हालांकि, कुछ स्निपेट में इस बारे में खास तौर पर बताया गया है.
Firebase ब्लॉग.