এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

API ব্যবহার করে

ভূমিকা

এই ডকুমেন্টটি ডেভেলপারদের জন্য যারা ক্লায়েন্ট লাইব্রেরি, IDE প্লাগইন এবং Google API-এর সাথে ইন্টারঅ্যাক্ট করার জন্য অন্যান্য টুল লিখতে চান। Google APIs ডিসকভারি সার্ভিস আপনাকে একটি সাধারণ API এর মাধ্যমে অন্যান্য Google API সম্পর্কে মেশিন রিডেবল মেটাডেটা প্রকাশ করে উপরের সমস্ত কিছু করতে দেয়। এই নির্দেশিকাটি আবিষ্কার নথির প্রতিটি বিভাগের একটি ওভারভিউ প্রদান করে, সেইসাথে নথিটি কীভাবে ব্যবহার করতে হয় তার সহায়ক টিপস প্রদান করে।

API-এ সমস্ত কল অননুমোদিত, JSON-ভিত্তিক, REST অনুরোধ যা SSL ব্যবহার করে, অর্থাৎ URLগুলি https দিয়ে শুরু হয়।

আপনি যদি Google APIs ডিসকভারি সার্ভিস ধারণার সাথে অপরিচিত হন, তাহলে কোড শুরু করার আগে আপনার শুরু করা পড়া উচিত।

আবিষ্কার নথি বিন্যাস

এই বিভাগটি আবিষ্কার নথির একটি ওভারভিউ দেয়।

নিচের সমস্ত উদাহরণ Google ক্লাউড সার্ভিস ম্যানেজমেন্ট এপিআই থেকে ডিসকভারি ডকুমেন্ট ব্যবহার করে। আপনি এই GET অনুরোধটি কার্যকর করার মাধ্যমে Google ক্লাউড সার্ভিস ম্যানেজমেন্ট API-এর জন্য ডিসকভারি ডকুমেন্ট লোড করতে পারেন:

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

একটি আবিষ্কার নথির বিন্যাসে এমন তথ্য রয়েছে যা ছয়টি প্রধান বিভাগে পড়ে:

API-এর প্রাথমিক বিবরণ ।
API-এর জন্য প্রমাণীকরণ তথ্য।
এপিআই-এর ডেটা বর্ণনা করে রিসোর্স এবং স্কিমার বিবরণ ।
API এর পদ্ধতি সম্পর্কে বিশদ বিবরণ।
API দ্বারা সমর্থিত কোনো কাস্টম বৈশিষ্ট্য সম্পর্কে তথ্য।
ইনলাইন ডকুমেন্টেশন যা API এর মূল উপাদানগুলিকে বর্ণনা করে।

এই ডিসকভারি ডকুমেন্ট সেকশনের প্রতিটি নিচে বর্ণনা করা হয়েছে। প্রতিটি সম্পত্তি সম্পর্কে আরো বিস্তারিত জানার জন্য রেফারেন্স ডকুমেন্টেশন দেখুন.

বেসিক API বর্ণনা

আবিষ্কার নথিতে API-নির্দিষ্ট বৈশিষ্ট্যগুলির একটি সেট রয়েছে:

"kind": "discovery#restDescription",
"name": "servicemanagement",
"version": "v1",
"title": "Service Management API",
"description": "Google Service Management allows service producers to publish their services on Google Cloud Platform so that they can be discovered and used by service consumers.",
"protocol": "rest",
"rootUrl": "https://servicemanagement.googleapis.com/. Root URL under which all API services live",
"servicePath": "",

এই API-স্তরের বৈশিষ্ট্যগুলিতে name , version , title এবং description সহ একটি API-এর একটি নির্দিষ্ট সংস্করণ সম্পর্কে বিশদ অন্তর্ভুক্ত রয়েছে। protocol সর্বদা rest একটি নির্দিষ্ট মান থাকে, কারণ APIs আবিষ্কার পরিষেবা শুধুমাত্র API গুলি অ্যাক্সেস করার RESTful পদ্ধতিগুলিকে সমর্থন করে৷

servicePath ক্ষেত্রটি এই নির্দিষ্ট API সংস্করণের জন্য পাথ উপসর্গ নির্দেশ করে।

প্রমাণীকরণ

