ComputeRoutes() तरीके को कॉल करते समय, आपको यह बताना होगा कि आपको कौनसे फ़ील्ड
मैं जवाब में लौटाना चाहता हूं. ऐसा रिस्पॉन्स फ़ील्ड मास्क का इस्तेमाल करके किया जाता है, जो
आप URL पैरामीटर $fields या fields के साथ या
एचटीटीपी/gRPC हेडर X-Goog-FieldMask. ज़्यादा जानकारी के लिए, यह देखें
सिस्टम पैरामीटर.
फ़ील्ड मास्क
फ़ील्ड मास्क की वैल्यू, फ़ील्ड पाथ की कॉमा-सेपरेटेड लिस्ट होती है. हर फ़ील्ड पाथ मैसेज की हैरारकी को दिखाने वाले फ़ील्ड के नाम की सूची, डॉट से अलग की गई होती है. ऐप्लिकेशन फ़ील्ड का नाम, JSON ऑब्जेक्ट कुंजी या प्रोटोबफ़ फ़ील्ड टैग का नाम होता है. कॉन्टेंट बनाने फ़ील्ड पाथ, टॉप लेवल रिस्पॉन्स मैसेज टाइप से शुरू होता है. हालांकि, यह ज़रूरी नहीं है उसके बाद एक या ज़्यादा बिंदु और फिर फ़ील्ड के नाम का अगला लेवल. सामान्य तौर पर, फ़ील्ड पाथ इस तरह बनाए जाते हैं:
topLevelField[.secondLevelField][.thirdLevelField][...]
खास केस फ़ील्ड मास्क, एक वाइल्डकार्ड “*” होता है, जो सभी रूट-लेवल को चुनता है फ़ील्ड.
उदाहरण
नीचे दिए गए उदाहरण में,
ComputeRoutes() तरीका.
उदाहरण 1
सभी उपलब्ध फ़ील्ड का फ़ील्ड मास्क (मैन्युअल जांच के लिए).
X-Goog-FieldMask: *
उदाहरण 2
रूट-लेवल की अवधि, दूरी, और पॉलीलाइन का फ़ील्ड मास्क (प्रोडक्शन सेटअप का उदाहरण).
X-Goog-FieldMask: routes.duration,routes.distanceMeters,routes.polyline
हम वाइल्डकार्ड (*) रिस्पॉन्स फ़ील्ड मास्क का इस्तेमाल करने या यह तय करने की सलाह नहीं देते हैं कि का इस्तेमाल किया जा सकता है. सिर्फ़ इन फ़ील्ड में अपनी ज़रूरत के हिसाब से बदलाव करें:
हमारे सर्वर को प्रोसेसिंग साइकल सेव करने की अनुमति देता है, ताकि हम आपके तो इंतज़ार का समय कम हो जाता है.
यह पक्का करता है कि इंतज़ार के समय की परफ़ॉर्मेंस अच्छी रहे. हम होगा, और उन नए फ़ील्ड को कैलकुलेट करने में ज़्यादा समय लग सकता है. अगर आपको या अगर टॉप लेवल पर सभी फ़ील्ड को चुना जाता है, तो आपको परफ़ॉर्मेंस में गिरावट इसलिए आएगी, क्योंकि हम जो भी नया फ़ील्ड जोड़ेंगे वह अपने-आप इसे आपके जवाब में शामिल किया गया था.
रिस्पॉन्स का साइज़ छोटा होता है. इसलिए, जवाब के तौर पर ज़्यादा नेटवर्क मिलता है प्रवाह क्षमता.
फ़ील्ड पाथ बनाने के बारे में ज़्यादा जानने के लिए, यहां जाएं: field_mask.proto.