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

Discovery API का इस्तेमाल करना

यह दस्तावेज़ उन डेवलपर के लिए है जो Google API के साथ इंटरैक्ट करने के लिए, क्लाइंट लाइब्रेरी, IDE प्लगिन, और अन्य टूल लिखना चाहते हैं. Google APIs Discovery Service की मदद से, ऊपर दिए गए सभी काम किए जा सकते हैं. इसके लिए, यह सेवा एक आसान एपीआई के ज़रिए, Google के अन्य एपीआई के बारे में मशीन से पढ़े जा सकने वाले मेटाडेटा को उपलब्ध कराती है. इस गाइड में, डिस्कवरी दस्तावेज़ के हर सेक्शन के बारे में खास जानकारी दी गई है. साथ ही, दस्तावेज़ का इस्तेमाल करने के बारे में काम के सुझाव भी दिए गए हैं.

एपीआई को किए गए सभी कॉल, बिना पुष्टि वाले JSON पर आधारित REST अनुरोध होते हैं. इनमें एसएसएल का इस्तेमाल किया जाता है. दूसरे शब्दों में कहें, तो यूआरएल https से शुरू होते हैं.

खोज से जुड़े दस्तावेज़ का फ़ॉर्मैट

इस सेक्शन में, डिस्कवरी दस्तावेज़ के बारे में खास जानकारी दी गई है.

यहां दिए गए सभी उदाहरणों में, Service Usage API से मिले खोज से जुड़े दस्तावेज़ का इस्तेमाल किया गया है. इस GET अनुरोध को पूरा करके, Service Usage API के लिए खोज से जुड़ा दस्तावेज़ लोड किया जा सकता है:

GET https://serviceusage.googleapis.com/$discovery/rest?version=v1

डिस्कवरी दस्तावेज़ के फ़ॉर्मैट में, छह मुख्य कैटगरी में आने वाली जानकारी शामिल होती है:

एपीआई के बारे में सामान्य जानकारी.
एपीआई के लिए, पहचान की पुष्टि करने की जानकारी.
एपीआई के डेटा के बारे में बताने वाली संसाधन और स्कीमा की जानकारी.
एपीआई के तरीकों के बारे में जानकारी.
एपीआई के साथ काम करने वाली किसी भी कस्टम सुविधा के बारे में जानकारी.
इनलाइन दस्तावेज़, जिसमें एपीआई के मुख्य एलिमेंट के बारे में बताया गया है.

डिस्कवरी दस्तावेज़ के इन सेक्शन के बारे में यहां बताया गया है.

एपीआई के बारे में बुनियादी जानकारी

डिस्कवरी दस्तावेज़ में, एपीआई के हिसाब से प्रॉपर्टी का एक सेट होता है. ये प्रॉपर्टी, इस क्रम में या डिस्कवरी दस्तावेज़ के एक ही सेक्शन में दिखें, यह ज़रूरी नहीं है:

"id": "serviceusage:v1",
"canonicalName": "Service Usage",
"revision": "20240331",
"servicePath": "",
"baseUrl": "https://serviceusage.googleapis.com/",
"kind": "discovery#restDescription",
"description": "Enables services that service consumers want to use on Google Cloud Platform, lists the available or enabled services, or disables services that service consumers no longer use.",
"ownerDomain": "google.com",
"version_module": true,
"version": "v1",
"fullyEncodeReservedExpansion": true,
"name": "serviceusage",
"title": "Service Usage API",
"discoveryVersion": "v1",
"rootUrl": "https://serviceusage.googleapis.com/",
"protocol": "rest"

एपीआई लेवल की इन प्रॉपर्टी में, एपीआई के किसी वर्शन के बारे में जानकारी शामिल होती है. जैसे, name, version, title, और description. protocol की वैल्यू हमेशा rest होती है, क्योंकि APIs Discovery Service सिर्फ़ एपीआई को ऐक्सेस करने के RESTful तरीकों के साथ काम करती है.

servicePath फ़ील्ड, इस एपीआई वर्शन के लिए पाथ प्रीफ़िक्स दिखाता है.

पुष्टि करना