auth বিভাগে API-এর জন্য OAuth 2.0 auth স্কোপ সম্পর্কে বিশদ বিবরণ রয়েছে। OAuth 2.0 এর সাথে স্কোপগুলি কীভাবে ব্যবহার করবেন সে সম্পর্কে আরও জানতে, Google API অ্যাক্সেস করতে OAuth 2.0 ব্যবহার করুন দেখুন।

auth বিভাগে একটি নেস্টেড oauth2 এবং scopes বিভাগ রয়েছে। scopes বিভাগটি হল একটি কী/মান ম্যাপিং যা স্কোপের মান থেকে স্কোপ সম্পর্কে আরও বিশদ বিবরণের জন্য:

"auth": {
  "oauth2": {
    "scopes": {
      "https://www.googleapis.com/auth/cloud-platform.read-only": {
        "description": "View your data across Google Cloud Platform services"
      },
      "https://www.googleapis.com/auth/service.management.readonly": {
        "description": "View your Google API service configuration"
      },
      "https://www.googleapis.com/auth/cloud-platform": {
        "description": "View and manage your data across Google Cloud Platform services"
      },
      "https://www.googleapis.com/auth/service.management": {
        "description": "Manage your Google API service configuration"
      }
    }
  }
}

auth বিভাগটি শুধুমাত্র একটি নির্দিষ্ট API-এর জন্য সুযোগ নির্ধারণ করে। এই স্কোপগুলি কীভাবে একটি API পদ্ধতির সাথে যুক্ত তা জানতে, নীচের পদ্ধতি বিভাগটি দেখুন৷

সম্পদ এবং স্কিমা

একটি API-এর ক্রিয়াকলাপগুলি ডেটা অবজেক্টের উপর কাজ করে যাকে resources বলা হয়। আবিষ্কারের নথিটি সম্পদের ধারণাকে ঘিরে তৈরি করা হয়েছে। প্রতিটি ডিসকভারি নথিতে একটি শীর্ষ-স্তরের resources বিভাগ থাকে যা API এর সাথে যুক্ত সমস্ত সংস্থানকে গোষ্ঠীভুক্ত করে। উদাহরণ স্বরূপ, Google ক্লাউড সার্ভিস ম্যানেজমেন্ট API-এর একটি services সংস্থান এবং শীর্ষ-স্তরের resources অধীনে একটি operations সংস্থান রয়েছে, services সংস্থানগুলির তিনটি উপ-সম্পদ রয়েছে, rollouts configs consumers :

"resources": {
  "services": {
    // Methods and sub-resources associated with the services resource
    "configs": {
      // Methods and sub-resources associated with the services.configs resource
    },
    "rollouts": {
      // Methods and sub-resources associated with the services.rollouts resource
    },
    "consumers": {
      // Methods and sub-resources associated with the services.consumers resource
    }
  },
  "operations": {
    // Methods and sub-resources associated with the operations resource
  }
}

প্রতিটি সম্পদ বিভাগের ভিতরে সেই সম্পদের সাথে যুক্ত পদ্ধতি রয়েছে। উদাহরণ স্বরূপ, Google ক্লাউড সার্ভিস ম্যানেজমেন্ট API-এর services.rollouts রিসোর্সের সাথে যুক্ত তিনটি পদ্ধতি রয়েছে: get , list এবং create ।

স্কিমাগুলি আপনাকে বলে যে একটি API-তে সংস্থানগুলি কেমন দেখায়৷ প্রতিটি ডিসকভারি নথিতে একটি শীর্ষ-স্তরের schemas বিভাগ থাকে, যেটিতে অবজেক্টের স্কিমা আইডির একটি নাম/মূল্য যুক্ত থাকে। স্কিমা আইডিগুলি API প্রতি অনন্য, এবং ডিসকভারি নথির methods বিভাগে স্কিমাটিকে অনন্যভাবে সনাক্ত করতে ব্যবহৃত হয়:

"schemas": {
  "Rollout": {
    // JSON Schema of the Rollout resource.
  }
}

APIs আবিষ্কার পরিষেবা তার স্কিমা উপস্থাপনার জন্য JSON স্কিমা ড্রাফ্ট-03 ব্যবহার করে। এখানে একটি প্রকৃত প্রতিক্রিয়া সংস্থান সহ Url সংস্থানের জন্য JSON স্কিমার একটি স্নিপেট রয়েছে:

