एक ही बार में कई हैश सूचियां मिलती हैं.
ऐसा अक्सर होता है, जब किसी क्लाइंट को एक से ज़्यादा हैश की गई सूचियों की ज़रूरत होती है. इस तरीके का इस्तेमाल, सामान्य Get तरीके को कई बार इस्तेमाल करने के मुकाबले बेहतर होता है.
यह https://google.aip.dev/231 में बताए गए स्टैंडर्ड बैच Get तरीके के मुताबिक है. साथ ही, एचटीटीपी तरीका भी GET है.
एचटीटीपी अनुरोध
GET https://safebrowsing.googleapis.com/v5alpha1/hashLists:batchGet
यह यूआरएल, gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल करता है.
क्वेरी पैरामीटर
| पैरामीटर | |
|---|---|
names[] |
ज़रूरी है. खास हैश सूचियों के नाम. यह सूची, थ्रेट लिस्ट या ग्लोबल कैश हो सकती है. नामों में डुप्लीकेट शामिल नहीं होने चाहिए. ऐसा होने पर, क्लाइंट को गड़बड़ी का मैसेज मिलेगा. |
version[] |
हैश की गई सूची के वे वर्शन जो क्लाइंट के पास पहले से मौजूद हैं. अगर क्लाइंट पहली बार हैश की गई सूचियां फ़ेच कर रहा है, तो इस फ़ील्ड को खाली छोड़ दिया जाना चाहिए. अगर ऐसा नहीं है, तो क्लाइंट को सर्वर से पहले मिले वर्शन देने चाहिए. क्लाइंट को उन बाइट में बदलाव नहीं करना चाहिए. क्लाइंट को वर्शन, सूची के नामों के क्रम में भेजने की ज़रूरत नहीं है. ऐसा हो सकता है कि क्लाइंट, अनुरोध में नामों की संख्या से कम या ज़्यादा वर्शन भेजे. हालांकि, क्लाइंट को एक ही नाम से जुड़े कई वर्शन नहीं भेजने चाहिए. ऐसा करने पर, क्लाइंट को गड़बड़ी का मैसेज मिलेगा. पुरानी जानकारी: एपीआई के V4 में, इसे base64 कोड में बदली गई स्ट्रिंग. |
sizeConstraints |
हर सूची के साइज़ से जुड़ी पाबंदियां. अगर इसे शामिल नहीं किया जाता है, तो कोई शर्त नहीं होती. ध्यान दें कि यहां दिए गए साइज़, हर सूची के हिसाब से हैं. इन्हें सभी सूचियों के हिसाब से एग्रीगेट नहीं किया गया है. |
अनुरोध का मुख्य भाग
अनुरोध का मुख्य हिस्सा खाली होना चाहिए.
जवाब का मुख्य भाग
जवाब में एक से ज़्यादा हैश सूचियां शामिल हैं.
अगर एपीआई सही से जुड़ जाता है, ताे जवाब के मुख्य भाग में नीचे दिए गए स्ट्रक्चर शामिल होता है.
| JSON फ़ॉर्मैट में दिखाया गया है |
|---|
{
"hashLists": [
{
object ( |
| फ़ील्ड | |
|---|---|
hashLists[] |
हैश की गई सूचियां, अनुरोध में दिए गए क्रम में होती हैं. |