auth सेक्शन में, एपीआई के लिए OAuth 2.0 ऑथराइज़ेशन स्कोप के बारे में जानकारी होती है. OAuth 2.0 के साथ स्कोप इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, Google API को ऐक्सेस करने के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

auth सेक्शन में, नेस्ट किया गया oauth2 और scopes सेक्शन शामिल है. scopes सेक्शन, स्कोप वैल्यू से स्कोप के बारे में ज़्यादा जानकारी देने वाली की/वैल्यू मैपिंग है:

"auth": {
  "oauth2": {
    "scopes": {
      "https://www.googleapis.com/auth/cloud-platform": {
        "description": "See, edit, configure, and delete your Google Cloud data and see the email address for your Google Account."
      },
      "https://www.googleapis.com/auth/cloud-platform.read-only": {
        "description": "View your data across Google Cloud services and see the email address of your Google Account"
      },
      "https://www.googleapis.com/auth/service.management": {
        "description": "Manage your Google API service configuration"
      }
    }
  }
}

auth सेक्शन में, सिर्फ़ किसी एपीआई के स्कोप तय किए जाते हैं. ये स्कोप किसी एपीआई तरीके से कैसे जुड़े होते हैं, यह जानने के लिए यहां दिया गया तरीके सेक्शन देखें.

संसाधन और स्कीमा

किसी एपीआई की कार्रवाइयां, resources कहे जाने वाले डेटा ऑब्जेक्ट पर काम करती हैं. डिस्कवरी दस्तावेज़, संसाधनों के कॉन्सेप्ट पर आधारित होता है. हर डिस्कवरी दस्तावेज़ में सबसे ऊपर के लेवल का resources सेक्शन होता है. इसमें एपीआई से जुड़े सभी संसाधनों को ग्रुप किया जाता है. उदाहरण के लिए, Service Usage API में services संसाधन और टॉप-लेवल resources के तहत operations संसाधन होता है:

"resources": {
  "services": {
    // Methods associated with the services resource
  }
  "operations": {
    // Methods associated with the operations resource
  }
}

हर संसाधन सेक्शन में, उस संसाधन से जुड़े तरीके होते हैं. उदाहरण के लिए, Service Usage API में services संसाधन से जुड़े छह तरीके हैं: get, enable, disable, batchGet, batchEnable, और list.

स्कीमा से पता चलता है कि एपीआई में मौजूद संसाधन कैसे दिखते हैं. हर डिस्कवरी दस्तावेज़ में सबसे ऊपर के लेवल का schemas सेक्शन होता है. इसमें स्कीमा आईडी से ऑब्जेक्ट तक का नाम/वैल्यू पेयर होता है. स्कीमा आईडी, हर एपीआई के लिए यूनीक होते हैं. इनका इस्तेमाल, डिस्कवरी दस्तावेज़ के methods सेक्शन में स्कीमा की पहचान करने के लिए किया जाता है. उदाहरण के लिए, यहां Service Usage API के डिस्कवरी दस्तावेज़ में मौजूद कुछ स्कीमा दिए गए हैं:

"schemas": {
  "Method": {
    // JSON schema of the Method resource
  },
  "Authentication": {
    // JSON schema of the Authentication resource
  },
  "RubySettings": {
    // JSON schema of the RubySettings resource
  },
  "EnableServiceResponse": {
   // JSON schema of the EnableServiceResponse resource
  }
}

एपीआई डिस्कवरी सेवा, स्कीमा दिखाने के लिए JSON Schema draft-03 का इस्तेमाल करती है. यहां EnableServiceResponse रिसॉर्स के लिए JSON स्कीमा का स्निपेट दिया गया है. साथ ही, GoogleApiServiceusagev1Service का भी स्निपेट दिया गया है. इन स्कीमा के साथ-साथ, Pub/Sub API (pubsub.googleapis.com) को चालू करने के अनुरोध के लिए, असल जवाब का एक हिस्सा भी दिया गया है.

EnableServiceResponse संसाधन का JSON स्कीमा: किसी सेवा को चालू करने के लिए मिला जवाब:

