फेसबुक एपीआई अनुरोधों में तेजी लाने के लिए नए 5 तरीके

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



पिछली बार के तरीके इस प्रकार हैं:

1. हम केवल आवश्यक क्षेत्रों का अनुरोध करते हैं
   me? फ़ील्ड = आईडी, नाम, जन्मदिन
2. हम एक अनुरोध में कई वस्तुओं के डेटा का अनुरोध करते हैं
   ? आईडी = 4,501012028
3. हम फ़िल्टरिंग और पेजिंग का उपयोग करते हैं
   मुझे / दोस्तों? सीमा = 10 और ऑफसेट = 10
4. FQL क्वेरी का उपयोग करना
   fql; q = uid, नाम, जन्मदिन_से उपयोगकर्ता से चयन करें, जहां से uid IN (मित्र से चयन uid2 करें) कहां uid1 = me ()
5. हम कई अनुरोधों के साथ एक बैच अनुरोध भेजते हैं
   बैच = [{"विधि": "GET", "रिश्तेदार_url": "me"}, {"पद्धति": "GET", "रिश्तेदार_url": "मुझे / मित्र? सीमा = 50"}]

सभी प्रश्नों को ग्राफ एपीआई एक्सप्लोरर में निष्पादित किया जा सकता है, जो अब FQL प्रश्नों का समर्थन करता है।

1) बहु-क्वेरी

बहु-क्वेरी कई FQL प्रश्न हैं जो एक एकल ग्राफ़ एपीआई क्वेरी में भेजे गए हैं। बैच अनुरोध के माध्यम से भेजे गए FQL प्रश्नों के समान पैक की तुलना में मल्टी-क्वेरीज़ को तेज़ी से संसाधित किया जाता है। इसी समय, वे न केवल कई वस्तुओं पर उत्तर पास कर सकते हैं, बल्कि सरल FQL प्रश्नों की समस्याओं में से एक को हल कर सकते हैं।

मान लीजिए कि आप उन उपयोगकर्ताओं की एक सूची प्राप्त करना चाहते हैं जो किसी विशेष कार्यक्रम में भाग लेने जा रहे हैं। आप एक FQL प्रश्न लिखते हैं:
सेलेक्ट नेम, url, pic FROM प्रोफाइल व्हेयर आईडी IN (Select uid FROM event_member WHERE eid = 12345678)

लेकिन इस तरह का अनुरोध आपको सभी उपयोगकर्ताओं को स्थिति की जानकारी दिए बिना (उपस्थित, अनिश्चित, अस्वीकृत, सूचित नहीं किया गया) प्रदान करता है। सभी अच्छी तरह से है यदि आपको केवल उन लोगों को जानकारी प्रदर्शित करने की आवश्यकता है जो घटना में शामिल होते हैं। फिर आप बस और उप- स्थिति की स्थिति में rsvp_status = 'भाग' जोड़ते हैं। लेकिन आपको क्या करना चाहिए अगर आपको एक पृष्ठ पर सभी उपयोगकर्ताओं को प्रदर्शित करने की आवश्यकता है, उन्हें आरएसवीपी स्थिति से तोड़कर। क्या 4 FQL प्रश्न विभिन्न स्थितियों के साथ हैं और उन्हें बैच का उपयोग करके भेजते हैं?

फेसबुक आपको दो अनुरोध करने और दूसरे में एक के डेटा का उपयोग करने की पेशकश करता है। हमारे उदाहरण के लिए, प्रश्न इस प्रकार होंगे:
"Query1": "SELID uid, rsvp_status FROM event_member को यहां से ईद = 12345678"
"Query2": "नाम का चयन करें, url, प्रोफ़ाइल से चित्र चुनें जहां पर आईडी है (# क्वेरी से चयन करें)"
अब एक अनुरोध के लिए आपको सभी आवश्यक डेटा प्राप्त होंगे, और यह बैच के माध्यम से तेजी से होगा।

आप दस्तावेज़ में बहु-क्वेरी के बारे में अधिक जानकारी प्राप्त कर सकते हैं।

2) बैच अनुरोध कई तरीकों और संचालन के बीच निर्भरता से युक्त

अब एक बैच रिक्वेस्ट में आप विभिन्न HTTP मेथड पास कर सकते हैं: GET, POST, DELETE। उदाहरण के लिए, एक नई स्थिति प्रकाशित करें और एक अनुरोध में उपयोगकर्ता का फ़ीड वापस करें। लेकिन बन्स इस में नहीं हैं, लेकिन "निर्भरता" में हैं।

प्रारंभ में, अनुरोध स्वतंत्र थे। लेकिन अब आप JSONPath अभिव्यक्तियों का उपयोग करते हुए निर्भरता को प्रबंधित करते हुए एक क्वेरी से दूसरे में डेटा का उपयोग कर सकते हैं।

सबसे सरल उदाहरण: 5 दोस्तों का डेटा प्राप्त करें। यह इस क्वेरी का उपयोग करके किया जा सकता है:
बैच = [{"विधि": "GET", "नाम": "get-friends", "रिश्तेदार_url": "me / friends? limit = 5",}, {"method": "GET", "रिश्तेदार_url"? : "; ids = {result = get-friends: $ data। *। id}"}}]