রোলআউট রিসোর্স JSON স্কিমা:

প্রকৃত রোলআউট রিসোর্স প্রতিক্রিয়া:

{
  "Rollout": {
    "id": "Rollout",
    "type": "object",
    "description": "...",
    "properties": {
      "serviceName": {
        "type": "string",
        "description": "..."
      },
      "rolloutId": {
        "type": "string",
        "description": "..."
      },
      "status": {
        "type": "string",
        "enum": [
          "ROLLOUT_STATUS_UNSPECIFIED",
          "IN_PROGRESS",
          "SUCCESS",
          "CANCELLED",
          "FAILED",
          "PENDING",
          "FAILED_ROLLED_BACK"
        ],
        "enumDescriptions": [
          ...
        ],
        "description": "..."
      },
      "trafficPercentStrategy": {
        "$ref": "TrafficPercentStrategy",
        "description": "..."
      },
      "deleteServiceStrategy": { ... },
      "createTime": { ... },
      "createdBy": { ... }
    }
  }
}

{
  "serviceName": "discovery.googleapis.com",
  "rolloutId": "2020-01-01R0",
  "status": "SUCCESS",
  "trafficPercentStrategy":{
    "precentages":{
      "2019-12-01R0": 70.00,
      "2019-11-01R0": 30.00
    }
  }
}

বোল্ড ক্ষেত্রগুলি JSON স্কিমা এবং প্রকৃত প্রতিক্রিয়ার মধ্যে ম্যাপিং দেখায়৷

স্কিমাগুলিতে অন্যান্য স্কিমার উল্লেখ থাকতে পারে। আপনি যদি একটি ক্লায়েন্ট লাইব্রেরি তৈরি করেন তবে এটি আপনাকে আপনার ডেটা মডেল ক্লাসে একটি API এর বস্তুকে কার্যকরভাবে মডেল করতে সহায়তা করতে পারে। উপরের Rollout উদাহরণে, trafficPercentStrategy প্রপার্টি আসলে ID TrafficPercentStrategy সহ একটি স্কিমার রেফারেন্স। আপনি যদি schemas বিভাগটি দেখেন তবে আপনি TrafficPercentStrategy স্কিমা পাবেন। এই স্কিমার মানটি Rollout রিসোর্সে ট্রাফিক trafficPercentStrategy প্রপার্টির জন্য প্রতিস্থাপিত হতে পারে (মনে রাখবেন যে $ref সিনট্যাক্স JSON স্কিমা স্পেক থেকে এসেছে)।

তাদের অনুরোধ এবং প্রতিক্রিয়া সংস্থাগুলি নির্দেশ করার সময় পদ্ধতিগুলি স্কিমাগুলিকেও উল্লেখ করতে পারে। আরও বিস্তারিত জানার জন্য পদ্ধতি বিভাগে পড়ুন।

পদ্ধতি

আবিষ্কার নথির মূল পদ্ধতিগুলিকে ঘিরে তৈরি করা হয়েছে। পদ্ধতিগুলি হল সেই ক্রিয়াকলাপ যা একটি API-তে সঞ্চালিত হতে পারে। আপনি ডিসকভারি ডকুমেন্টের বিভিন্ন ক্ষেত্রে methods সেকশন পাবেন, যার মধ্যে টপ লেভেলে (যাকে আমরা API-লেভেল মেথড বলি) বা resources লেভেলে।

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

যদিও একটি API-এর API-স্তরের পদ্ধতি থাকতে পারে , একটি সংস্থান অবশ্যই একটি methods বিভাগ থাকতে হবে।

প্রতিটি methods বিভাগ হল একটি কী/মান মানচিত্র পদ্ধতির নাম থেকে সেই পদ্ধতি সম্পর্কে অন্যান্য বিবরণ পর্যন্ত। নীচের উদাহরণটি তিনটি পদ্ধতির নথি, get , list এবং create :