"EnableServiceResponse": {
  "id": "EnableServiceResponse",
  "description": "Response message for the `EnableService` method. This response message is assigned to the `response` field of the returned Operation when that operation is done.",
  "properties": {
    "service": {
      "description": "The new state of the service after enabling.",
      "$ref": "GoogleApiServiceusageV1Service"
    }
  },
  "type": "object"
},
"GoogleApiServiceusageV1Service": {
  "description": "A service that is available for use by the consumer.",
  "properties": {
    "config": {
      "$ref": "GoogleApiServiceusageV1ServiceConfig",
      "description": "The service configuration of the available service. Some fields may be filtered out of the configuration in responses to the `ListServices` method. These fields are present only in responses to the `GetService` method."
    },
    "name": {
      "type": "string",
      "description": "The resource name of the consumer and service. A valid name would be: - projects/123/services/serviceusage.googleapis.com"
    },
    "state": {
      "enumDescriptions": [
        "The default value, which indicates that the enabled state of the service is unspecified or not meaningful. Currently, all consumers other than projects (such as folders and organizations) are always in this state.",
        "The service cannot be used by this consumer. It has either been explicitly disabled, or has never been enabled.",
        "The service has been explicitly enabled for use by this consumer."
      ],
      "description": "Whether or not the service has been enabled for use by the consumer.",
      "type": "string",
      "enum": [
        "STATE_UNSPECIFIED",
        "DISABLED",
        "ENABLED"
      ]
    },
    "parent": {
      "type": "string",
      "description": "The resource name of the consumer. A valid name would be: - projects/123"
    }
  },
  "id": "GoogleApiServiceusageV1Service",
  "type": "object"
}

"response": {
  "@type": "type.googleapis.com/google.api.serviceusage.v1.EnableServiceResponse",
  "service": {
    "name": "projects/232342569935/services/pubsub.googleapis.com",
    "config": {
      "name": "pubsub.googleapis.com",
      "title": "Cloud Pub/Sub API",
      "documentation": {
        "summary": "Provides reliable, many-to-many, asynchronous messaging between applications.\n"
      },
      "quota": {},
      "authentication": {},
      "usage": {
        "requirements": [
          "serviceusage.googleapis.com/tos/cloud"
        ]
      },
      "monitoring": {}
    },
    "state": "ENABLED",
    "parent": "projects/232342569935"
  }
}

बोल्ड किए गए फ़ील्ड, JSON स्कीमा और असल जवाब के बीच मैपिंग दिखाते हैं.

इस उदाहरण में दिखाया गया है कि स्कीमा में, अन्य स्कीमा के रेफ़रंस शामिल हो सकते हैं. अगर आपको क्लाइंट लाइब्रेरी बनानी है, तो इससे आपको अपनी डेटा मॉडल क्लास में एपीआई के ऑब्जेक्ट को असरदार तरीके से मॉडल करने में मदद मिल सकती है. ऊपर दिए गए EnableServiceResponse उदाहरण में, service प्रॉपर्टी, आईडी GoogleApiServiceusageV1Service वाले स्कीमा का रेफ़रंस है. यह Service Usage API के डिस्कवरी दस्तावेज़ में मौजूद एक और स्कीमा है. EnableServiceResponse संसाधन में मौजूद GoogleApiServiceusageV1Service प्रॉपर्टी की जगह, GoogleApiServiceusageV1Service स्कीमा की वैल्यू का इस्तेमाल किया जा सकता है. ध्यान दें कि $ref सिंटैक्स, JSON स्कीमा स्पेसिफ़िकेशन से लिया गया है.

मेथड, अनुरोध और जवाब के मुख्य हिस्से के बारे में बताते समय स्कीमा का भी रेफ़रंस दे सकते हैं. ज़्यादा जानकारी के लिए, तरीके सेक्शन देखें.

तरीके

खोज से जुड़े दस्तावेज़ का मुख्य हिस्सा, तरीकों के बारे में जानकारी देता है. तरीके, एपीआई पर की जा सकने वाली कार्रवाइयां होती हैं. आपको डिस्कवरी दस्तावेज़ के अलग-अलग हिस्सों में methods सेक्शन दिखेगा. यह टॉप लेवल (जिसे हम एपीआई-लेवल के तरीके कहते हैं) या resources लेवल पर भी दिख सकता है.

