পারফরম্যান্সের উন্নতি

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

জিজিপ ব্যবহার করে কম্প্রেশন

প্রতিটি অনুরোধের জন্য প্রয়োজনীয় ব্যান্ডউইথ কমানোর একটি সহজ এবং সুবিধাজনক উপায় হল জিজিপ কম্প্রেশন সক্ষম করা। যদিও ফলাফলগুলিকে কম্প্রেস করতে এর জন্য অতিরিক্ত CPU সময় প্রয়োজন, নেটওয়ার্ক খরচের সাথে ট্রেড-অফ সাধারণত এটিকে খুব সার্থক করে তোলে।

একটি gzip-এনকোড করা প্রতিক্রিয়া পাওয়ার জন্য আপনাকে দুটি জিনিস করতে হবে: একটি Accept-Encoding শিরোনাম সেট করুন এবং স্ট্রিং gzip ধারণ করতে আপনার ব্যবহারকারী এজেন্টকে পরিবর্তন করুন। এখানে gzip কম্প্রেশন সক্ষম করার জন্য সঠিকভাবে গঠিত HTTP হেডারগুলির একটি উদাহরণ রয়েছে:

Accept-Encoding: gzip
User-Agent: my program (gzip)

আংশিক সম্পদ নিয়ে কাজ করা

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

দুই ধরনের আংশিক অনুরোধ আছে:

  • আংশিক প্রতিক্রিয়া : একটি অনুরোধ যেখানে আপনি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি অন্তর্ভুক্ত করতে হবে তা নির্দিষ্ট করেন ( fields অনুরোধের প্যারামিটার ব্যবহার করুন)।
  • প্যাচ : একটি আপডেট অনুরোধ যেখানে আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তা পাঠান ( PATCH HTTP ক্রিয়া ব্যবহার করুন)।

আংশিক অনুরোধ করার বিষয়ে আরও বিশদ নিম্নলিখিত বিভাগে দেওয়া হয়েছে।

আংশিক প্রতিক্রিয়া

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

একটি আংশিক প্রতিক্রিয়া অনুরোধ করতে, আপনি যে ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে fields অনুরোধ প্যারামিটার ব্যবহার করুন৷ আপনি এই প্যারামিটারটি যেকোন অনুরোধের সাথে ব্যবহার করতে পারেন যা প্রতিক্রিয়া ডেটা প্রদান করে।

মনে রাখবেন যে fields প্যারামিটার শুধুমাত্র প্রতিক্রিয়া ডেটা প্রভাবিত করে; এটি আপনাকে যে ডেটা পাঠাতে হবে তা প্রভাবিত করে না, যদি থাকে। সম্পদ পরিবর্তন করার সময় আপনার পাঠানো ডেটার পরিমাণ কমাতে, একটি প্যাচ অনুরোধ ব্যবহার করুন।

উদাহরণ

প্যাচ (আংশিক আপডেট)

সম্পদ পরিবর্তন করার সময় আপনি অপ্রয়োজনীয় ডেটা পাঠানো এড়াতে পারেন। আপনি যে নির্দিষ্ট ক্ষেত্রে পরিবর্তন করছেন তার জন্য শুধুমাত্র আপডেট করা ডেটা পাঠাতে, HTTP PATCH ক্রিয়া ব্যবহার করুন। এই নথিতে বর্ণিত প্যাচ শব্দার্থবিদ্যা আংশিক আপডেটের পুরানো, GData বাস্তবায়নের তুলনায় ভিন্ন (এবং সহজ)।

নীচের সংক্ষিপ্ত উদাহরণটি দেখায় কিভাবে প্যাচ ব্যবহার করে একটি ছোট আপডেট করার জন্য আপনাকে যে ডেটা পাঠাতে হবে তা কমিয়ে দেয়।

উদাহরণ

একটি প্যাচ প্রতিক্রিয়া হ্যান্ডলিং

একটি বৈধ প্যাচ অনুরোধ প্রক্রিয়া করার পরে, API পরিবর্তিত সম্পদের সম্পূর্ণ উপস্থাপনা সহ একটি 200 OK HTTP প্রতিক্রিয়া কোড প্রদান করে। যদি ETagsগুলি API দ্বারা ব্যবহার করা হয়, সার্ভারটি ETag মানগুলি আপডেট করে যখন এটি একটি প্যাচ অনুরোধ সফলভাবে প্রক্রিয়া করে, ঠিক যেমন এটি PUT এর সাথে করে।

প্যাচ রিকোয়েস্ট সম্পূর্ণ রিসোর্স রিপ্রেজেন্টেশন রিটার্ন করে যদি না আপনি fields প্যারামিটার ব্যবহার করে ডেটার পরিমাণ কমাতে ব্যবহার করেন।

যদি একটি প্যাচ অনুরোধ একটি নতুন রিসোর্স স্থিতিতে পরিণত হয় যা সিনট্যাক্টিক্যাল বা শব্দার্থগতভাবে অবৈধ, সার্ভারটি একটি 400 Bad Request বা 422 Unprocessable Entity HTTP স্ট্যাটাস কোড ফেরত দেয় এবং রিসোর্স অবস্থা অপরিবর্তিত থাকে। উদাহরণস্বরূপ, যদি আপনি একটি প্রয়োজনীয় ক্ষেত্রের জন্য মান মুছে ফেলার চেষ্টা করেন, সার্ভার একটি ত্রুটি প্রদান করে।

প্যাচ HTTP ক্রিয়া সমর্থিত না হলে বিকল্প স্বরলিপি

যদি আপনার ফায়ারওয়াল HTTP PATCH অনুরোধের অনুমতি না দেয়, তাহলে একটি HTTP POST অনুরোধ করুন এবং ওভাররাইড হেডারটিকে PATCH এ সেট করুন, যেমনটি নীচে দেখানো হয়েছে:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

প্যাচ এবং আপডেটের মধ্যে পার্থক্য

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

এই কারণে প্যাচ ব্যবহার করা অনেক নিরাপদ। আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তার জন্য ডেটা সরবরাহ করুন; আপনি বাদ দেওয়া ক্ষেত্রগুলি সাফ করা হয় না। এই নিয়মের একমাত্র ব্যতিক্রমটি পুনরাবৃত্তি করা উপাদান বা অ্যারেগুলির সাথে ঘটে: আপনি যদি তাদের সবগুলি বাদ দেন তবে তারা যেমন আছে ঠিক তেমনই থাকবে; আপনি যদি তাদের কোনোটি প্রদান করেন, তাহলে পুরো সেটটি আপনার দেওয়া সেট দিয়ে প্রতিস্থাপিত হবে।

ব্যাচ অনুরোধ

এই নথিটি দেখায় যে কীভাবে আপনার ক্লায়েন্টকে HTTP সংযোগগুলি তৈরি করতে হবে তা কমাতে API কলগুলিকে একসাথে ব্যাচ করতে হয়৷

এই নথিটি বিশেষভাবে একটি HTTP অনুরোধ পাঠিয়ে একটি ব্যাচ অনুরোধ করার বিষয়ে। যদি, পরিবর্তে, আপনি একটি ব্যাচ অনুরোধ করতে একটি Google ক্লায়েন্ট লাইব্রেরি ব্যবহার করেন, ক্লায়েন্ট লাইব্রেরির ডকুমেন্টেশন দেখুন।

ওভারভিউ

প্রতিটি HTTP সংযোগ আপনার ক্লায়েন্ট একটি নির্দিষ্ট পরিমাণ ওভারহেড ফলাফল করে। Google ড্রাইভ API ব্যাচিং সমর্থন করে, আপনার ক্লায়েন্টকে একটি একক HTTP অনুরোধে একাধিক API কল করার অনুমতি দিতে।

আপনি যখন ব্যাচিং ব্যবহার করতে চাইতে পারেন এমন পরিস্থিতির উদাহরণ:

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

প্রতিটি ক্ষেত্রে, প্রতিটি কল আলাদাভাবে পাঠানোর পরিবর্তে, আপনি একটি একক HTTP অনুরোধে তাদের একসাথে গোষ্ঠী করতে পারেন। সমস্ত অভ্যন্তরীণ অনুরোধ একই Google API এ যেতে হবে।

আপনি একটি একক ব্যাচ অনুরোধে 100টি কলের মধ্যে সীমাবদ্ধ। আপনি যদি এর চেয়ে বেশি কল করতে চান তবে একাধিক ব্যাচ অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : Google Drive API-এর ব্যাচ সিস্টেম OData ব্যাচ প্রসেসিং সিস্টেমের মতো একই সিনট্যাক্স ব্যবহার করে, কিন্তু শব্দার্থবিদ্যা আলাদা।