"methods": {
  "get": { //details about the "get" method },
  "list": { //details about the "list" method },
  "create": { //details about the "create" method }
}

অবশেষে, প্রতিটি পদ্ধতির বিভাগ সেই পদ্ধতি সম্পর্কে বিভিন্ন বৈশিষ্ট্যের বিবরণ দেয়। এখানে get পদ্ধতির একটি উদাহরণ:

"get": {
  "id": "servicemanagement.services.rollouts.get",
  "path": "v1/services/{serviceName}/rollouts/{rolloutId}",
  "flatPath": "v1/services/{serviceName}/rollouts/{rolloutId}",
  "httpMethod": "GET",
  "description": "Gets a service configuration rollout.",
  "response": { "$ref": "Rollout" },
  "parameters": { // parameters related to the method },
  "parameterOrder": [ // parameter order related to the method ],
  "scopes": [ // OAuth 2.0 scopes applicable to this method ],
  "mediaUpload": { // optional media upload information },
},

এই বিভাগে সাধারণ পদ্ধতির বিশদ রয়েছে যেমন পদ্ধতি সনাক্ত করার জন্য একটি অনন্য ID , ব্যবহার করার জন্য httpMethod এবং পদ্ধতির path (সম্পূর্ণ পদ্ধতির url গণনা করার জন্য কীভাবে path সম্পত্তি ব্যবহার করতে হয় তার বিশদ বিবরণের জন্য, একটি অনুরোধ রচনা করুন বিভাগটি দেখুন ) এই সাধারণ পদ্ধতির বৈশিষ্ট্যগুলি ছাড়াও, কিছু বৈশিষ্ট্য রয়েছে যা আবিষ্কার নথিতে অন্যান্য বিভাগের সাথে পদ্ধতিটিকে সংযুক্ত করে:

স্কোপ

এই ডকুমেন্টেশনের আগে সংজ্ঞায়িত auth বিভাগে একটি নির্দিষ্ট API দ্বারা সমর্থিত সমস্ত স্কোপের তথ্য রয়েছে। যদি একটি পদ্ধতি এই স্কোপগুলির একটিকে সমর্থন করে তবে এটির একটি স্কোপ অ্যারে থাকবে। পদ্ধতি দ্বারা সমর্থিত প্রতিটি সুযোগের জন্য এই অ্যারেতে একটি এন্ট্রি রয়েছে। উদাহরণস্বরূপ, Google ক্লাউড সার্ভিস ম্যানেজমেন্ট API এর scopes বিভাগটি এইরকম দেখায় get

"scopes": [
  "https://www.googleapis.com/auth/cloud-platform",
  "https://www.googleapis.com/auth/cloud-platform.read-only",
  "https://www.googleapis.com/auth/service.management",
  "https://www.googleapis.com/auth/service.management.readonly"
]

মনে রাখবেন যে আপনার অ্যাপ্লিকেশনে ব্যবহার করার জন্য একটি প্রমাণীকরণের সুযোগ নির্বাচন করা বিভিন্ন কারণের উপর নির্ভর করে যেমন কোন পদ্ধতিগুলিকে কল করা হচ্ছে এবং পদ্ধতির সাথে কোন প্যারামিটারগুলি পাঠানো হয়েছে৷ অতএব, কোন সুযোগটি ব্যবহার করবেন তার সিদ্ধান্ত বিকাশকারীর উপর ছেড়ে দেওয়া হয়। আবিষ্কার শুধুমাত্র নথি যা স্কোপ একটি পদ্ধতির জন্য বৈধ।

অনুরোধ এবং প্রতিক্রিয়া

যদি পদ্ধতিটির একটি অনুরোধ বা প্রতিক্রিয়ার অংশ থাকে, তবে এগুলি যথাক্রমে request বা response বিভাগে নথিভুক্ত করা হয়। উপরের উদাহরণে, পদ্ধতিটির একটি response বডি রয়েছে get

"response": {
  "$ref": "Rollout"
}

উপরের সিনট্যাক্সটি নির্দেশ করে যে রেসপন্স বডি একটি JSON স্কিমা দ্বারা Rollout একটি আইডি দ্বারা সংজ্ঞায়িত করা হয়েছে। এই স্কিমাটি শীর্ষ-স্তরের স্কিমা বিভাগে পাওয়া যাবে। অনুরোধ এবং প্রতিক্রিয়া উভয় সংস্থাই স্কিমা উল্লেখ করার জন্য $ref সিনট্যাক্স ব্যবহার করে।

পরামিতি

যদি একটি পদ্ধতিতে পরামিতি থাকে যা ব্যবহারকারীর দ্বারা নির্দিষ্ট করা উচিত, এই পরামিতিগুলি পদ্ধতি-স্তরের parameters বিভাগে নথিভুক্ত করা হয়। এই বিভাগে সেই প্যারামিটার সম্পর্কে আরও বিশদ বিবরণের জন্য প্যারামিটার নামের একটি কী/মান ম্যাপিং রয়েছে:

"parameters": {
  "serviceName": {
    "type": "string",
    "description": "Required. The name of the service.",
    "required": true,
    "location": "path"
  },
  "rolloutId": { ... }
},
"parameterOrder": [
  "serviceName",
  "rolloutId"
]

উপরের উদাহরণে, get পদ্ধতির জন্য দুটি পরামিতি রয়েছে: serviceName এবং rolloutId । প্যারামিটারগুলি হয় path বা URL query যেতে পারে; location বৈশিষ্ট্য নির্দেশ করে যেখানে ক্লায়েন্ট লাইব্রেরি পরামিতি স্থাপন করা উচিত।

প্যারামিটার ডেটা type (দৃঢ়ভাবে টাইপ করা ভাষার জন্য দরকারী), প্যারামিটারটি required কিনা এবং প্যারামিটারটি একটি enum সহ প্যারামিটারটি বর্ণনা করে এমন আরও অনেক বৈশিষ্ট্য রয়েছে। বৈশিষ্ট্য সম্পর্কে আরো বিস্তারিত জানার জন্য রেফারেন্স গাইডের সাথে পরামর্শ করুন।

প্যারামিটার অর্ডার

ক্লায়েন্ট লাইব্রেরির জন্য তাদের ইন্টারফেস গঠনের জন্য অনেক উপায় রয়েছে। একটি উপায় হল পদ্ধতি স্বাক্ষরে প্রতিটি API প্যারামিটার সহ একটি পদ্ধতি থাকা। যাইহোক, যেহেতু JSON একটি ক্রমবিন্যস্ত বিন্যাস, তাই পদ্ধতি স্বাক্ষরে পরামিতিগুলি কীভাবে অর্ডার করতে হয় তা প্রোগ্রাম্যাটিকভাবে জানা কঠিন। parameterOrder অ্যারে অনুরোধ করার জন্য একটি নির্দিষ্ট প্যারামিটার অর্ডার প্রদান করে। অ্যারে প্রতিটি প্যারামিটারের নাম তাত্পর্যের ক্রম অনুসারে তালিকাভুক্ত করে; এটি পাথ বা ক্যোয়ারী পরামিতি ধারণ করতে পারে, কিন্তু অ্যারের প্রতিটি প্যারামিটার প্রয়োজন। উপরের উদাহরণে, একটি জাভা পদ্ধতি স্বাক্ষর এই মত কিছু দেখতে পারে:

public Rollout get(String serviceName, String rolloutId, Map<String, Object> optionalParameters);

parameterOrder অ্যারের প্রথম মান, serviceName , এছাড়াও পদ্ধতি স্বাক্ষরের প্রথম উপাদান। যদি parameterOrder অ্যারেতে অন্যান্য পরামিতি থাকে তবে সেগুলি serviceName প্যারামিটারের পরে যাবে। যেহেতু parameterOrder অ্যারেতে শুধুমাত্র প্রয়োজনীয় প্যারামিটার থাকে, তাই ব্যবহারকারীদের ঐচ্ছিক পরামিতিগুলিও নির্দিষ্ট করার জন্য একটি উপায় অন্তর্ভুক্ত করা একটি ভাল অভ্যাস। উপরের উদাহরণটি optionalParameters মানচিত্রের সাথে এটি করে।

মিডিয়া আপলোড

যদি একটি পদ্ধতি আপলোড মিডিয়া সমর্থন করে, যেমন ছবি, অডিও, বা ভিডিও, তাহলে সেই মিডিয়া আপলোড করার জন্য সমর্থিত অবস্থান এবং প্রোটোকলগুলি মিডিয়া 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 এমবি আকারে সীমাবদ্ধ৷ মনে রাখবেন যে এই মানটি সেই API-এর জন্য একটি পৃথক ব্যবহারকারীর অবশিষ্ট সঞ্চয়স্থান কোটা প্রতিফলিত করে না, তাই আপলোডটি maxSize এর চেয়ে কম হলেও ক্লায়েন্ট লাইব্রেরীকে একটি আপলোড পরিচালনা করার জন্য প্রস্তুত থাকতে হবে যা অপর্যাপ্ত স্থানের কারণে ব্যর্থ হয়।

protocols বিভাগটি আপলোড প্রোটোকলগুলির তালিকা করে যা একটি পদ্ধতি সমর্থন করে। simple প্রোটোকল হল শুধুমাত্র একটি একক HTTP অনুরোধে প্রদত্ত এন্ডপয়েন্টে মিডিয়া পোস্ট করা। resumable প্রোটোকল বোঝায় যে path URI-তে দেওয়া শেষ পয়েন্টটি পুনরায় শুরুযোগ্য আপলোড প্রোটোকলকে সমর্থন করে। যদি multipart প্রপার্টি true হয় তাহলে এন্ডপয়েন্ট মাল্টিপার্ট আপলোড গ্রহণ করে, যার অর্থ JSON অনুরোধ এবং মিডিয়া উভয়ই একটি mutlipart/সম্পর্কিত বডিতে একসাথে মোড়ানো এবং একসাথে পাঠানো যেতে পারে। মনে রাখবেন যে simple এবং resumable উভয় প্রোটোকলই মাল্টিপার্ট আপলোড সমর্থন করতে পারে।

path প্রপার্টিটি হল একটি URI টেমপ্লেট এবং এটিকে প্রসারিত করা উচিত পদ্ধতির জন্য path প্রপার্টির মত, যেমনটি একটি অনুরোধ রচনা বিভাগে বর্ণিত হয়েছে।

মিডিয়া ডাউনলোড

যদি একটি পদ্ধতি মিডিয়া ডাউনলোড করা সমর্থন করে, যেমন ছবি, অডিও, বা ভিডিও, তাহলে সেটি supportsMediaDownload প্যারামিটার দ্বারা নির্দেশিত হয়:

"supportsMediaDownload": true,

মিডিয়া ডাউনলোড করার সময় আপনাকে অনুরোধ URL-এ media alt ক্যোয়ারী প্যারামিটার সেট করতে হবে।

API পদ্ধতির useMediaDownloadService বৈশিষ্ট্যটি true হলে, একটি পুনঃনির্দেশ এড়াতে servicePath এর আগে সন্নিবেশ /download করুন। উদাহরণস্বরূপ, ডাউনলোড পাথ হল /download/youtube/v3/captions/{id} যদি servicePath এবং path সংমিশ্রণ /youtube/v3/captions/{id} হয়। useMediaDownloadService ব্যবহার করলেও /download সহ মিডিয়া ডাউনলোড URL তৈরি করার পরামর্শ দেওয়া হয়।

দ্রষ্টব্য: মিডিয়া ডাউনলোড এবং আপলোড উভয় সমর্থন করার জন্য এটি একটি API পদ্ধতির জন্য অনুমোদিত। মিডিয়া আপলোড এবং ডাউনলোডের জন্য অনুরোধ URL নির্মাণ যুক্তি স্বাধীনভাবে কাজ করে এবং একে অপরের সাথে হস্তক্ষেপ করে না। ফলস্বরূপ, এই ধরনের API পদ্ধতিতে মিডিয়া ডাউনলোডের জন্য একটি /download/... url এবং মিডিয়া আপলোড করার জন্য একটি /upload/... url থাকবে। যাইহোক, কেউ একটি একক অনুরোধে মিডিয়া আপলোড এবং ডাউনলোড করতে পারবেন না।

সাধারণ পরামিতি

শীর্ষ-স্তরের আবিষ্কার নথিতে একটি parameters বৈশিষ্ট্য রয়েছে। এই বিভাগটি প্রতিটি পদ্ধতির জন্য পরামিতি বিভাগের অনুরূপ, তবে এই পরামিতিগুলি API-এর যেকোনো পদ্ধতিতে প্রয়োগ করা যেতে পারে।

উদাহরণ স্বরূপ, Google ক্লাউড সার্ভিস ম্যানেজমেন্ট এপিআই-এর প্রাপ্ত, সন্নিবেশ বা তালিকা পদ্ধতিতে অনুরোধের প্যারামিটারে একটি prettyPrint প্যারামিটার থাকতে পারে, যা মানব-পাঠযোগ্য বিন্যাসে সেই সমস্ত পদ্ধতির প্রতিক্রিয়া ফর্ম্যাট করবে। এখানে সাধারণ পরামিতিগুলির একটি তালিকা রয়েছে:

প্যারামিটার	অর্থ	মন্তব্য	প্রযোজ্যতা
`access_token`	বর্তমান ব্যবহারকারীর জন্য OAuth 2.0 টোকেন।	একটি OAuth 2.0 টোকেন প্রদান করার একটি সম্ভাব্য উপায় ।
`alt`	প্রতিক্রিয়ার জন্য ডেটা বিন্যাস।	বৈধ মান: `json` , `atom` , `csv` । ডিফল্ট মান: API প্রতি পরিবর্তিত হয়। প্রতিটি API-এর জন্য সমস্ত মান উপলব্ধ নয়।	সমস্ত সংস্থানগুলির জন্য সমস্ত ক্রিয়াকলাপে প্রযোজ্য।
`callback`	কলব্যাক ফাংশন।	জাভাস্ক্রিপ্ট কলব্যাক ফাংশনের নাম যা প্রতিক্রিয়া পরিচালনা করে। JavaScript JSON-P অনুরোধে ব্যবহৃত হয়।
`fields`	প্রতিক্রিয়া অন্তর্ভুক্ত করার জন্য ক্ষেত্রগুলির একটি উপসেট নির্দিষ্ট করে নির্বাচক৷	আরও তথ্যের জন্য, আংশিক প্রতিক্রিয়া ডকুমেন্টেশন দেখুন। ভাল কর্মক্ষমতা জন্য ব্যবহার করুন.
`key`	API কী। (প্রয়োজনীয়*)	*আপনি একটি OAuth 2.0 টোকেন প্রদান না করা পর্যন্ত প্রয়োজনীয়৷ আপনার API কী আপনার প্রজেক্টকে শনাক্ত করে এবং আপনাকে API অ্যাক্সেস, কোটা এবং রিপোর্ট প্রদান করে। APIs কনসোল থেকে আপনার প্রকল্পের API কী পান।
`prettyPrint`	পরিচয় এবং লাইন বিরতি সহ প্রতিক্রিয়া প্রদান করে।	`true` হলে মানব-পাঠযোগ্য বিন্যাসে প্রতিক্রিয়া প্রদান করে। ডিফল্ট মান: API প্রতি পরিবর্তিত হয়। যখন এটি `false` হয়, এটি প্রতিক্রিয়া পেলোডের আকার হ্রাস করতে পারে, যা কিছু পরিবেশে আরও ভাল কর্মক্ষমতার দিকে নিয়ে যেতে পারে।
`quotaUser`	`userIp` বিকল্প।	ব্যবহারকারীর আইপি ঠিকানা অজানা থাকা অবস্থায়ও আপনাকে সার্ভার-সাইড অ্যাপ্লিকেশন থেকে প্রতি-ব্যবহারকারী কোটা প্রয়োগ করতে দেয়। এটি ঘটতে পারে, উদাহরণস্বরূপ, ব্যবহারকারীর পক্ষ থেকে অ্যাপ ইঞ্জিনে ক্রোন কাজ চালানোর অ্যাপ্লিকেশনগুলির সাথে। আপনি যেকোন নির্বিচারে স্ট্রিং চয়ন করতে পারেন যা ব্যবহারকারীকে অনন্যভাবে সনাক্ত করে, তবে এটি 40টি অক্ষরের মধ্যে সীমাবদ্ধ। উভয়ই প্রদান করা হলে `userIp` ওভাররাইড করে। ক্যাপিং ব্যবহার সম্পর্কে আরও জানুন।
`userIp`	শেষ ব্যবহারকারীর IP ঠিকানা যার জন্য API কল করা হচ্ছে।	সার্ভার-সাইড অ্যাপ্লিকেশন থেকে API কল করার সময় আপনাকে প্রতি-ব্যবহারকারী কোটা প্রয়োগ করতে দেয়। ক্যাপিং ব্যবহার সম্পর্কে আরও জানুন।

বৈশিষ্ট্য

এমন কিছু ক্ষেত্রে রয়েছে যেখানে API গুলি ডিসকভারি নথির বাকি অংশের বাইরে কাস্টম বৈশিষ্ট্য সমর্থন করে। এই features অ্যারে সংগ্রহ করা হয়. বৈশিষ্ট্য অ্যারেতে API দ্বারা সমর্থিত প্রতিটি বিশেষ বৈশিষ্ট্যের জন্য একটি স্ট্রিং লেবেল রয়েছে। বর্তমানে, dataWrapper একমাত্র সমর্থিত বৈশিষ্ট্য, তবে অন্যান্য বৈশিষ্ট্যগুলি ভবিষ্যতে সমর্থিত হতে পারে।

"features": dataWrapper

dataWrapper বৈশিষ্ট্যটি নির্দেশ করে যে API-এর সমস্ত অনুরোধ এবং প্রতিক্রিয়া একটি data JSON অবজেক্টে মোড়ানো হয়। এটি পুরানো Google API-এর একটি বৈশিষ্ট্য, কিন্তু এটি এগিয়ে যেতে বঞ্চিত হচ্ছে। নিম্নলিখিত APIগুলি dataWrapper বৈশিষ্ট্য সমর্থন করে: মডারেটর v1 , এবং অনুবাদ v2 ।

একটি ক্লায়েন্ট লাইব্রেরি বিকাশকারী হিসাবে, যদি একটি API "ডেটা র্যাপার" বৈশিষ্ট্য সমর্থন করে, তাহলে আপনাকে নিম্নলিখিতগুলি করতে হবে:

অনুরোধে: একটি data JSON অবজেক্টে অনুরোধ সংস্থানটি মোড়ানো।
প্রতিক্রিয়াগুলিতে: একটি data JSON অবজেক্টের ভিতরে সংস্থান খুঁজুন।

ডিসকভারি ডকুমেন্টের স্কিমাগুলিতে ডেটা র‍্যাপার থাকে না, তাই আপনাকে অবশ্যই সেগুলিকে স্পষ্টভাবে যুক্ত করতে হবে এবং সরাতে হবে৷ উদাহরণস্বরূপ, ধরুন "Foo" নামের একটি সংস্থান সহ একটি API আছে যা দেখতে এইরকম:

{
  "id": 1,
  "foo": "bar"
}

API ব্যবহার করে এই সংস্থানটি সন্নিবেশ করার আগে, আপনাকে এটি একটি ডেটা উপাদানে মোড়ানো দরকার:

{
  "data": {
    "id": 1,
    "foo": "bar"
  }
}

ফ্লিপ সাইডে, যখন আপনি API থেকে একটি প্রতিক্রিয়া পান, এতে ডেটা র‍্যাপারও থাকে:

{
  "data": {
    "id": 1,
    "foo": "bar"
  }
}

স্কিমা দ্বারা সংজ্ঞায়িত সংস্থান পেতে, আপনাকে ডেটা মোড়কটি সরাতে হবে:

{
  "id": 1,
  "foo": "bar"
}

ইনলাইন ডকুমেন্টেশন

প্রতিটি ডিসকভারি ডকুমেন্ট এপিআই-এর জন্য ইনলাইন ডকুমেন্টেশন প্রদান করে এমন অনেকগুলি description ক্ষেত্র সহ টীকা করা হয়। নিম্নলিখিত API উপাদানগুলির জন্য description ক্ষেত্রগুলি পাওয়া যেতে পারে:

API নিজেই
OAuth স্কোপ
রিসোর্স স্কিমা
API পদ্ধতি
পদ্ধতির পরামিতি
নির্দিষ্ট প্যারামিটারের জন্য গ্রহণযোগ্য মান

এই ক্ষেত্রগুলি বিশেষভাবে উপযোগী যদি আপনি Google APIs আবিষ্কার পরিষেবা ব্যবহার করতে চান যাতে একটি ক্লায়েন্ট লাইব্রেরির জন্য মানুষের পাঠযোগ্য ডকুমেন্টেশন তৈরি করা যায়, যেমন JavaDoc।

পরবর্তী পদক্ষেপ

একটি ক্লায়েন্ট লাইব্রেরি নির্মাণ