Compliance Firehose API

कृपया ध्यान दें

हमने X API v2 में batch compliance नाम का एक नया कंप्लायंस टूल जारी किया है। यह नया टूल आपको पोस्ट या उपयोगकर्ता IDs के बड़े डेटासेट अपलोड करने की सुविधा देता है, ताकि उनकी कंप्लायंस स्थिति प्राप्त की जा सके और यह निर्धारित किया जा सके कि आपके डेटासेट को अनुपालन में लाने के लिए किस डेटा पर कार्रवाई आवश्यक है।

इसके अतिरिक्त, पोस्ट संपादन के समर्थन के लिए batch compliance और compliance firehose, दोनों को अपडेट किया गया है। compliance firehose के लिए, एक नया ‘tweet_edit’ इवेंट जोड़ा गया है। अधिक जानकारी के लिए Compliance Data Objects दस्तावेज़ देखें। Edit Post मेटाडेटा कैसे काम करता है, इसके बारे में अधिक जानने के लिए Edit Posts fundamentals पेज देखें।

​

अवलोकन

Enterprise

X के मूल मूल्यों में से एक है उपयोगकर्ता की आवाज़ की रक्षा करना और उसका सम्मान करना। इसमें उनकी अपेक्षाओं और मंशा का सम्मान करना भी शामिल है, जब वे X पर साझा की गई अपनी सामग्री को हटाते, बदलते या संपादित करते हैं। हमारा मानना है कि यह दुनिया के सबसे बड़े सार्वजनिक, रीयल-टाइम सूचना प्लेटफ़ॉर्मों में से एक के दीर्घकालिक स्वास्थ्य के लिए अत्यंत महत्वपूर्ण है। X अपने उपयोगकर्ताओं को नियंत्रण देता है, जिससे व्यक्तियों को अपने X अनुभव को नियंत्रित करने की क्षमता मिलती है। हमारा मानना है कि X डेटा प्राप्त करने वाले व्यावसायिक उपभोक्ताओं की यह ज़िम्मेदारी है कि वे अंतिम उपयोगकर्ताओं की अपेक्षाओं और मंशा का सम्मान करें।

X प्लेटफ़ॉर्म पर संभव अनुपालन संबंधी घटनाओं के प्रकारों के बारे में अधिक जानकारी के लिए, हमारा लेख X पर उपयोगकर्ता की मंशा का सम्मान करना देखें।

API के माध्यम से X डेटा का उपयोग करने वाले किसी भी डेवलपर या कंपनी पर यह दायित्व होता है कि वह उपयोगकर्ता सामग्री में होने वाले बदलावों का सम्मान करने के लिए सभी उचित प्रयास करे। यह दायित्व उपयोगकर्ता घटनाओं, जैसे हटाना, संशोधन, और शेयरिंग विकल्पों में बदलाव (उदाहरण के लिए, सामग्री का संरक्षित या रोकी गई हो जाना) तक विस्तृत होता है। इसमें वे स्थितियाँ भी शामिल हैं जब उपयोगकर्ता अपने पोस्ट्स को संपादित करते हैं। कृपया Developer Policy और/या अपने X Data Agreement में दी गई विशिष्ट भाषा देखें, ताकि आप समझ सकें कि यह दायित्व आपके X डेटा के उपयोग को कैसे प्रभावित करता है।

X निम्नलिखित समाधान प्रदान करता है, जो इन उपयोगकर्ता अनुपालन संबंधी घटनाओं के बारे में जानकारी देते हैं और यह बताते हैं कि कोई विशिष्ट पोस्ट या उपयोगकर्ता सार्वजनिक रूप से उपलब्ध है या नहीं। समाधानों का संक्षिप्त अवलोकन और उनके सामान्य इंटीग्रेशन पैटर्न नीचे दिए गए हैं:

​

GET statuses/lookup और GET users/lookup

• प्रारूप: REST API’s देखें: GET statuses/lookup और GET users/lookup.