"methods": {
  // API-level methods
}
"resources": {
  "resource1": {
    "methods": {
      // resource-level methods
    }
    "resources": {
      "nestedResource": {
        "methods": {
          // methods can even be found in nested-resources
        }
      }
    }
  }
}

एपीआई में एपीआई लेवल के तरीके हो सकते हैं, लेकिन संसाधन में methods सेक्शन ज़रूर होना चाहिए.

हर methods सेक्शन, तरीके के नाम से लेकर उस तरीके के बारे में अन्य जानकारी तक का कुंजी-वैल्यू मैप होता है. यहां दिए गए उदाहरण में, तीन तरीकों के बारे में बताया गया है: get, enable, और disable:

"methods": {
  "get": { //details about the "get" method },
  "enable": { //details about the "enable" method },
  "disable": { //details about the "disable" method }
}

आखिर में, हर तरीके के सेक्शन में उस तरीके के बारे में अलग-अलग प्रॉपर्टी की जानकारी दी गई है. यहां enable तरीके का एक उदाहरण दिया गया है:

"enable": {
  "path": "v1/{+name}:enable",
  "request": {
    "$ref": "EnableServiceRequest"
  },
  "parameterOrder": [
    "name"
  ],
  "id": "serviceusage.services.enable",
  "response": {
    "$ref": "Operation"
  },
  "description": "Enable a service so that it can be used with a project.",
  "httpMethod": "POST",
  "flatPath": "v1/{v1Id}/{v1Id1}/services/{servicesId}:enable",
  "scopes": [
    "https://www.googleapis.com/auth/cloud-platform",
    "https://www.googleapis.com/auth/service.management"
  ],
  "parameters": {
    "name": {
      "location": "path",
      "description": "Name of the consumer and service to enable the service on. The `EnableService` and `DisableService` methods currently only support projects. Enabling a service requires that the service is public or is shared with the user enabling the service. An example name would be: `projects/123/services/serviceusage.googleapis.com` where `123` is the project number.",
      "required": true,
      "type": "string",
      "pattern": "^[^/]+/[^/]+/services/[^/]+$"
    }
  }
},

इस सेक्शन में, सामान्य तरीके की जानकारी दी गई है. जैसे, तरीके की पहचान करने के लिए यूनीक ID, इस्तेमाल किया जाने वाला httpMethod, और तरीके का path. तरीके के पूरे यूआरएल का हिसाब लगाने के लिए, path प्रॉपर्टी का इस्तेमाल करने के बारे में जानने के लिए, अनुरोध लिखें सेक्शन देखें. तरीके की इन सामान्य प्रॉपर्टी के अलावा, कुछ ऐसी प्रॉपर्टी भी होती हैं जो तरीके को डिस्कवरी दस्तावेज़ के अन्य सेक्शन से जोड़ती हैं:

स्कोप

इस दस्तावेज़ में पहले बताए गए auth सेक्शन में, किसी एपीआई के साथ काम करने वाले सभी स्कोप के बारे में जानकारी होती है. अगर कोई तरीका इनमें से किसी एक स्कोप के साथ काम करता है, तो उसमें स्कोप का एक कलेक्शन होगा. इस कलेक्शन में, तरीके के साथ काम करने वाले हर स्कोप के लिए एक एंट्री होती है.

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

अनुरोध और जवाब

अगर तरीके में अनुरोध या जवाब का मुख्य हिस्सा है, तो इन्हें क्रमशः request या response सेक्शन में शामिल किया जाता है. उदाहरण के लिए, enable तरीके के लिए, request सेक्शन के कॉन्टेंट से पता चलता है कि इस तरीके का अनुरोध, EnableServiceRequest आईडी वाले JSON स्कीमा से तय होता है. यह स्कीमा, टॉप-लेवल स्कीमा सेक्शन में देखा जा सकता है.

पैरामीटर

अगर किसी तरीके में ऐसे पैरामीटर हैं जिन्हें उपयोगकर्ता को तय करना चाहिए, तो इन पैरामीटर के बारे में तरीके के लेवल के parameters सेक्शन में बताया गया है. इस सेक्शन में, पैरामीटर के नाम की कुंजी/वैल्यू मैपिंग होती है. इससे उस पैरामीटर के बारे में ज़्यादा जानकारी मिलती है.

उदाहरण के लिए, enable तरीके के लिए एक पैरामीटर है: name. पैरामीटर, path या यूआरएल query में जा सकते हैं. location प्रॉपर्टी से पता चलता है कि क्लाइंट लाइब्रेरी को पैरामीटर कहां रखना चाहिए.

पैरामीटर के बारे में बताने वाली कई अन्य प्रॉपर्टी भी होती हैं. इनमें पैरामीटर डेटा type (टाइप की जानकारी देने वाली भाषाओं के लिए काम का है), पैरामीटर required है या नहीं, और पैरामीटर एक एनम है या नहीं, शामिल हैं. इन प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, इस एपीआई के लिए रेफ़रंस दस्तावेज़ देखें.

पैरामीटर का क्रम

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

मीडिया अपलोड करना

अगर किसी तरीके से इमेज, ऑडियो या वीडियो जैसे मीडिया को अपलोड किया जा सकता है, तो उस मीडिया को अपलोड करने के लिए इस्तेमाल की जा सकने वाली जगह और प्रोटोकॉल की जानकारी, mediaUpload सेक्शन में दी गई है. इस सेक्शन में, यह जानकारी दी गई है कि कौनसे अपलोड प्रोटोकॉल काम करते हैं. साथ ही, इसमें यह भी बताया गया है कि किस तरह का मीडिया अपलोड किया जा सकता है.

enable तरीके में mediaUpload सेक्शन शामिल नहीं है. हालांकि, mediaUpload सेक्शन आम तौर पर ऐसा दिखता है:

"supportsMediaUpload": true,
"mediaUpload": {
  "accept": [
    "image/*"
  ],
  "maxSize": "10MB",
  "protocols": {
    "simple": {
      "multipart": true,
      "path": "/upload/storage/v1beta1/b/{bucket}/o"
    },
    "resumable": {
      "multipart": true,
      "path": "/resumable/upload/storage/v1beta1/b/{bucket}/o"
    }
  }
}

ऊपर दिए गए उदाहरण में, supportsMediaUpload प्रॉपर्टी एक बूलियन वैल्यू है. इससे यह तय होता है कि यह तरीका मीडिया अपलोड करने की सुविधा के साथ काम करता है या नहीं. अगर वैल्यू सही है, तो mediaUpload सेक्शन में, अपलोड किए जा सकने वाले मीडिया के टाइप के बारे में बताया गया है.

accept प्रॉपर्टी, मीडिया-रेंज की एक सूची होती है. इससे यह तय होता है कि अपलोड करने के लिए, कौनसे माइम-टाइप स्वीकार किए जा सकते हैं. ऊपर दिए गए उदाहरण में दिखाया गया एंडपॉइंट, किसी भी इमेज फ़ॉर्मैट को स्वीकार करेगा.

maxSize प्रॉपर्टी के लिए, अपलोड की जाने वाली फ़ाइल का साइज़ सबसे ज़्यादा होता है. वैल्यू, MB, GB या TB की यूनिट में एक स्ट्रिंग होती है. ऊपर दिए गए उदाहरण में, अपलोड किए जाने वाले डेटा का साइज़ ज़्यादा से ज़्यादा 10 एमबी तक सीमित है. ध्यान दें कि यह वैल्यू, किसी एपीआई के लिए किसी उपयोगकर्ता के बचे हुए स्टोरेज कोटे को नहीं दिखाती. इसलिए, भले ही अपलोड का साइज़ maxSize से कम हो, क्लाइंट लाइब्रेरी को अब भी ऐसे अपलोड को हैंडल करने के लिए तैयार रहना चाहिए जो जगह कम होने की वजह से पूरा नहीं हो पाता.

protocols सेक्शन में, अपलोड करने के उन प्रोटोकॉल की सूची दी गई है जिन्हें इस्तेमाल किया जा सकता है. simple प्रोटोकॉल, दिए गए एंडपॉइंट पर मीडिया को सिर्फ़ एक एचटीटीपी अनुरोध में पोस्ट करता है. resumable प्रोटोकॉल का मतलब है कि resumable यूआरआई में दिया गया एंडपॉइंट, फिर से शुरू किए जा सकने वाले अपलोड प्रोटोकॉल के साथ काम करता है.path अगर multipart प्रॉपर्टी true है, तो इसका मतलब है कि एंडपॉइंट, मल्टीपार्ट अपलोड स्वीकार करता है. इसका मतलब है कि JSON अनुरोध और मीडिया, दोनों को mutlipart/related बॉडी में एक साथ रैप करके भेजा जा सकता है. ध्यान दें कि simple और resumable, दोनों प्रोटोकॉल मल्टीपार्ट अपलोड के साथ काम कर सकते हैं.

path प्रॉपर्टी एक यूआरआई टेंप्लेट है. इसे ठीक उसी तरह से बड़ा किया जाना चाहिए जिस तरह से अनुरोध लिखें सेक्शन में बताए गए तरीके के लिए path प्रॉपर्टी को बड़ा किया जाता है.

मीडिया डाउनलोड करना

अगर कोई तरीका, इमेज, ऑडियो या वीडियो जैसे मीडिया को डाउनलोड करने की सुविधा देता है, तो उसे supportsMediaDownload पैरामीटर से दिखाया जाता है:

"supportsMediaDownload": true,

मीडिया डाउनलोड करते समय, आपको अनुरोध यूआरएल में alt क्वेरी पैरामीटर को media पर सेट करना होगा.

अगर एपीआई के तरीके की useMediaDownloadService प्रॉपर्टी true है, तो रीडायरेक्ट से बचने के लिए servicePath से पहले /download डालें. उदाहरण के लिए, अगर servicePath और path को जोड़ने पर /youtube/v3/captions/{id} मिलता है, तो डाउनलोड पाथ /download/youtube/v3/captions/{id} होगा. हमारा सुझाव है कि useMediaDownloadService की वैल्यू false होने पर भी, मीडिया डाउनलोड करने का यूआरएल /download की मदद से बनाया जाए.

ध्यान दें: एक एपीआई तरीके से, मीडिया को डाउनलोड और अपलोड, दोनों किया जा सकता है. मीडिया को अपलोड और डाउनलोड करने के लिए, अनुरोध किए गए यूआरएल को बनाने का लॉजिक अलग-अलग काम करता है. साथ ही, यह एक-दूसरे में दखल नहीं देता. इस वजह से, इस तरह के एपीआई तरीके में मीडिया डाउनलोड करने के लिए एक /download/... यूआरएल और मीडिया अपलोड करने के लिए एक /upload/... यूआरएल होगा. हालांकि, एक ही अनुरोध में मीडिया को अपलोड और डाउनलोड नहीं किया जा सकता.

सामान्य पैरामीटर

टॉप-लेवल डिस्कवरी दस्तावेज़ में parameters प्रॉपर्टी होती है. यह सेक्शन, हर तरीके के लिए पैरामीटर सेक्शन की तरह ही होता है. हालांकि, इन पैरामीटर को एपीआई के किसी भी तरीके पर लागू किया जा सकता है.

उदाहरण के लिए, Service Usage API के get और list तरीकों के अनुरोध पैरामीटर में prettyPrint पैरामीटर हो सकता है. इससे उन सभी तरीकों के जवाब को ऐसे फ़ॉर्मैट में फ़ॉर्मैट किया जाएगा जिसे आसानी से पढ़ा जा सकता है. यहां कुछ सामान्य पैरामीटर की सूची दी गई है:

पैरामीटर	मतलब	नोट	लागू होने की शर्तें
`access_token`	मौजूदा उपयोगकर्ता के लिए OAuth 2.0 टोकन.	OAuth 2.0 टोकन देने का एक तरीका.
`alt`	जवाब के लिए डेटा फ़ॉर्मैट.	मान्य वैल्यू: `json`, `atom`, `csv`. डिफ़ॉल्ट वैल्यू: हर एपीआई के हिसाब से अलग-अलग होती है. हर एपीआई के लिए सभी वैल्यू उपलब्ध नहीं होती हैं.	यह सभी संसाधनों के लिए, सभी कार्रवाइयों पर लागू होता है.
`callback`	कॉलबैक फ़ंक्शन.	यह JavaScript कॉलबैक फ़ंक्शन का नाम है, जो रिस्पॉन्स को हैंडल करता है. इसका इस्तेमाल JavaScript JSON-P अनुरोधों में किया जाता है.
`fields`	यह चुनने वाला टूल, रिस्पॉन्स में शामिल करने के लिए फ़ील्ड का सबसेट तय करता है.	बेहतर परफ़ॉर्मेंस के लिए इसका इस्तेमाल करें.
`key`	एपीआई पासकोड. (ज़रूरी है)	अगर आपने OAuth 2.0 टोकन नहीं दिया है, तो यह फ़ील्ड ज़रूरी है. आपका एपीआई पासकोड, आपके प्रोजेक्ट की पहचान करता है. साथ ही, आपको एपीआई ऐक्सेस, कोटा, और रिपोर्ट देता है. APIs console से अपने प्रोजेक्ट का एपीआई पासकोड पाएं.
`prettyPrint`	जवाब में इंडेंटेशन और लाइन ब्रेक शामिल होते हैं.	अगर `true` है, तो जवाब को ऐसे फ़ॉर्मैट में दिखाता है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. डिफ़ॉल्ट वैल्यू: हर एपीआई के हिसाब से अलग-अलग होती है. जब यह `false` होता है, तो इससे जवाब के पेलोड का साइज़ कम हो सकता है. इससे कुछ एनवायरमेंट में बेहतर परफ़ॉर्मेंस मिल सकती है.
`quotaUser`	`userIp` का विकल्प.	इस कुकी की मदद से, सर्वर साइड ऐप्लिकेशन से हर उपयोगकर्ता के लिए कोटा लागू किया जा सकता है. ऐसा तब भी किया जा सकता है, जब उपयोगकर्ता के आईपी पते की जानकारी न हो. ऐसा तब हो सकता है, जब कोई ऐप्लिकेशन किसी उपयोगकर्ता की ओर से App Engine पर क्रॉन जॉब चलाता हो. आपके पास ऐसी कोई भी स्ट्रिंग चुनने का विकल्प होता है जो किसी उपयोगकर्ता की यूनीक पहचान करती हो. हालांकि, यह 40 वर्णों तक सीमित होती है. अगर दोनों एट्रिब्यूट की वैल्यू दी गई हैं, तो `userIp` एट्रिब्यूट की वैल्यू की जगह इस एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है. इस्तेमाल की सीमा तय करने के बारे में ज़्यादा जानें.
`userIp`	उस असली उपयोगकर्ता का आईपी पता जिसके लिए एपीआई कॉल किया जा रहा है.	इस विकल्प की मदद से, सर्वर-साइड ऐप्लिकेशन से एपीआई को कॉल करते समय, हर उपयोगकर्ता के लिए कोटा लागू किया जा सकता है. इस्तेमाल की सीमा तय करने के बारे में ज़्यादा जानें.

इनलाइन दस्तावेज़

हर डिस्कवरी दस्तावेज़ में कई description फ़ील्ड एनोटेट किए जाते हैं. ये फ़ील्ड, एपीआई के लिए इनलाइन दस्तावेज़ उपलब्ध कराते हैं. description फ़ील्ड, इन एपीआई एलिमेंट के लिए उपलब्ध हैं:

एपीआई
OAuth के दायरे
संसाधन स्कीमा
एपीआई के तरीके
मेथड के पैरामीटर
कुछ पैरामीटर के लिए इस्तेमाल की जा सकने वाली वैल्यू

अगर आपको Google APIs Discovery Service का इस्तेमाल करके, क्लाइंट लाइब्रेरी के लिए ऐसा दस्तावेज़ जनरेट करना है जिसे आसानी से पढ़ा जा सके, तो ये फ़ील्ड आपके लिए बहुत काम के हैं. उदाहरण के लिए, JavaDoc.