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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

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

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

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

PATCH HTTP ভার্ব সমর্থিত না হলে বিকল্প সংকেত

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

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

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

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

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

সংক্ষিপ্ত বিবরণ

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

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

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

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

একটি একক ব্যাচ অনুরোধে আপনি সর্বোচ্চ ১০০টি কল করতে পারবেন। যদি এর চেয়ে বেশি কল করার প্রয়োজন হয়, তবে একাধিক ব্যাচ অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : গুগল ড্রাইভ এপিআই-এর ব্যাচ সিস্টেমটি OData ব্যাচ প্রসেসিং সিস্টেমের মতোই সিনট্যাক্স ব্যবহার করে, কিন্তু এর অর্থগত তাৎপর্য ভিন্ন।

অতিরিক্ত সীমাবদ্ধতাগুলোর মধ্যে রয়েছে:

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

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

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

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

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

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

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

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

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

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

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

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

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

রিকোয়েস্টের অংশগুলোর মতোই, প্রতিটি রেসপন্স পার্টে একটি সম্পূর্ণ HTTP রেসপন্স থাকে, যার মধ্যে স্ট্যাটাস কোড, হেডার এবং বডি অন্তর্ভুক্ত। এবং রিকোয়েস্টের অংশগুলোর মতোই, প্রতিটি রেসপন্স পার্টের আগে একটি 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--