• ये endpoint हमेशा किसी भी पोस्ट संपादन का नवीनतम संस्करण लौटाते हैं। संपादन सुविधा शुरू होने के बाद बनाई गई पोस्ट्स का वर्णन करने वाले सभी Post objects में पोस्ट संपादन metadata शामिल होगा। यह उन पोस्ट्स पर भी लागू होता है जिन्हें संपादित नहीं किया गया था। 

• सभी पोस्ट्स के लिए, उनके बनाए जाने के 30 मिनट से अधिक समय बाद की गई requests सभी पोस्ट्स की अंतिम स्थिति दर्शाएँगी। 

• API request के हिस्से के रूप में caller द्वारा परिभाषित विशिष्ट पोस्ट्स या उपयोगकर्ताओं के लिए उपलब्धता संबंधी जानकारी प्रदान करते हैं।

• पोस्ट्स / उपयोगकर्ताओं के किसी विशिष्ट समूह की वर्तमान उपलब्धता स्थिति की ad-hoc spot-checking के लिए इनका उपयोग किया जा सकता है।

• उन ग्राहकों के लिए आदर्श, जिन्हें किसी निश्चित समय पर किसी विशेष पोस्ट या उपयोगकर्ता की वर्तमान स्थिति जांचने का तरीका चाहिए।

• ये API’s एक उपयोगी तंत्र प्रदान करते हैं, जिसका उपयोग वे ग्राहक कर सकते हैं जिन्हें किसी सामग्री की उपलब्धता जांचनी हो, उदाहरण के लिए जब:

  1. पोस्ट्स प्रदर्शित करना
  2. किसी पोस्ट या उपयोगकर्ता के साथ 1:1 तरीके से इंटरैक्ट करना
  3. अनुमत file download के माध्यम से X सामग्री को किसी 3rd party तक वितरित करना
  4. पोस्ट्स को लंबे समय तक संग्रहीत करना

​

Compliance Firehose (केवल एंटरप्राइज़)

• फ़ॉर्मैट: Streaming API देखें: Compliance Firehose.
• X पर Compliance activities की रियल-टाइम स्ट्रीम प्रदान करता है। इन गतिविधियों में पोस्ट्स के संपादित किए जाने की घटनाएँ भी शामिल हैं। 
• प्लेटफ़ॉर्म पर नए अनुपालन इवेंट होने पर, संग्रहीत डेटा के किसी सेट में अनुपालन स्थिति बनाए रखने के लिए इसका उपयोग किया जा सकता है।
• उन ग्राहकों के लिए आदर्श है जो लंबे समय तक X डेटा की बड़ी मात्रा प्राप्त और संग्रहीत करते हैं।

​

गाइड

​

अनुपालन के लिए सर्वोत्तम प्रथाएँ

​

सिफारिशें और सर्वोत्तम प्रथाएँ

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

• ऐसी स्कीमाएँ बनाएँ जो सभी अनुपालन स्थितियों को कवर करें: विभिन्न ऐप्लिकेशनों में अनुपालन गतिविधियों को कैसे संभाला जाएगा, इसके आधार पर डेटा स्टोर में अन्य मेटाडेटा जोड़ना आवश्यक हो सकता है। उदाहरण के लिए, डेटा उपभोक्ता status\_withheld संदेश से प्रभावित देशों में सामग्री के प्रदर्शन को सीमित करने में सुविधा के लिए किसी मौजूदा डेटाबेस में मेटाडेटा जोड़ने का निर्णय ले सकते हैं।

• Retweet डिलीट को संभालना: Retweets, पोस्ट का एक विशेष प्रकार हैं, जिसमें मूल संदेश Retweet के भीतर एक ऑब्जेक्ट में नेस्टेड होता है। इस स्थिति में, एक Retweet में दो पोस्ट IDs का संदर्भ होता है – एक Retweet की ID, और दूसरी मूल संदेश की ID (जो नेस्टेड ऑब्जेक्ट में शामिल होती है)। जब कोई मूल संदेश हटाया जाता है, तो मूल ID के लिए एक पोस्ट delete संदेश जारी किया जाता है। पोस्ट deletion इवेंट्स आम तौर पर सभी Retweets के लिए delete इवेंट्स ट्रिगर करते हैं। हालांकि, कुछ मामलों में सभी नहीं भेजे जाते, इसलिए client systems को अपूर्ण Retweet deletions को सहन करने में सक्षम होना चाहिए। मूल ID का deletion, उसके बाद आने वाले सभी Retweets को हटाने के लिए पर्याप्त होना चाहिए। Retweets को संग्रहीत करते समय मूल पोस्ट ID का संदर्भ रखना, और पोस्ट delete इवेंट्स प्राप्त होने पर सभी संदर्भित Retweets को हटा देना, एक सर्वोत्तम प्रथा है।