অতিরিক্ত সীমাবদ্ধতা অন্তর্ভুক্ত:

  • 100 টির বেশি কল সহ ব্যাচের অনুরোধগুলি একটি ত্রুটির কারণ হতে পারে৷
  • প্রতিটি অভ্যন্তরীণ অনুরোধের জন্য URL-এর দৈর্ঘ্যে একটি 8,000 অক্ষরের সীমা রয়েছে৷
  • Google ড্রাইভ মিডিয়ার জন্য ব্যাচ অপারেশন সমর্থন করে না, হয় আপলোড বা ডাউনলোডের জন্য বা ফাইল রপ্তানির জন্য।

ব্যাচের বিবরণ

একটি ব্যাচ অনুরোধে একাধিক API কল থাকে যা একটি HTTP অনুরোধের সাথে মিলিত হয়, যা API আবিষ্কার নথিতে নির্দিষ্ট batchPath পাঠানো যেতে পারে। ডিফল্ট পাথ হল /batch/ api_name / api_version । এই বিভাগে ব্যাচ সিনট্যাক্স বিস্তারিতভাবে বর্ণনা করে; পরে, একটি উদাহরণ আছে.

দ্রষ্টব্য : একত্রে ব্যাচ করা n অনুরোধের একটি সেট আপনার ব্যবহারের সীমা n অনুরোধ হিসাবে গণনা করে, একটি অনুরোধ হিসাবে নয়। ব্যাচ অনুরোধ প্রক্রিয়াকরণের আগে অনুরোধের একটি সেট মধ্যে বিভক্ত করা হয়.

একটি ব্যাচ অনুরোধের বিন্যাস

একটি ব্যাচ অনুরোধ হল একটি একক স্ট্যান্ডার্ড HTTP অনুরোধ যাতে একাধিক Google ড্রাইভ API কল থাকে, multipart/mixed সামগ্রীর ধরন ব্যবহার করে। সেই প্রধান HTTP অনুরোধের মধ্যে, প্রতিটি অংশে একটি নেস্টেড HTTP অনুরোধ থাকে।

প্রতিটি অংশ তার নিজস্ব Content-Type: application/http HTTP হেডার। এটিতে একটি ঐচ্ছিক Content-ID শিরোনামও থাকতে পারে। যাইহোক, অংশের শিরোনামগুলি শুধুমাত্র অংশের শুরুতে চিহ্নিত করার জন্য রয়েছে; তারা নেস্টেড অনুরোধ থেকে আলাদা। সার্ভার ব্যাচের অনুরোধটিকে পৃথক অনুরোধে আনর্যাপ করার পরে, অংশ শিরোনামগুলি উপেক্ষা করা হয়।

প্রতিটি অংশের মূল অংশটি একটি সম্পূর্ণ HTTP অনুরোধ, যার নিজস্ব ক্রিয়া, URL, শিরোনাম এবং বডি রয়েছে। HTTP অনুরোধে শুধুমাত্র URL এর পাথ অংশ থাকতে হবে; ব্যাচ অনুরোধে সম্পূর্ণ URL গুলি অনুমোদিত নয়৷

বাইরের ব্যাচের অনুরোধের জন্য HTTP শিরোনামগুলি, Content- -শিরোনামগুলি ব্যতীত যেমন Content-Type , ব্যাচের প্রতিটি অনুরোধের জন্য প্রযোজ্য। আপনি যদি বাইরের অনুরোধ এবং একটি পৃথক কল উভয় ক্ষেত্রে একটি প্রদত্ত HTTP শিরোনাম উল্লেখ করেন, তাহলে পৃথক কল হেডারের মান বাইরের ব্যাচ অনুরোধ শিরোনামের মানকে ওভাররাইড করে। একটি পৃথক কলের শিরোনাম শুধুমাত্র সেই কলের জন্য প্রযোজ্য।

উদাহরণস্বরূপ, যদি আপনি একটি নির্দিষ্ট কলের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি শুধুমাত্র সেই কলের জন্য প্রযোজ্য হবে। আপনি যদি বাইরের অনুরোধের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি সমস্ত স্বতন্ত্র কলের ক্ষেত্রে প্রযোজ্য হবে যদি না তারা এটিকে তাদের নিজস্ব অথরাইজেশন হেডার দিয়ে ওভাররাইড করে।

যখন সার্ভার ব্যাচ করা অনুরোধটি পায়, তখন এটি প্রতিটি অংশে বাইরের অনুরোধের ক্যোয়ারী প্যারামিটার এবং শিরোনাম (যথাযথ হিসাবে) প্রয়োগ করে এবং তারপর প্রতিটি অংশকে এমনভাবে আচরণ করে যেন এটি একটি পৃথক HTTP অনুরোধ।

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

সার্ভারের প্রতিক্রিয়া হল multipart/mixed কন্টেন্ট টাইপ সহ একটি একক স্ট্যান্ডার্ড HTTP প্রতিক্রিয়া; প্রতিটি অংশ হল ব্যাচ করা অনুরোধের একটি অনুরোধের প্রতিক্রিয়া, অনুরোধের মতো একই ক্রমে।

অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশে একটি স্ট্যাটাস কোড, হেডার এবং বডি সহ একটি সম্পূর্ণ HTTP প্রতিক্রিয়া রয়েছে৷ এবং অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশের আগে একটি Content-Type শিরোনাম থাকে যা অংশের শুরুতে চিহ্নিত করে।

যদি অনুরোধের একটি প্রদত্ত অংশে একটি Content-ID শিরোনাম থাকে, তাহলে প্রতিক্রিয়াটির সংশ্লিষ্ট অংশে একটি মিলযুক্ত Content-ID শিরোনাম থাকে, যার মূল মান স্ট্রিং response- পূর্বে থাকে-, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে।

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

উদাহরণ

নিচের উদাহরণটি Google Drive API-এর সাথে ব্যাচিংয়ের ব্যবহার দেখায়।

উদাহরণ ব্যাচ অনুরোধ

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8