इसे रोको! तो हम ऐसा बहु-क्वेरी की मदद से कर सकते हैं। हां, सभी शक्ति दिखाने के लिए एक और उदाहरण चुना जाना चाहिए। और आपको यह कैसे पसंद है:
बैच = [{"विधि": "GET", "नाम": "एक-मित्र", "रिश्तेदार_उर्ल": "मुझे / दोस्त? सीमा = 1",}, {"विधि": "POST", "रिश्तेदार_हूर्ल"? : "मुझे / फ़ीड", "शरीर": "संदेश = {परिणाम = एक-मित्र: $। Data.0.name} मेरा मित्र है}]]
हम एक उपयोगकर्ता के दोस्तों को प्राप्त करते हैं और एक नई पोस्ट प्रकाशित करने के लिए उसके डेटा का उपयोग करते हैं। दो अलग-अलग प्रश्नों की आवश्यकता नहीं है।

आप बैच में 50 अनुरोधों का उपयोग कर सकते हैं, omit_response_on_success और depend_on मापदंडों का उपयोग करके अनुरोधों के व्यवहार को नियंत्रित कर सकते हैं, और विभिन्न अनुरोधों में विभिन्न access_token (उपयोगकर्ता, पृष्ठ, एप्लिकेशन) का उपयोग भी कर सकते हैं। बैच अनुरोध प्रलेखन।

3) ETags

वर्ष की शुरुआत में, फेसबुक ने HTTP ETags का समर्थन किया। उनके काम का सिद्धांत सरल है:

1. जब आप ग्राफ़ एपीआई अनुरोध को निष्पादित करते हैं, तो प्रतिक्रिया ईटीएजी हेडर को उस मान के साथ लौटाएगी जो एपीआई के माध्यम से लौटाए गए डेटा का हैश है।
2. अगली बार जब आप एक ही अनुरोध करते हैं, तो चरण 1 से प्राप्त डेटा के साथ इफ-नो-मैच हेडर पास करें।
3. यदि डेटा नहीं बदला है, तो आपको प्रतिक्रिया में डेटा के बिना 304 - संशोधित नहीं मिलेगा।
4. यदि डेटा बदल गया है, तो डेटा हमेशा की तरह वापस आ जाता है (बिंदु 1)।

यह उन डेटा के साथ उपयोग करने के लिए सलाह दी जाती है जो अक्सर बदलते नहीं हैं। उदाहरण के लिए, फीड या पोस्ट अनुरोध में ETags का उपयोग न करें। लेकिन धीमे कनेक्शन पर मोबाइल एप्लिकेशन में मित्र अनुरोधों के लिए, प्रदर्शन में निश्चित रूप से सुधार होगा।

आप डेवलपर ब्लॉग पर इस पोस्ट में ETags के साथ-साथ नमूना कोड के बारे में अधिक पढ़ सकते हैं।

4) क्षेत्र का विस्तार

ऊपर, मैंने पहले ही दो तरीकों का वर्णन किया है कि JSONPath के साथ मल्टी-क्वेरी और बैच का उपयोग करके एक क्वेरी में संबंधित ऑब्जेक्ट से डेटा कैसे प्राप्त किया जाए। लेकिन अनुरोधों के ग्राफ एपीआई के लिए एक सरल विकल्प है।

उदाहरण के लिए, हम पृष्ठ पर उपयोगकर्ता का नाम, उसका जन्मदिन और अंतिम 10 तस्वीरें प्रदर्शित करना चाहते हैं। हम इस क्वेरी की सहायता से यह सब कर सकते हैं:
मुझे? फ़ील्ड = नाम, जन्मदिन, फ़ोटो। बिलिट (10)। फ़ील्ड (आईडी, चित्र)

या हम फोटो पर टिप्पणियां प्रदर्शित करना चाहते हैं, लेकिन मानक क्षेत्र हमारे लिए पर्याप्त नहीं हैं, और हम एक और टिप्पणीकारों के जन्मदिन को जोड़ना चाहते हैं। अनुरोध इस प्रकार है:
<photo_id> /comments?fields=from.fields(id, नाम, जन्मदिन)

आप सभी पहचानकर्ताओं, क्षेत्रों और कनेक्शन के लिए इस तरह के अनुरोध कर सकते हैं। क्या यह बहुत आसान और अधिक सुविधाजनक नहीं है? क्षेत्र विस्तार प्रलेखन।

५) पेजिनेशन

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

फेसबुक एक नया समाधान प्रदान करता है: कर्सर-आधारित ऑफसेट पेजिंग। अधिक डेटा न होने पर आपको अब पिछला और अगला नहीं दिखाया जाएगा। यदि कोई पिछला / अगला पृष्ठ है, तो अनुरोध में लिंक के पहले / बाद में प्रदर्शित किया जाएगा। आप वस्तुओं के प्रत्येक संग्रह को देखकर "एक पास" बचाते हैं।

दुर्भाग्य से, कर्सर-आधारित पेजिनेशन अभी तक सभी वस्तुओं के लिए उपलब्ध नहीं है। लेकिन यह समय की बात है। प्रलेखन का पालन करें और अधिक प्रभावी समाधान का उपयोग करें।

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

अंत में, मैं आपको याद दिलाना चाहूंगा कि 1 अक्टूबर को, मास्को फेसबुक डेवलपर HACK 2012 की मेजबानी करेगा। यदि आप व्यक्तिगत रूप से उपस्थित नहीं हो सकते हैं, तो अपने प्रश्नों को टिप्पणियों में छोड़ दें। व्यक्तिगत रूप से, मैंने फेसबुक इंजीनियरों के लिए पर्याप्त प्रश्न संचित किए हैं।