​

अनुपालन डेटा ऑब्जेक्ट्स

​

Compliance Firehose API

अनुपालन इवेंट के संभावित प्रकारों में पोस्ट (या “status”) इवेंट और उपयोगकर्ता इवेंट शामिल हैं, जिनके कई प्रकार नीचे बताए गए हैं।  

कृपया ध्यान दें:

• उपयोगकर्ता statuses के बारे में अधिक यहाँ पढ़ें, और deleted पोस्ट्स से संबंधित हमारी developer policy यहाँ देखें।
• Compliance Firehose को ‘tweet_edit’ इवेंट प्रदान करने के लिए अपडेट किया गया है। 
• कई उपयोगकर्ता delete, protect और suspend इवेंट आवश्यक रूप से स्थायी नहीं होते और वे अवस्थाओं के बीच अनंत बार टॉगल हो सकते हैं। इनमें शामिल हैं: user_delete, user_undelete, user_protect, user_unprotect, user_suspend, user_unsuspend।
• user_deletes के 30 दिन बाद status_deletes केवल तभी आते हैं, जब उपयोगकर्ता ने अपने खाते को user_undelete चुनकर पुनर्स्थापित न किया हो। यह संभव है कि user_delete को उपयोगकर्ता बाद में उलट दे, और 30 दिन बाद उनकी सभी पोस्ट्स के लिए deletes न हों।
• user_suspend एक ऐसी कार्रवाई है जो तब तक प्रभावी रहती है, जब तक उपयोगकर्ता पर user_unsuspend इवेंट लागू न हो। ये 30 दिनों की समयावधि के किसी बदलाव के अधीन नहीं होते।

अंतिम उपयोगकर्ता की गोपनीयता और मंशा का सम्मान करने के लिए, हर प्रकार के इवेंट को कैसे प्रोसेस करना है, यह समझने हेतु ‘Recommended Action’ कॉलम देखें।

मूल संदेश प्रकार	ऑब्जेक्ट	स्थायी (हाँ/नहीं)	अनुशंसित कार्रवाई
delete	Status	हाँ	संबंधित पोस्ट हटाएँ।
status_withheld	Status	हाँ	status_withheld संदेश में सूचीबद्ध विशिष्ट देशों में संबंधित पोस्ट को दबाएँ।
drop	Status	नहीं	पोस्ट को सार्वजनिक दृश्य से हटाएँ।
undrop	Status	नहीं	Status को फिर से प्रदर्शित किया जा सकता है और उसे सार्वजनिक माना जा सकता है।
tweet_edit	Status	हाँ	इसका सम्मान करें और जहाँ प्रासंगिक हो, नया edit दिखाएँ।
user_delete	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को दबाएँ या हटाएँ।
user_undelete	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को फिर से प्रदर्शित किया जा सकता है और उन्हें सार्वजनिक माना जा सकता है।
user_protect	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को दबाएँ या हटाएँ।
user_unprotect	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को फिर से प्रदर्शित किया जा सकता है और उन्हें सार्वजनिक माना जा सकता है।
user_suspend	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को दबाएँ या हटाएँ।
user_unsuspend	उपयोगकर्ता	नहीं	संबंधित उपयोगकर्ता की सभी पोस्ट्स को फिर से प्रदर्शित किया जा सकता है और उन्हें सार्वजनिक माना जा सकता है।
scrub_geo	उपयोगकर्ता	हाँ	scrub_geo संदेश में निर्दिष्ट पोस्ट से पहले, उपयोगकर्ता की सभी पोस्ट्स के लिए X द्वारा प्रदान किया गया समस्त geodata हटाएँ। ध्यान दें कि उपयोगकर्ता की बाद की पोस्ट्स में geodata हो सकता है, जिसका उपयोग किया जा सकता है।
user_withheld	उपयोगकर्ता	हाँ	user_withheld संदेश में सूचीबद्ध विशिष्ट देशों में संबंधित उपयोगकर्ता की पोस्ट्स को दबाएँ।
delete	Favorite	हाँ	संबंधित like/favorite हटाएँ।