{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8

{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--

উদাহরণ ব্যাচ প্রতিক্রিয়া

এটি পূর্ববর্তী বিভাগে উদাহরণ অনুরোধের প্রতিক্রিয়া।

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "12218244892818058021i" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "04109509152946699072k" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk--

অনুরোধ থেকে নির্দিষ্ট ক্ষেত্র ফেরত দিন

আপনি যদি fields পরামিতি নির্দিষ্ট না করেন, সার্ভারটি পদ্ধতির জন্য নির্দিষ্ট ক্ষেত্রগুলির একটি ডিফল্ট সেট প্রদান করে। উদাহরণস্বরূপ, files.list পদ্ধতি শুধুমাত্র kind , id , name , এবং mimeType ক্ষেত্রগুলি প্রদান করে৷

প্রত্যাবর্তিত ডিফল্ট ক্ষেত্রগুলি আপনার যা প্রয়োজন তা নাও হতে পারে। আপনি যদি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে চান, fields সিস্টেম প্যারামিটার ব্যবহার করুন। আরও তথ্যের জন্য, নির্দিষ্ট ক্ষেত্র ফেরত দেখুন।

about , comments ( delete ব্যতীত), এবং replies ( delete ব্যতীত) সংস্থানগুলির সমস্ত পদ্ধতির জন্য আপনাকে অবশ্যই fields পরামিতি সেট করতে হবে। এই পদ্ধতিগুলি ক্ষেত্রগুলির একটি ডিফল্ট সেট ফেরত দেয় না।

,

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

জিজিপ ব্যবহার করে কম্প্রেশন

প্রতিটি অনুরোধের জন্য প্রয়োজনীয় ব্যান্ডউইথ কমানোর একটি সহজ এবং সুবিধাজনক উপায় হল জিজিপ কম্প্রেশন সক্ষম করা। যদিও ফলাফলগুলিকে কম্প্রেস করতে এর জন্য অতিরিক্ত CPU সময় প্রয়োজন, নেটওয়ার্ক খরচের সাথে ট্রেড-অফ সাধারণত এটিকে খুব সার্থক করে তোলে।

একটি gzip-এনকোড করা প্রতিক্রিয়া পাওয়ার জন্য আপনাকে দুটি জিনিস করতে হবে: একটি Accept-Encoding শিরোনাম সেট করুন এবং স্ট্রিং gzip ধারণ করতে আপনার ব্যবহারকারী এজেন্টকে পরিবর্তন করুন। এখানে gzip কম্প্রেশন সক্ষম করার জন্য সঠিকভাবে গঠিত HTTP হেডারগুলির একটি উদাহরণ রয়েছে:

Accept-Encoding: gzip
User-Agent: my program (gzip)

আংশিক সম্পদ নিয়ে কাজ করা

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

দুই ধরনের আংশিক অনুরোধ আছে:

  • আংশিক প্রতিক্রিয়া : একটি অনুরোধ যেখানে আপনি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি অন্তর্ভুক্ত করতে হবে তা নির্দিষ্ট করেন ( fields অনুরোধের প্যারামিটার ব্যবহার করুন)।
  • প্যাচ : একটি আপডেট অনুরোধ যেখানে আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তা পাঠান ( PATCH HTTP ক্রিয়া ব্যবহার করুন)।

আংশিক অনুরোধ করার বিষয়ে আরও বিশদ নিম্নলিখিত বিভাগে দেওয়া হয়েছে।

আংশিক প্রতিক্রিয়া

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

একটি আংশিক প্রতিক্রিয়া অনুরোধ করতে, আপনি যে ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে fields অনুরোধ প্যারামিটার ব্যবহার করুন৷ আপনি এই প্যারামিটারটি যেকোন অনুরোধের সাথে ব্যবহার করতে পারেন যা প্রতিক্রিয়া ডেটা প্রদান করে।

মনে রাখবেন যে fields প্যারামিটার শুধুমাত্র প্রতিক্রিয়া ডেটা প্রভাবিত করে; এটি আপনাকে যে ডেটা পাঠাতে হবে তা প্রভাবিত করে না, যদি থাকে। সম্পদ পরিবর্তন করার সময় আপনার পাঠানো ডেটার পরিমাণ কমাতে, একটি প্যাচ অনুরোধ ব্যবহার করুন।

উদাহরণ

প্যাচ (আংশিক আপডেট)

সম্পদ পরিবর্তন করার সময় আপনি অপ্রয়োজনীয় ডেটা পাঠানো এড়াতে পারেন। আপনি যে নির্দিষ্ট ক্ষেত্রে পরিবর্তন করছেন তার জন্য শুধুমাত্র আপডেট করা ডেটা পাঠাতে, HTTP PATCH ক্রিয়া ব্যবহার করুন। এই নথিতে বর্ণিত প্যাচ শব্দার্থবিদ্যা আংশিক আপডেটের পুরোনো, GData বাস্তবায়নের চেয়ে ভিন্ন (এবং সহজ)।

নীচের সংক্ষিপ্ত উদাহরণটি দেখায় কিভাবে প্যাচ ব্যবহার করে একটি ছোট আপডেট করার জন্য আপনাকে যে ডেটা পাঠাতে হবে তা কমিয়ে দেয়।

উদাহরণ

একটি প্যাচ প্রতিক্রিয়া হ্যান্ডলিং

একটি বৈধ প্যাচ অনুরোধ প্রক্রিয়া করার পরে, API পরিবর্তিত সম্পদের সম্পূর্ণ উপস্থাপনা সহ একটি 200 OK HTTP প্রতিক্রিয়া কোড প্রদান করে। যদি ETagsগুলি API দ্বারা ব্যবহার করা হয়, সার্ভারটি ETag মানগুলি আপডেট করে যখন এটি একটি প্যাচ অনুরোধ সফলভাবে প্রক্রিয়া করে, ঠিক যেমন এটি PUT এর সাথে করে।

প্যাচ রিকোয়েস্ট সম্পূর্ণ রিসোর্স রিপ্রেজেন্টেশন রিটার্ন করে যদি না আপনি fields প্যারামিটার ব্যবহার করে ডেটার পরিমাণ কমাতে ব্যবহার করেন।

যদি একটি প্যাচ অনুরোধ একটি নতুন রিসোর্স স্থিতিতে পরিণত হয় যা সিনট্যাক্টিক্যাল বা শব্দার্থগতভাবে অবৈধ, সার্ভারটি একটি 400 Bad Request বা 422 Unprocessable Entity HTTP স্ট্যাটাস কোড ফেরত দেয় এবং রিসোর্স অবস্থা অপরিবর্তিত থাকে। উদাহরণস্বরূপ, যদি আপনি একটি প্রয়োজনীয় ক্ষেত্রের জন্য মান মুছে ফেলার চেষ্টা করেন, সার্ভার একটি ত্রুটি প্রদান করে।

প্যাচ HTTP ক্রিয়া সমর্থিত না হলে বিকল্প স্বরলিপি

যদি আপনার ফায়ারওয়াল HTTP PATCH অনুরোধের অনুমতি না দেয়, তাহলে একটি HTTP POST অনুরোধ করুন এবং ওভাররাইড হেডারটিকে PATCH এ সেট করুন, যেমনটি নীচে দেখানো হয়েছে:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

প্যাচ এবং আপডেটের মধ্যে পার্থক্য

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

এই কারণে প্যাচ ব্যবহার করা অনেক নিরাপদ। আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তার জন্য ডেটা সরবরাহ করুন; আপনি বাদ দেওয়া ক্ষেত্রগুলি সাফ করা হয় না। এই নিয়মের একমাত্র ব্যতিক্রমটি পুনরাবৃত্তি করা উপাদান বা অ্যারেগুলির সাথে ঘটে: আপনি যদি তাদের সবগুলি বাদ দেন তবে তারা যেমন আছে ঠিক তেমনই থাকবে; আপনি যদি তাদের কোনোটি প্রদান করেন, তাহলে পুরো সেটটি আপনার দেওয়া সেট দিয়ে প্রতিস্থাপিত হবে।

ব্যাচ অনুরোধ

এই নথিটি দেখায় যে কীভাবে আপনার ক্লায়েন্টকে HTTP সংযোগগুলি তৈরি করতে হবে তা কমাতে API কলগুলিকে একসাথে ব্যাচ করতে হয়৷

এই নথিটি বিশেষভাবে একটি HTTP অনুরোধ পাঠিয়ে একটি ব্যাচ অনুরোধ করার বিষয়ে। যদি, পরিবর্তে, আপনি একটি ব্যাচ অনুরোধ করতে একটি Google ক্লায়েন্ট লাইব্রেরি ব্যবহার করেন, ক্লায়েন্ট লাইব্রেরির ডকুমেন্টেশন দেখুন।

ওভারভিউ

প্রতিটি HTTP সংযোগ আপনার ক্লায়েন্ট একটি নির্দিষ্ট পরিমাণ ওভারহেড ফলাফল করে। Google ড্রাইভ API ব্যাচিং সমর্থন করে, আপনার ক্লায়েন্টকে একটি একক HTTP অনুরোধে একাধিক API কল করার অনুমতি দিতে।

আপনি যখন ব্যাচিং ব্যবহার করতে চাইতে পারেন এমন পরিস্থিতির উদাহরণ:

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

প্রতিটি ক্ষেত্রে, প্রতিটি কল আলাদাভাবে পাঠানোর পরিবর্তে, আপনি একটি একক HTTP অনুরোধে তাদের একসাথে গোষ্ঠী করতে পারেন। সমস্ত অভ্যন্তরীণ অনুরোধ একই Google API এ যেতে হবে।

আপনি একটি একক ব্যাচ অনুরোধে 100টি কলের মধ্যে সীমাবদ্ধ। আপনি যদি এর চেয়ে বেশি কল করতে চান তবে একাধিক ব্যাচ অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : Google Drive API-এর ব্যাচ সিস্টেম OData ব্যাচ প্রসেসিং সিস্টেমের মতো একই সিনট্যাক্স ব্যবহার করে, কিন্তু শব্দার্থবিদ্যা আলাদা।

অতিরিক্ত সীমাবদ্ধতা অন্তর্ভুক্ত:

  • 100 টির বেশি কল সহ ব্যাচের অনুরোধগুলি একটি ত্রুটির কারণ হতে পারে৷
  • প্রতিটি অভ্যন্তরীণ অনুরোধের জন্য URL-এর দৈর্ঘ্যে একটি 8,000 অক্ষরের সীমা রয়েছে৷
  • Google ড্রাইভ মিডিয়ার জন্য ব্যাচ অপারেশন সমর্থন করে না, হয় আপলোড বা ডাউনলোডের জন্য বা ফাইল রপ্তানির জন্য।

ব্যাচের বিবরণ

একটি ব্যাচ অনুরোধে একাধিক API কল থাকে যা একটি HTTP অনুরোধের সাথে মিলিত হয়, যা API আবিষ্কার নথিতে নির্দিষ্ট batchPath পাঠানো যেতে পারে। ডিফল্ট পাথ হল /batch/ api_name / api_version । এই বিভাগে ব্যাচ সিনট্যাক্স বিস্তারিতভাবে বর্ণনা করে; পরে, একটি উদাহরণ আছে.

দ্রষ্টব্য : একত্রে ব্যাচ করা n অনুরোধের একটি সেট আপনার ব্যবহারের সীমা n অনুরোধ হিসাবে গণনা করে, একটি অনুরোধ হিসাবে নয়। ব্যাচ অনুরোধ প্রক্রিয়াকরণের আগে অনুরোধের একটি সেট মধ্যে বিভক্ত করা হয়.

একটি ব্যাচ অনুরোধের বিন্যাস

একটি ব্যাচ অনুরোধ হল একটি একক স্ট্যান্ডার্ড HTTP অনুরোধ যাতে একাধিক Google ড্রাইভ API কল থাকে, multipart/mixed সামগ্রীর ধরন ব্যবহার করে। সেই প্রধান HTTP অনুরোধের মধ্যে, প্রতিটি অংশে একটি নেস্টেড HTTP অনুরোধ থাকে।

প্রতিটি অংশ তার নিজস্ব Content-Type: application/http HTTP হেডার। এটিতে একটি ঐচ্ছিক Content-ID শিরোনামও থাকতে পারে। যাইহোক, অংশের শিরোনামগুলি শুধুমাত্র অংশের শুরুতে চিহ্নিত করার জন্য রয়েছে; তারা নেস্টেড অনুরোধ থেকে আলাদা। সার্ভার ব্যাচের অনুরোধটিকে পৃথক অনুরোধে আনর্যাপ করার পরে, অংশ শিরোনামগুলি উপেক্ষা করা হয়।

প্রতিটি অংশের মূল অংশটি একটি সম্পূর্ণ HTTP অনুরোধ, যার নিজস্ব ক্রিয়া, URL, শিরোনাম এবং বডি রয়েছে। HTTP অনুরোধে শুধুমাত্র URL এর পাথ অংশ থাকতে হবে; ব্যাচ অনুরোধে সম্পূর্ণ URL গুলি অনুমোদিত নয়৷

বাইরের ব্যাচের অনুরোধের জন্য HTTP শিরোনামগুলি, Content- -শিরোনামগুলি ব্যতীত যেমন Content-Type , ব্যাচের প্রতিটি অনুরোধের জন্য প্রযোজ্য। আপনি যদি বাইরের অনুরোধ এবং একটি পৃথক কল উভয় ক্ষেত্রে একটি প্রদত্ত HTTP শিরোনাম উল্লেখ করেন, তাহলে পৃথক কল হেডারের মান বাইরের ব্যাচ অনুরোধ শিরোনামের মানকে ওভাররাইড করে। একটি পৃথক কলের শিরোনাম শুধুমাত্র সেই কলের জন্য প্রযোজ্য।

উদাহরণস্বরূপ, যদি আপনি একটি নির্দিষ্ট কলের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি শুধুমাত্র সেই কলের জন্য প্রযোজ্য হবে। আপনি যদি বাইরের অনুরোধের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি সমস্ত স্বতন্ত্র কলের ক্ষেত্রে প্রযোজ্য হবে যদি না তারা এটিকে তাদের নিজস্ব অথরাইজেশন হেডার দিয়ে ওভাররাইড করে।

যখন সার্ভার ব্যাচ করা অনুরোধটি পায়, তখন এটি প্রতিটি অংশে বাইরের অনুরোধের ক্যোয়ারী প্যারামিটার এবং শিরোনাম (যথাযথ হিসাবে) প্রয়োগ করে এবং তারপর প্রতিটি অংশকে এমনভাবে আচরণ করে যেন এটি একটি পৃথক HTTP অনুরোধ।

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

সার্ভারের প্রতিক্রিয়া হল multipart/mixed কন্টেন্ট টাইপ সহ একটি একক স্ট্যান্ডার্ড HTTP প্রতিক্রিয়া; প্রতিটি অংশ হল ব্যাচ করা অনুরোধের একটি অনুরোধের প্রতিক্রিয়া, অনুরোধের মতো একই ক্রমে।

অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশে একটি স্ট্যাটাস কোড, হেডার এবং বডি সহ একটি সম্পূর্ণ HTTP প্রতিক্রিয়া রয়েছে৷ এবং অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশের আগে একটি Content-Type শিরোনাম থাকে যা অংশের শুরুতে চিহ্নিত করে।

যদি অনুরোধের একটি প্রদত্ত অংশে একটি Content-ID শিরোনাম থাকে, তাহলে প্রতিক্রিয়াটির সংশ্লিষ্ট অংশে একটি মিলযুক্ত Content-ID শিরোনাম থাকে, যার মূল মান স্ট্রিং response- পূর্বে থাকে-, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে।

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

উদাহরণ

নিচের উদাহরণটি Google Drive API-এর সাথে ব্যাচিংয়ের ব্যবহার দেখায়।

উদাহরণ ব্যাচ অনুরোধ

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8

{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8

{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--

উদাহরণ ব্যাচ প্রতিক্রিয়া

এটি পূর্ববর্তী বিভাগে উদাহরণ অনুরোধের প্রতিক্রিয়া।

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "12218244892818058021i" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "04109509152946699072k" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk--

অনুরোধ থেকে নির্দিষ্ট ক্ষেত্র ফেরত দিন

আপনি যদি fields পরামিতি নির্দিষ্ট না করেন, সার্ভারটি পদ্ধতির জন্য নির্দিষ্ট ক্ষেত্রগুলির একটি ডিফল্ট সেট প্রদান করে। উদাহরণস্বরূপ, files.list পদ্ধতি শুধুমাত্র kind , id , name , এবং mimeType ক্ষেত্রগুলি প্রদান করে৷

প্রত্যাবর্তিত ডিফল্ট ক্ষেত্রগুলি আপনার যা প্রয়োজন তা নাও হতে পারে। আপনি যদি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে চান, fields সিস্টেম প্যারামিটার ব্যবহার করুন। আরও তথ্যের জন্য, নির্দিষ্ট ক্ষেত্র ফেরত দেখুন।

about , comments ( delete ব্যতীত), এবং replies ( delete ব্যতীত) সংস্থানগুলির সমস্ত পদ্ধতির জন্য আপনাকে অবশ্যই fields পরামিতি সেট করতে হবে। এই পদ্ধতিগুলি ক্ষেত্রগুলির একটি ডিফল্ট সেট ফেরত দেয় না।

,

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

জিজিপ ব্যবহার করে কম্প্রেশন

প্রতিটি অনুরোধের জন্য প্রয়োজনীয় ব্যান্ডউইথ কমানোর একটি সহজ এবং সুবিধাজনক উপায় হল জিজিপ কম্প্রেশন সক্ষম করা। যদিও ফলাফলগুলিকে কম্প্রেস করতে এর জন্য অতিরিক্ত CPU সময় প্রয়োজন, নেটওয়ার্ক খরচের সাথে ট্রেড-অফ সাধারণত এটিকে খুব সার্থক করে তোলে।

একটি gzip-এনকোড করা প্রতিক্রিয়া পাওয়ার জন্য আপনাকে দুটি জিনিস করতে হবে: একটি Accept-Encoding শিরোনাম সেট করুন এবং স্ট্রিং gzip ধারণ করতে আপনার ব্যবহারকারী এজেন্টকে পরিবর্তন করুন। এখানে gzip কম্প্রেশন সক্ষম করার জন্য সঠিকভাবে গঠিত HTTP হেডারগুলির একটি উদাহরণ রয়েছে:

Accept-Encoding: gzip
User-Agent: my program (gzip)

আংশিক সম্পদ নিয়ে কাজ করা

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

দুই ধরনের আংশিক অনুরোধ আছে:

  • আংশিক প্রতিক্রিয়া : একটি অনুরোধ যেখানে আপনি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি অন্তর্ভুক্ত করতে হবে তা নির্দিষ্ট করেন ( fields অনুরোধের প্যারামিটার ব্যবহার করুন)।
  • প্যাচ : একটি আপডেট অনুরোধ যেখানে আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তা পাঠান ( PATCH HTTP ক্রিয়া ব্যবহার করুন)।

আংশিক অনুরোধ করার বিষয়ে আরও বিশদ নিম্নলিখিত বিভাগে দেওয়া হয়েছে।

আংশিক প্রতিক্রিয়া

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

একটি আংশিক প্রতিক্রিয়া অনুরোধ করতে, আপনি যে ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে fields অনুরোধ প্যারামিটার ব্যবহার করুন৷ আপনি এই প্যারামিটারটি যেকোন অনুরোধের সাথে ব্যবহার করতে পারেন যা প্রতিক্রিয়া ডেটা প্রদান করে।

মনে রাখবেন যে fields প্যারামিটার শুধুমাত্র প্রতিক্রিয়া ডেটা প্রভাবিত করে; এটি আপনাকে যে ডেটা পাঠাতে হবে তা প্রভাবিত করে না, যদি থাকে। সম্পদ পরিবর্তন করার সময় আপনার পাঠানো ডেটার পরিমাণ কমাতে, একটি প্যাচ অনুরোধ ব্যবহার করুন।

উদাহরণ

প্যাচ (আংশিক আপডেট)

সম্পদ পরিবর্তন করার সময় আপনি অপ্রয়োজনীয় ডেটা পাঠানো এড়াতে পারেন। আপনি যে নির্দিষ্ট ক্ষেত্রে পরিবর্তন করছেন তার জন্য শুধুমাত্র আপডেট করা ডেটা পাঠাতে, HTTP PATCH ক্রিয়া ব্যবহার করুন। এই নথিতে বর্ণিত প্যাচ শব্দার্থবিদ্যা আংশিক আপডেটের পুরোনো, GData বাস্তবায়নের চেয়ে ভিন্ন (এবং সহজ)।

নীচের সংক্ষিপ্ত উদাহরণটি দেখায় কিভাবে প্যাচ ব্যবহার করে একটি ছোট আপডেট করার জন্য আপনাকে যে ডেটা পাঠাতে হবে তা কমিয়ে দেয়।

উদাহরণ

একটি প্যাচ প্রতিক্রিয়া হ্যান্ডলিং

একটি বৈধ প্যাচ অনুরোধ প্রক্রিয়া করার পরে, API পরিবর্তিত সম্পদের সম্পূর্ণ উপস্থাপনা সহ একটি 200 OK HTTP প্রতিক্রিয়া কোড প্রদান করে। যদি ETagsগুলি API দ্বারা ব্যবহার করা হয়, সার্ভারটি ETag মানগুলি আপডেট করে যখন এটি একটি প্যাচ অনুরোধ সফলভাবে প্রক্রিয়া করে, ঠিক যেমন এটি PUT এর সাথে করে।

প্যাচ রিকোয়েস্ট সম্পূর্ণ রিসোর্স রিপ্রেজেন্টেশন রিটার্ন করে যদি না আপনি fields প্যারামিটার ব্যবহার করে ডেটার পরিমাণ কমাতে ব্যবহার করেন।

যদি একটি প্যাচ অনুরোধ একটি নতুন রিসোর্স স্থিতিতে পরিণত হয় যা সিনট্যাক্টিক্যাল বা শব্দার্থগতভাবে অবৈধ, সার্ভারটি একটি 400 Bad Request বা 422 Unprocessable Entity HTTP স্ট্যাটাস কোড ফেরত দেয় এবং রিসোর্স অবস্থা অপরিবর্তিত থাকে। উদাহরণস্বরূপ, যদি আপনি একটি প্রয়োজনীয় ক্ষেত্রের জন্য মান মুছে ফেলার চেষ্টা করেন, সার্ভার একটি ত্রুটি প্রদান করে।

প্যাচ HTTP ক্রিয়া সমর্থিত না হলে বিকল্প স্বরলিপি

যদি আপনার ফায়ারওয়াল HTTP PATCH অনুরোধের অনুমতি না দেয়, তাহলে একটি HTTP POST অনুরোধ করুন এবং ওভাররাইড হেডারটিকে PATCH এ সেট করুন, যেমনটি নীচে দেখানো হয়েছে:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

প্যাচ এবং আপডেটের মধ্যে পার্থক্য

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

এই কারণে প্যাচ ব্যবহার করা অনেক নিরাপদ। আপনি শুধুমাত্র যে ক্ষেত্রগুলি পরিবর্তন করতে চান তার জন্য ডেটা সরবরাহ করুন; আপনি বাদ দেওয়া ক্ষেত্রগুলি সাফ করা হয় না। এই নিয়মের একমাত্র ব্যতিক্রমটি পুনরাবৃত্তি করা উপাদান বা অ্যারেগুলির সাথে ঘটে: আপনি যদি তাদের সবগুলি বাদ দেন তবে তারা যেমন আছে ঠিক তেমনই থাকবে; আপনি যদি তাদের কোনোটি প্রদান করেন, তাহলে পুরো সেটটি আপনার দেওয়া সেট দিয়ে প্রতিস্থাপিত হবে।

ব্যাচ অনুরোধ

এই নথিটি দেখায় যে কীভাবে আপনার ক্লায়েন্টকে HTTP সংযোগগুলি তৈরি করতে হবে তা কমাতে API কলগুলিকে একসাথে ব্যাচ করতে হয়৷

এই নথিটি বিশেষভাবে একটি HTTP অনুরোধ পাঠিয়ে একটি ব্যাচ অনুরোধ করার বিষয়ে। যদি, পরিবর্তে, আপনি একটি ব্যাচ অনুরোধ করতে একটি Google ক্লায়েন্ট লাইব্রেরি ব্যবহার করেন, ক্লায়েন্ট লাইব্রেরির ডকুমেন্টেশন দেখুন।

ওভারভিউ

প্রতিটি HTTP সংযোগ আপনার ক্লায়েন্ট একটি নির্দিষ্ট পরিমাণ ওভারহেড ফলাফল করে। Google ড্রাইভ API ব্যাচিং সমর্থন করে, আপনার ক্লায়েন্টকে একটি একক HTTP অনুরোধে একাধিক API কল করার অনুমতি দিতে।

আপনি যখন ব্যাচিং ব্যবহার করতে চাইতে পারেন এমন পরিস্থিতির উদাহরণ:

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

প্রতিটি ক্ষেত্রে, প্রতিটি কল আলাদাভাবে পাঠানোর পরিবর্তে, আপনি একটি একক HTTP অনুরোধে তাদের একসাথে গোষ্ঠী করতে পারেন। সমস্ত অভ্যন্তরীণ অনুরোধ একই Google API এ যেতে হবে।

আপনি একটি একক ব্যাচ অনুরোধে 100টি কলের মধ্যে সীমাবদ্ধ। আপনি যদি এর চেয়ে বেশি কল করতে চান তবে একাধিক ব্যাচ অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : Google Drive API-এর ব্যাচ সিস্টেম OData ব্যাচ প্রসেসিং সিস্টেমের মতো একই সিনট্যাক্স ব্যবহার করে, কিন্তু শব্দার্থবিদ্যা আলাদা।

অতিরিক্ত সীমাবদ্ধতা অন্তর্ভুক্ত:

  • 100 টির বেশি কল সহ ব্যাচের অনুরোধগুলি একটি ত্রুটির কারণ হতে পারে৷
  • প্রতিটি অভ্যন্তরীণ অনুরোধের জন্য URL-এর দৈর্ঘ্যে একটি 8,000 অক্ষরের সীমা রয়েছে৷
  • Google ড্রাইভ মিডিয়ার জন্য ব্যাচ অপারেশন সমর্থন করে না, হয় আপলোড বা ডাউনলোডের জন্য বা ফাইল রপ্তানির জন্য।

ব্যাচের বিবরণ

একটি ব্যাচ অনুরোধে একাধিক API কল থাকে যা একটি HTTP অনুরোধের সাথে মিলিত হয়, যা API আবিষ্কার নথিতে নির্দিষ্ট batchPath পাঠানো যেতে পারে। ডিফল্ট পাথ হল /batch/ api_name / api_version । এই বিভাগে ব্যাচ সিনট্যাক্স বিস্তারিতভাবে বর্ণনা করে; পরে, একটি উদাহরণ আছে.

দ্রষ্টব্য : একত্রে ব্যাচ করা n অনুরোধের একটি সেট আপনার ব্যবহারের সীমা n অনুরোধ হিসাবে গণনা করে, একটি অনুরোধ হিসাবে নয়। ব্যাচ অনুরোধ প্রক্রিয়াকরণের আগে অনুরোধের একটি সেট মধ্যে বিভক্ত করা হয়.

একটি ব্যাচ অনুরোধের বিন্যাস

একটি ব্যাচ অনুরোধ হল একটি একক স্ট্যান্ডার্ড HTTP অনুরোধ যাতে একাধিক Google ড্রাইভ API কল থাকে, multipart/mixed সামগ্রীর ধরন ব্যবহার করে। সেই প্রধান HTTP অনুরোধের মধ্যে, প্রতিটি অংশে একটি নেস্টেড HTTP অনুরোধ থাকে।

প্রতিটি অংশ তার নিজস্ব Content-Type: application/http HTTP হেডার। এটিতে একটি ঐচ্ছিক Content-ID শিরোনামও থাকতে পারে। যাইহোক, অংশের শিরোনামগুলি শুধুমাত্র অংশের শুরুতে চিহ্নিত করার জন্য রয়েছে; তারা নেস্টেড অনুরোধ থেকে আলাদা। সার্ভার ব্যাচের অনুরোধটিকে পৃথক অনুরোধে আনর্যাপ করার পরে, অংশ শিরোনামগুলি উপেক্ষা করা হয়।

প্রতিটি অংশের মূল অংশটি একটি সম্পূর্ণ HTTP অনুরোধ, যার নিজস্ব ক্রিয়া, URL, শিরোনাম এবং বডি রয়েছে। HTTP অনুরোধে শুধুমাত্র URL এর পাথ অংশ থাকতে হবে; ব্যাচ অনুরোধে সম্পূর্ণ URL গুলি অনুমোদিত নয়৷

বাইরের ব্যাচের অনুরোধের জন্য HTTP শিরোনামগুলি, Content- -শিরোনামগুলি ব্যতীত যেমন Content-Type , ব্যাচের প্রতিটি অনুরোধের জন্য প্রযোজ্য। আপনি যদি বাইরের অনুরোধ এবং একটি পৃথক কল উভয় ক্ষেত্রে একটি প্রদত্ত HTTP শিরোনাম উল্লেখ করেন, তাহলে পৃথক কল হেডারের মান বাইরের ব্যাচ অনুরোধ শিরোনামের মানকে ওভাররাইড করে। একটি পৃথক কলের শিরোনাম শুধুমাত্র সেই কলের জন্য প্রযোজ্য।

উদাহরণস্বরূপ, যদি আপনি একটি নির্দিষ্ট কলের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি শুধুমাত্র সেই কলের জন্য প্রযোজ্য হবে। আপনি যদি বাইরের অনুরোধের জন্য একটি অনুমোদন শিরোনাম প্রদান করেন, তাহলে সেই শিরোনামটি সমস্ত স্বতন্ত্র কলের ক্ষেত্রে প্রযোজ্য হবে যদি না তারা এটিকে তাদের নিজস্ব অথরাইজেশন হেডার দিয়ে ওভাররাইড করে।

যখন সার্ভার ব্যাচ করা অনুরোধটি পায়, তখন এটি প্রতিটি অংশে বাইরের অনুরোধের ক্যোয়ারী প্যারামিটার এবং শিরোনাম (যথাযথ হিসাবে) প্রয়োগ করে এবং তারপর প্রতিটি অংশকে এমনভাবে আচরণ করে যেন এটি একটি পৃথক HTTP অনুরোধ।

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

সার্ভারের প্রতিক্রিয়া হল multipart/mixed কন্টেন্ট টাইপ সহ একটি একক স্ট্যান্ডার্ড HTTP প্রতিক্রিয়া; প্রতিটি অংশ হল ব্যাচ করা অনুরোধের একটি অনুরোধের প্রতিক্রিয়া, অনুরোধের মতো একই ক্রমে।

অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশে একটি স্ট্যাটাস কোড, হেডার এবং বডি সহ একটি সম্পূর্ণ HTTP প্রতিক্রিয়া রয়েছে৷ এবং অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশের আগে একটি Content-Type শিরোনাম থাকে যা অংশের শুরুতে চিহ্নিত করে।

যদি অনুরোধের একটি প্রদত্ত অংশে একটি Content-ID শিরোনাম থাকে, তাহলে প্রতিক্রিয়াটির সংশ্লিষ্ট অংশে একটি মিলযুক্ত Content-ID শিরোনাম থাকে, যার মূল মান স্ট্রিং response- পূর্বে থাকে-, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে।

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

উদাহরণ

নিচের উদাহরণটি Google Drive API-এর সাথে ব্যাচিংয়ের ব্যবহার দেখায়।

উদাহরণ ব্যাচ অনুরোধ

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8

{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8

{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--

উদাহরণ ব্যাচ প্রতিক্রিয়া

এটি পূর্ববর্তী বিভাগে উদাহরণ অনুরোধের প্রতিক্রিয়া।

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "12218244892818058021i" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "04109509152946699072k" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk--

অনুরোধ থেকে নির্দিষ্ট ক্ষেত্র ফেরত দিন

আপনি যদি fields পরামিতি নির্দিষ্ট না করেন, সার্ভারটি পদ্ধতির জন্য নির্দিষ্ট ক্ষেত্রগুলির একটি ডিফল্ট সেট প্রদান করে। উদাহরণস্বরূপ, files.list পদ্ধতি শুধুমাত্র kind , id , name , এবং mimeType ক্ষেত্রগুলি প্রদান করে৷

প্রত্যাবর্তিত ডিফল্ট ক্ষেত্রগুলি আপনার যা প্রয়োজন তা নাও হতে পারে। আপনি যদি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি ফেরত দিতে চান তা নির্দিষ্ট করতে চান, fields সিস্টেম প্যারামিটার ব্যবহার করুন। আরও তথ্যের জন্য, নির্দিষ্ট ক্ষেত্র ফেরত দেখুন।

about , comments ( delete ব্যতীত), এবং replies ( delete ব্যতীত) সংস্থানগুলির সমস্ত পদ্ধতির জন্য আপনাকে অবশ্যই fields পরামিতি সেট করতে হবে। এই পদ্ধতিগুলি ক্ষেত্রগুলির একটি ডিফল্ট সেট ফেরত দেয় না।

,

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

জিজিপ ব্যবহার করে কম্প্রেশন

প্রতিটি অনুরোধের জন্য প্রয়োজনীয় ব্যান্ডউইথ কমানোর একটি সহজ এবং সুবিধাজনক উপায় হল জিজিপ কম্প্রেশন সক্ষম করা। যদিও ফলাফলগুলিকে কম্প্রেস করতে এর জন্য অতিরিক্ত CPU সময় প্রয়োজন, নেটওয়ার্ক খরচের সাথে ট্রেড-অফ সাধারণত এটিকে খুব সার্থক করে তোলে।

একটি gzip-এনকোড করা প্রতিক্রিয়া পাওয়ার জন্য আপনাকে দুটি জিনিস করতে হবে: একটি Accept-Encoding শিরোনাম সেট করুন এবং স্ট্রিং gzip ধারণ করতে আপনার ব্যবহারকারী এজেন্টকে পরিবর্তন করুন। এখানে gzip কম্প্রেশন সক্ষম করার জন্য সঠিকভাবে গঠিত HTTP হেডারগুলির একটি উদাহরণ রয়েছে:

Accept-Encoding: gzip
User-Agent: my program (gzip)

আংশিক সম্পদ নিয়ে কাজ করা

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

দুই ধরনের আংশিক অনুরোধ আছে:

  • আংশিক প্রতিক্রিয়া : একটি অনুরোধ যেখানে আপনি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি অন্তর্ভুক্ত করতে হবে তা নির্দিষ্ট করেন ( fields অনুরোধের প্যারামিটার ব্যবহার করুন)।
  • প্যাচ : একটি আপডেটের অনুরোধ যেখানে আপনি কেবল ক্ষেত্রগুলি পরিবর্তন করতে চান তা প্রেরণ করুন ( PATCH এইচটিটিপি ক্রিয়াটি ব্যবহার করুন)।

আংশিক অনুরোধ করার বিষয়ে আরও বিশদ নিম্নলিখিত বিভাগগুলিতে সরবরাহ করা হয়েছে।

আংশিক প্রতিক্রিয়া

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

আংশিক প্রতিক্রিয়ার জন্য অনুরোধ করতে, আপনি যে ক্ষেত্রগুলি ফিরে আসতে চান তা নির্দিষ্ট করতে fields অনুরোধ প্যারামিটারটি ব্যবহার করুন। প্রতিক্রিয়া ডেটা ফেরত দেয় এমন কোনও অনুরোধের সাথে আপনি এই প্যারামিটারটি ব্যবহার করতে পারেন।

নোট করুন যে fields প্যারামিটারটি কেবল প্রতিক্রিয়া ডেটা প্রভাবিত করে; এটি আপনাকে যে ডেটা প্রেরণ করতে হবে তা প্রভাবিত করে না, যদি থাকে। সংস্থানগুলি সংশোধন করার সময় আপনি যে পরিমাণ ডেটা প্রেরণ করেন তা হ্রাস করতে, প্যাচ অনুরোধটি ব্যবহার করুন।

উদাহরণ

প্যাচ (আংশিক আপডেট)

সংস্থানগুলি সংশোধন করার সময় আপনি অপ্রয়োজনীয় ডেটা প্রেরণ এড়াতে পারেন। আপনি যে নির্দিষ্ট ক্ষেত্রগুলি পরিবর্তন করছেন তার জন্য আপডেট হওয়া ডেটা প্রেরণ করতে, এইচটিটিপি PATCH ভার ব্যবহার করুন। এই দস্তাবেজে বর্ণিত প্যাচ শব্দার্থবিজ্ঞানগুলি আংশিক আপডেটের পুরানো, জিডিএটিএ বাস্তবায়নের চেয়ে আলাদা (এবং সহজ)।

নীচের সংক্ষিপ্ত উদাহরণটি দেখায় যে কীভাবে প্যাচ ব্যবহার করা একটি ছোট আপডেট করার জন্য আপনার যে ডেটা প্রেরণ করতে হবে তা হ্রাস করে।

উদাহরণ

একটি প্যাচ প্রতিক্রিয়া পরিচালনা করা

একটি বৈধ প্যাচ অনুরোধ প্রক্রিয়া করার পরে, এপিআই পরিবর্তিত সংস্থানটির সম্পূর্ণ উপস্থাপনা সহ 200 OK এইচটিটিপি প্রতিক্রিয়া কোডটি প্রদান করে। যদি ইটিএজিগুলি এপিআই দ্বারা ব্যবহৃত হয়, সার্ভারটি ইটিএজি মানগুলি আপডেট করে যখন এটি সফলভাবে কোনও প্যাচ অনুরোধ প্রক্রিয়া করে, ঠিক যেমনটি এটি করে PUT

প্যাচ অনুরোধটি পুরো রিসোর্সের প্রতিনিধিত্বকে ফেরত দেয় যদি না আপনি এটি যে পরিমাণ ডেটা ফেরত দেয় তার পরিমাণ হ্রাস করতে fields প্যারামিটার ব্যবহার না করে।

যদি কোনও প্যাচ অনুরোধের ফলে কোনও নতুন সংস্থানীয় অবস্থার ফলাফল হয় যা সিনট্যাকটিক্যালি বা শব্দার্থগতভাবে অবৈধ হয় তবে সার্ভারটি একটি 400 Bad Request বা 422 Unprocessable Entity এইচটিটিপি স্ট্যাটাস কোডটি দেয় এবং রিসোর্স স্টেটটি অপরিবর্তিত থাকে। উদাহরণস্বরূপ, আপনি যদি কোনও প্রয়োজনীয় ক্ষেত্রের জন্য মান মুছে ফেলার চেষ্টা করেন তবে সার্ভার একটি ত্রুটি ফেরত দেয়।

প্যাচ এইচটিটিপি ক্রিয়াটি সমর্থিত না হলে বিকল্প স্বরলিপি

যদি আপনার ফায়ারওয়াল HTTP PATCH অনুরোধগুলির অনুমতি না দেয় তবে একটি এইচটিটিপি POST অনুরোধটি করুন এবং ওভাররাইড শিরোনামটি PATCH সেট করুন, নীচে দেখানো হয়েছে:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

প্যাচ এবং আপডেটের মধ্যে পার্থক্য

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

এই কারণে প্যাচ ব্যবহার করা অনেক বেশি নিরাপদ। আপনি যে ক্ষেত্রগুলি পরিবর্তন করতে চান তার জন্য আপনি কেবল ডেটা সরবরাহ করেন; আপনি বাদ দেওয়া ক্ষেত্রগুলি সাফ করা হয় না। এই নিয়মের একমাত্র ব্যতিক্রম পুনরাবৃত্তি উপাদান বা অ্যারেগুলির সাথে ঘটে: আপনি যদি সেগুলি সমস্ত বাদ দেন তবে তারা যেমন থাকে ঠিক তেমনই থাকে; আপনি যদি সেগুলির কোনও সরবরাহ করেন তবে পুরো সেটটি আপনার সরবরাহ করা সেটটি প্রতিস্থাপন করা হয়েছে।

ব্যাচ অনুরোধ

এই দস্তাবেজটি দেখায় যে কীভাবে ব্যাচ এপিআই কলগুলি একসাথে আপনার ক্লায়েন্টকে যে এইচটিটিপি সংযোগগুলি তৈরি করতে হবে তার সংখ্যা হ্রাস করতে।

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

ওভারভিউ

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

পরিস্থিতিগুলির উদাহরণ যখন আপনি ব্যাচিং ব্যবহার করতে চাইতে পারেন:

  • বিপুল সংখ্যক ফাইলের জন্য মেটাডেটা পুনরুদ্ধার করা।
  • বাল্কে মেটাডেটা বা সম্পত্তি আপডেট করা।
  • বিপুল সংখ্যক ফাইলের জন্য অনুমতি পরিবর্তন করা, যেমন কোনও নতুন ব্যবহারকারী বা গোষ্ঠী যুক্ত করা।
  • প্রথমবারের জন্য বা বর্ধিত সময়ের জন্য অফলাইনে থাকার পরে স্থানীয় ক্লায়েন্টের ডেটা সিঙ্ক্রোনাইজ করা।

প্রতিটি ক্ষেত্রে, প্রতিটি কল আলাদাভাবে প্রেরণের পরিবর্তে, আপনি এগুলিকে একটি একক এইচটিটিপি অনুরোধে একত্রিত করতে পারেন। সমস্ত অভ্যন্তরীণ অনুরোধগুলি অবশ্যই একই গুগল এপিআইতে যেতে হবে।

আপনি একটি একক ব্যাচের অনুরোধে 100 কলগুলিতে সীমাবদ্ধ। যদি আপনার অবশ্যই এর চেয়ে আরও বেশি কল করতে হয় তবে একাধিক ব্যাচের অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : গুগল ড্রাইভ এপিআইয়ের ব্যাচ সিস্টেমটি ওডাটা ব্যাচ প্রসেসিং সিস্টেমের মতো একই সিনট্যাক্স ব্যবহার করে তবে শব্দার্থবিজ্ঞান পৃথক।

অতিরিক্ত সীমাবদ্ধতা অন্তর্ভুক্ত:

  • 100 টিরও বেশি কল সহ ব্যাচের অনুরোধগুলি একটি ত্রুটির কারণ হতে পারে।
  • প্রতিটি অভ্যন্তরীণ অনুরোধের জন্য URL এর দৈর্ঘ্যের উপর একটি 8,000 চরিত্রের সীমা রয়েছে।
  • গুগল ড্রাইভ মিডিয়াগুলির জন্য ব্যাচ অপারেশনগুলিকে সমর্থন করে না, হয় আপলোড বা ডাউনলোডের জন্য, বা ফাইল রফতানির জন্য।

ব্যাচের বিশদ

একটি ব্যাচের অনুরোধে একটি এইচটিটিপি অনুরোধের সাথে মিলিত একাধিক এপিআই কল রয়েছে, যা এপিআই আবিষ্কারের নথিতে নির্দিষ্ট করা batchPath প্রেরণ করা যেতে পারে। ডিফল্ট পথটি /batch/ api_name / api_version । এই বিভাগটি ব্যাচ সিনট্যাক্সটি বিশদভাবে বর্ণনা করে; পরে, একটি উদাহরণ আছে।

দ্রষ্টব্য : n অনুরোধগুলির একটি সেট একসাথে আপনার ব্যবহারের সীমা হিসাবে n অনুরোধ হিসাবে গণনা করে, একটি অনুরোধ হিসাবে নয়। ব্যাচের অনুরোধটি প্রক্রিয়াজাতকরণের আগে অনুরোধের একটি সেটে পৃথক করা হয়।

একটি ব্যাচের অনুরোধের ফর্ম্যাট

একটি ব্যাচের অনুরোধ হ'ল একাধিক গুগল ড্রাইভ এপিআই কলগুলি সমন্বিত একটি একক স্ট্যান্ডার্ড এইচটিটিপি অনুরোধ, multipart/mixed সামগ্রীর ধরণটি ব্যবহার করে। সেই প্রধান এইচটিটিপি অনুরোধের মধ্যে, প্রতিটি অংশে একটি নেস্টেড এইচটিটিপি অনুরোধ রয়েছে।

প্রতিটি অংশ তার নিজস্ব Content-Type: application/http এইচটিটিপি শিরোনাম। এটিতে একটি al চ্ছিক Content-ID শিরোনামও থাকতে পারে। যাইহোক, অংশের শিরোনামগুলি কেবল অংশের শুরুটি চিহ্নিত করার জন্য রয়েছে; তারা নেস্টেড অনুরোধ থেকে পৃথক। সার্ভারটি ব্যাচের অনুরোধটি পৃথক অনুরোধগুলিতে মোড়ক দেওয়ার পরে, অংশ শিরোনামগুলি উপেক্ষা করা হয়।

প্রতিটি অংশের দেহটি একটি সম্পূর্ণ HTTP অনুরোধ, যার নিজস্ব ক্রিয়া, ইউআরএল, শিরোনাম এবং শরীর সহ। এইচটিটিপি অনুরোধে কেবলমাত্র URL এর পাথ অংশ থাকতে হবে; ব্যাচের অনুরোধে পূর্ণ URL টি অনুমোদিত নয়।

Content-Type মতো Content- -শিরোনাম ব্যতীত বাইরের ব্যাচের অনুরোধের জন্য এইচটিটিপি শিরোনামগুলি ব্যাচের প্রতিটি অনুরোধে প্রয়োগ করে। যদি আপনি বাইরের অনুরোধ এবং পৃথক কল উভয় ক্ষেত্রেই প্রদত্ত এইচটিটিপি শিরোনাম নির্দিষ্ট করে থাকেন তবে পৃথক কল শিরোনামের মানটি বাইরের ব্যাচের অনুরোধের শিরোনামটির মানকে ওভাররাইড করে। একটি পৃথক কলের শিরোনামগুলি কেবল সেই কলটিতে প্রযোজ্য।

উদাহরণস্বরূপ, আপনি যদি কোনও নির্দিষ্ট কলের জন্য কোনও অনুমোদনের শিরোনাম সরবরাহ করেন তবে সেই শিরোনামটি কেবল সেই কলটিতে প্রযোজ্য। যদি আপনি বাইরের অনুরোধের জন্য কোনও অনুমোদনের শিরোনাম সরবরাহ করেন তবে সেই শিরোনামটি পৃথক কলগুলির সমস্ত ক্ষেত্রে প্রযোজ্য যদি না তারা এটিকে তাদের নিজস্ব অনুমোদনের শিরোনামগুলির সাথে ওভাররাইড করে।

যখন সার্ভারটি ব্যাচড অনুরোধটি গ্রহণ করে, এটি প্রতিটি অংশের জন্য বাইরের অনুরোধের ক্যোয়ারী প্যারামিটার এবং শিরোনামগুলি (যথাযথ হিসাবে) প্রয়োগ করে এবং তারপরে প্রতিটি অংশকে এমনভাবে আচরণ করে যেন এটি একটি পৃথক এইচটিটিপি অনুরোধ।

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

সার্ভারের প্রতিক্রিয়া একটি multipart/mixed সামগ্রীর ধরণের সহ একক স্ট্যান্ডার্ড এইচটিটিপি প্রতিক্রিয়া; প্রতিটি অংশই অনুরোধগুলির মতো একই ক্রমে ব্যাচ অনুরোধের একটি অনুরোধের প্রতিক্রিয়া।

অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশে একটি স্ট্যাটাস কোড, শিরোনাম এবং বডি সহ একটি সম্পূর্ণ এইচটিটিপি প্রতিক্রিয়া রয়েছে। এবং অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশটি একটি Content-Type শিরোনাম দ্বারা আগে রয়েছে যা অংশের সূচনা চিহ্নিত করে।

যদি অনুরোধের কোনও প্রদত্ত অংশে একটি Content-ID শিরোনাম থাকে, তবে প্রতিক্রিয়াটির সংশ্লিষ্ট অংশে একটি মিলে যাওয়া Content-ID শিরোনাম রয়েছে, স্ট্রিং response- আগে মূল মানটি রয়েছে-, নিম্নলিখিত উদাহরণে দেখানো হয়েছে।

দ্রষ্টব্য : সার্ভার কোনও ক্রমে আপনার কলগুলি সম্পাদন করতে পারে। আপনি যে ক্রমে সেগুলি নির্দিষ্ট করেছেন তাতে তাদের মৃত্যুদন্ড কার্যকর করা হচ্ছে না। আপনি যদি নিশ্চিত করতে চান যে প্রদত্ত ক্রমে দুটি কল ঘটে তবে আপনি সেগুলি একক অনুরোধে প্রেরণ করতে পারবেন না; পরিবর্তে, নিজে থেকে প্রথমটি প্রেরণ করুন, তারপরে দ্বিতীয়টি প্রেরণের আগে প্রথমটির প্রতিক্রিয়াটির জন্য অপেক্ষা করুন।

উদাহরণ

নিম্নলিখিত উদাহরণটি গুগল ড্রাইভ এপিআইয়ের সাথে ব্যাচিংয়ের ব্যবহার দেখায়।

উদাহরণ ব্যাচের অনুরোধ

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART Content-Length: 337 Content-Type: application/http content-id: 1 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id Authorization: Bearer authorization_token Content-Length: 70 Content-Type: application/json; charset=UTF-8

{ "emailAddress":"example@appsrocks.com", "role":"writer", "type":"user" } --END_OF_PART Content-Length: 353 Content-Type: application/http content-id: 2 content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false Authorization: Bearer authorization_token Content-Length: 58 Content-Type: application/json; charset=UTF-8

{ "domain":"appsrocks.com", "role":"reader", "type":"domain" } --END_OF_PART--

উদাহরণ ব্যাচের প্রতিক্রিয়া

এটি পূর্ববর্তী বিভাগে উদাহরণ অনুরোধের প্রতিক্রিয়া।

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-1

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "12218244892818058021i" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk Content-Type: application/http Content-ID: response-2

HTTP/1.1 200 OK Content-Type: application/json; charset=UTF-8 Date: Fri, 13 Nov 2015 19:28:59 GMT Expires: Fri, 13 Nov 2015 19:28:59 GMT Cache-Control: private, max-age=0 Content-Length: 35

{ "id": "04109509152946699072k" }

--batch_6VIxXCQbJoQ_AATxy_GgFUk--

অনুরোধ থেকে নির্দিষ্ট ক্ষেত্রগুলি ফিরিয়ে দিন

আপনি যদি fields প্যারামিটারটি নির্দিষ্ট না করেন তবে সার্ভারটি পদ্ধতিতে নির্দিষ্ট ক্ষেত্রগুলির একটি ডিফল্ট সেট দেয়। উদাহরণস্বরূপ, files.list পদ্ধতিটি কেবল kind , id , name এবং mimeType ক্ষেত্রগুলি ফেরত দেয়।

ফিরে আসা ডিফল্ট ক্ষেত্রগুলি আপনার যা প্রয়োজন তা নাও হতে পারে। আপনি যদি প্রতিক্রিয়াতে কোন ক্ষেত্রগুলি ফিরে আসতে চান তা নির্দিষ্ট করতে চান তবে fields সিস্টেমের প্যারামিটারটি ব্যবহার করুন। আরও তথ্যের জন্য, নির্দিষ্ট ক্ষেত্রগুলি রিটার্ন দেখুন।

about সমস্ত পদ্ধতির জন্য, comments ( delete বাদে), এবং replies ( delete বাদে) সংস্থানগুলি আপনাকে অবশ্যই fields প্যারামিটার সেট করতে হবে। এই পদ্ধতিগুলি ক্ষেত্রগুলির একটি ডিফল্ট সেট ফেরত দেয় না।