​

पेलोड के उदाहरण

ऊपर दी गई तालिका में वर्णित प्रत्येक अनुपालन ईवेंट के लिए नीचे पेलोड के उदाहरण देखें।

पोस्ट संपादित करना

{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }

पोस्ट हटाया जाना

{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

पोस्ट रोकी गई

{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}

ड्रॉप

{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

Undrop

{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​

भौगोलिक जानकारी हटाना

{
  "scrub_geo": {
    "user_id": 519761961,
    "up_to_status_id": 411552403083628540,
    "up_to_status_id_str": "411552403083628544",
    "user_id_str": "519761961",
    "timestamp_ms": "1432228180345"
  }
}

उपयोगकर्ता विलोपन

{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}

उपयोगकर्ता पुनर्बहाली

{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}

उपयोगकर्ता की जानकारी रोकी गई

{
  "user_withheld": {
    "user": {
      "id": 1375036644,
      "id_str": "1375036644"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestampMs": "2014-08-27T23:49:41.839+00:00"
  }
}

उपयोगकर्ता को सुरक्षित करना

{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}

उपयोगकर्ता की सुरक्षा हटाना

{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}

उपयोगकर्ता को निलंबित करें

{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}

उपयोगकर्ता का निलंबन समाप्त करना

{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​

Compliance Firehose को एकीकृत करना

Compliance Firehose एक रीयलटाइम स्ट्रीमिंग API है, जो X प्लेटफ़ॉर्म पर होने वाली अनुपालन इवेंट्स डिलीवर करती है। अनुपालन इवेंट्स और वे X पर कैसे जनरेट होते हैं, इसे समझने के लिए कृपया हमारा लेख, X पर उपयोगकर्ता की मंशा का सम्मान, देखें।

यह ध्यान रखना महत्वपूर्ण है कि पोस्ट और उपयोगकर्ता इवेंट्स अलग-अलग डिलीवर किए जाते हैं और दोनों को अलग-अलग प्रोसेस किया जाना चाहिए (अर्थात, किसी पोस्ट delete का मतलब यह नहीं है कि कोई उपयोगकर्ता इवेंट भी हुआ है, और इसका उलटा भी सही है।) कई उपयोगकर्ता इवेंट्स आवश्यक रूप से स्थायी नहीं होते और वे अनिश्चितकाल तक अलग-अलग अवस्थाओं के बीच टॉगल हो सकते हैं। इनमें शामिल हैं: user_delete,user_undelete, user_protect, user_unprotect और user_suspend, user_unsuspend।

User_deletes के 30 दिन बाद status_deletes आते हैं, लेकिन केवल तभी जब उपयोगकर्ता ने अपने खाते को user_undelete करने का विकल्प नहीं चुना हो। यह संभव है कि user_delete को उपयोगकर्ता बाद में रिवर्स कर दे, और ऐसे में 30 दिन बाद उनकी सभी पोस्ट्स के लिए deletes न हों।

User_suspend एक ऐसी कार्रवाई है, जो तब तक प्रभावी रहती है जब तक उपयोगकर्ता पर user_unsuspend इवेंट लागू न हो। ये 30 दिन की समयावधि से संबंधित किसी बदलाव के अधीन नहीं होते।

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

​

Compliance Firehose के साथ एकीकरण

Compliance Firehose को अपने सिस्टम में एकीकृत करने के लिए, आपको ऐसा इंटीग्रेशन बनाना होगा जो निम्नलिखित कार्य कर सके:

1. Compliance Firehose के प्रत्येक स्ट्रीमिंग API पार्टिशन के साथ एक स्ट्रीमिंग कनेक्शन स्थापित करे
2. अधिक डेटा वॉल्यूम को संभाले – असिंक्रोनस प्रक्रियाओं का उपयोग करके स्ट्रीम इनजेशन को अतिरिक्त प्रोसेसिंग से अलग रखे
3. किसी भी कारण से डिस्कनेक्ट होने पर स्ट्रीम पार्टिशनों से अपने-आप फिर से कनेक्ट हो
4. ऊपर दिए गए मार्गदर्शन के अनुसार, आपके द्वारा संग्रहीत पोस्ट और उपयोगकर्ता डेटा से संबंधित अनुपालन इवेंट्स को प्रोसेस करे

​

Twitter पर उपयोगकर्ता की मंशा का सम्मान करना

हमारा मानना है कि X उपयोगकर्ताओं की गोपनीयता और मंशा का सम्मान करना दुनिया के सबसे बड़े सार्वजनिक, रीयल-टाइम सूचना प्लेटफ़ॉर्मों में से एक के दीर्घकालिक स्वास्थ्य के लिए बेहद महत्वपूर्ण है। X गोपनीयता नियंत्रण अपने उपयोगकर्ताओं के हाथ में देता है, जिससे लोगों को अपने X अनुभव को नियंत्रित करने की क्षमता मिलती है। X डेटा के व्यावसायिक उपभोक्ताओं के रूप में, इस भरोसे और सम्मान के माहौल को बनाए रखने के लिए अंतिम उपयोगकर्ताओं की गोपनीयता और उनके कार्यों का सम्मान करना हमारी सामूहिक ज़िम्मेदारी है।

पोस्ट्स और उपयोगकर्ता खातों के साथ कई तरह की चीज़ें हो सकती हैं, जो इस बात को प्रभावित करती हैं कि वे प्लेटफ़ॉर्म पर कैसे दिखते हैं। गोपनीयता और मंशा को प्रभावित करने वाली कार्रवाइयाँ Status (Post) और उपयोगकर्ता, दोनों स्तरों पर परिभाषित की गई हैं। इन कार्रवाइयों में शामिल हैं:

​

उपयोगकर्ता

Action	Description
खाते को सुरक्षित करें	X का कोई उपयोगकर्ता किसी भी समय अपने खाते को सुरक्षित या असुरक्षित कर सकता है। सुरक्षित खातों में, खाते के पोस्ट्स देखने की अनुमति पाने वाले हर व्यक्ति के लिए उपयोगकर्ता की मैन्युअल स्वीकृति आवश्यक होती है।  अधिक जानकारी के लिए, About Public and Protected Posts देखें।
खाता हटाएँ	X का कोई उपयोगकर्ता किसी भी समय अपना खाता और उससे जुड़े सभी स्टेटस संदेशों को हटाने का निर्णय ले सकता है। यदि उपयोगकर्ता अपना खाता फिर से बहाल करना और प्रभावी रूप से पुनः सक्रिय करना चाहे, तो X हटाने के बाद 30 दिनों तक खाते की जानकारी सुरक्षित रखता है।
Geo हटाएँ	X का कोई उपयोगकर्ता किसी भी समय पिछले पोस्ट्स से सभी स्थान-संबंधी डेटा हटा सकता है। इसे “scrub geo” कहा जाता है।
खाता निलंबित करें	X को उन खातों को निलंबित करने का अधिकार है जो X के नियमों का उल्लंघन करते हैं या जिनके हैक या कंप्रोमाइज़ होने की आशंका होती है। खाते का निलंबन केवल X द्वारा ही हटाया जा सकता है (unsuspend)।
खाते पर रोक लगाएँ	X को समय-समय पर किसी विशेष देश में कुछ सामग्री तक पहुँच रोकने का अधिकार है। किसी रोके गए खाते से यह रोक केवल X ही हटा सकता है।  अधिक जानकारी के लिए, Country Withheld Content देखें।

​

स्टेटस

कार्रवाई	विवरण
स्टेटस हटाएँ	X उपयोगकर्ता किसी भी समय स्टेटस हटा सकता है। हटाए गए स्टेटस को वापस नहीं लाया जा सकता और वे स्थायी रूप से मिटा दिए जाते हैं।
स्टेटस पर रोक लगाएँ	X समय-समय पर किसी विशेष देश में कुछ सामग्री की पहुँच को रोकने का अधिकार सुरक्षित रखता है। जिस स्टेटस पर रोक लगाई गई हो, उसे केवल X ही फिर से उपलब्ध करा सकता है।  अधिक जानकारी के लिए, Country Withheld Content देखें।

​

उपयोगकर्ता और स्टेटस में होने वाले बदलावों पर नज़र रखना

ऊपर दी गई कार्रवाइयों में से किसी एक के कारण किसी भी समय किसी उपयोगकर्ता या स्टेटस की स्थिति बदल सकती है, और इससे यह प्रभावित होता है कि X डेटा का उपयोग करने वालों से सभी संबंधित सामग्री की उपलब्धता और गोपनीयता के साथ कैसा व्यवहार करने की अपेक्षा की जाती है। जब ये कार्रवाइयाँ होती हैं, तो एक संबंधित कंप्लायंस संदेश भेजा जाता है, जो यह दर्शाता है कि किसी स्टेटस या उपयोगकर्ता की स्थिति बदल गई है।

​

API संदर्भ

​

GET compliance/firehose

​

मेथड्स

मेथड	विवरण
GET /compliance/:stream	डेटा स्ट्रीम से जुड़ें

​

प्रमाणीकरण

Compliance Firehose API के लिए सभी अनुरोधों में HTTP Basic Authentication का उपयोग करना अनिवार्य है। यह console.gnip.com पर अपने खाते में लॉग इन करने के लिए उपयोग किए जाने वाले किसी मान्य ईमेल पते और पासवर्ड के संयोजन से बनाया जाता है। क्रेडेंशियल्स को प्रत्येक अनुरोध में Authorization header के रूप में भेजना आवश्यक है।

​

GET /compliance/:stream

Compliance firehose डेटा स्ट्रीम के लिए एक स्थायी कनेक्शन स्थापित करता है, जिसके माध्यम से compliance ईवेंट डिलीवर किए जाते हैं।

Request Method	HTTP GET
Connection Type	Keep-Alive
URL	आपके डैशबोर्ड में स्ट्रीम के API Help पेज पर उपलब्ध, और यह निम्नलिखित संरचना जैसा दिखता है: https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1 नोट: “partition” पैरामीटर आवश्यक है। पूरी स्ट्रीम का उपभोग करने के लिए आपको सभी 8 partition से कनेक्ट करना होगा, जिनमें से प्रत्येक में कुल वॉल्यूम का 12.5% होता है।
Compression	Gzip. Gzip compression का उपयोग करके स्ट्रीम से कनेक्ट करने के लिए, कनेक्शन अनुरोध में बस एक Accept-Encoding header भेजें। header निम्नलिखित जैसा दिखना चाहिए: Accept-Encoding: gzip
Character Encoding	UTF-8
Response Format	JSON. आपके अनुरोध के header में response के लिए JSON format निर्दिष्ट होना चाहिए।
Rate Limit	60 सेकंड में 10 अनुरोध।
Read Timeout	अपने client पर read timeout सेट करें और सुनिश्चित करें कि यह 30 सेकंड से अधिक मान पर सेट हो।
Support for Tweet edits	सभी Tweet edits एक “tweet_edit” Compliance event ट्रिगर करते हैं। अधिक जानकारी के लिए Compliance Data Objects दस्तावेज़ देखें।

उदाहरण cURL अनुरोध

निम्नलिखित उदाहरण अनुरोध कमांड लाइन पर cURL का उपयोग करके किया जाता है:

curl --compressed -v [e-mail] "https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1"

नोट: ऊपर दिया गया अनुरोध केवल Compliance firehose के partition=1 से कनेक्ट होता है - इस स्ट्रीम का पूरा डेटा प्राप्त करने के लिए आपको सभी 8 partitions से कनेक्ट करना होगा।

​

रिस्पॉन्स कोड

इन अनुरोधों के लिए API निम्नलिखित रिस्पॉन्स लौटा सकता है। अधिकांश त्रुटि कोड बॉडी में अतिरिक्त विवरण वाली एक स्ट्रिंग के साथ लौटाए जाते हैं। 200 के अलावा अन्य रिस्पॉन्स के लिए, क्लाइंट्स को फिर से कनेक्ट करने का प्रयास करना चाहिए।

Status	Text	Definition
200	सफलता	कनेक्शन सफलतापूर्वक खोल दिया गया और नई गतिविधियाँ उपलब्ध होते ही भेजी जाएँगी।
401	अनधिकृत	अमान्य क्रेडेंशियल्स के कारण HTTP प्रमाणीकरण विफल हो गया। अपने क्रेडेंशियल्स के साथ console.gnip.com में लॉग इन करें, ताकि यह सुनिश्चित हो सके कि आप उन्हें अपने अनुरोध के साथ सही तरीके से उपयोग कर रहे हैं।
406	स्वीकार्य नहीं	आम तौर पर, यह तब होता है जब आपका क्लाइंट स्ट्रीम से gzip encoding स्वीकार करने के लिए हेडर्स सही तरीके से शामिल नहीं करता, लेकिन यह अन्य परिस्थितियों में भी हो सकता है। इसमें “This connection requires compression. To enable compression, send an ‘Accept-Encoding: gzip’ header in your request and be ready to uncompress the stream as it is read on the client end.” जैसा एक JSON संदेश शामिल होगा।
429	रेट लिमिट लागू	आपका ऐप कनेक्शन अनुरोधों की सीमा से अधिक हो गया है।
503	सेवा अनुपलब्ध	Twitter सर्वर से जुड़ी समस्या। exponential backoff pattern का उपयोग करके फिर से कनेक्ट करें। यदि इस समस्या के बारे में X API Status Page पर कोई सूचना पोस्ट नहीं की गई है, तो support से संपर्क करें।

​

अन्य अनुशंसाएँ & सर्वोत्तम प्रथाएँ

• ऐसी डेटा स्टोरेज स्कीमाएँ बनाएँ जो संख्यात्मक Tweet ID और User ID संग्रहीत करें: उपयोगकर्ता संदेशों के लिए उस उपयोगकर्ता के सभी Tweets पर कार्रवाई करना आवश्यक होता है। इसलिए, चूँकि सभी compliance संदेश केवल संख्यात्मक ID के आधार पर ही भेजे जाते हैं, ऐसी स्टोरेज स्कीमाएँ डिज़ाइन करना महत्वपूर्ण है जो संख्यात्मक ID के आधार पर Tweet और User के बीच संबंध बनाए रखें। डेटा उपभोक्ताओं को Tweet ID और User ID, दोनों के आधार पर compliance events की निगरानी करनी होगी और स्थानीय डेटा स्टोर को उपयुक्त रूप से अपडेट करने में सक्षम होना होगा।

• ऐसी स्कीमाएँ बनाएँ जो सभी compliance statuses को कवर करें: विभिन्न अनुप्रयोगों में compliance गतिविधियों को कैसे संभाला जाएगा, इसके आधार पर डेटा स्टोर में अन्य metadata जोड़ना आवश्यक हो सकता है। उदाहरण के लिए, डेटा उपभोक्ता status_withheld संदेश से प्रभावित देशों में सामग्री के प्रदर्शन को प्रतिबंधित करने की सुविधा के लिए किसी मौजूदा डेटाबेस में metadata जोड़ने का निर्णय ले सकते हैं।

• Retweet deletes को संभालना: Retweets, Tweet का एक विशेष प्रकार हैं, जिसमें मूल संदेश Retweet के भीतर एक nested object में होता है। इस स्थिति में, एक Retweet में दो Tweet IDs संदर्भित होती हैं — एक Retweet की ID और दूसरी मूल संदेश की ID (जो nested object में शामिल होती है)। जब किसी मूल संदेश को हटाया जाता है, तो मूल ID के लिए एक Tweet delete message जारी किया जाता है। इसके बाद सभी Retweets के लिए अलग-अलग delete messages जारी नहीं किए जाते। मूल ID को हटाना, उसके बाद के सभी Retweets को हटाने के लिए पर्याप्त होना चाहिए।