সংযুক্তি আপলোড হচ্ছে

জিমেইল এপিআই আপনাকে ড্রাফ্ট তৈরি বা আপডেট করার সময় অথবা বার্তা সন্নিবেশ করানো বা পাঠানোর সময় ফাইল ডেটা আপলোড করার অনুমতি দেয়।

আপলোডের বিকল্পগুলি

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

• সর্বোচ্চ আপলোড ফাইলের আকার : এই পদ্ধতিতে আপনি সর্বোচ্চ কত ডেটা সঞ্চয় করতে পারবেন।
• গ্রহণযোগ্য মিডিয়া MIME প্রকার : এই পদ্ধতি ব্যবহার করে আপনি যে ধরণের বাইনারি ডেটা সংরক্ষণ করতে পারেন।

আপনি নিম্নলিখিত যেকোনো উপায়ে আপলোড অনুরোধ করতে পারেন। uploadType অনুরোধ প্যারামিটারের সাহায্যে আপনি যে পদ্ধতিটি ব্যবহার করছেন তা উল্লেখ করুন।

• সহজ আপলোড : uploadType=media । ৫ মেগাবাইট বা তার কম আকারের ছোট ফাইল দ্রুত স্থানান্তরের জন্য।
• মাল্টিপার্ট আপলোড : uploadType=multipart । ছোট ফাইল এবং মেটাডেটা দ্রুত স্থানান্তরের জন্য; ফাইলটি বর্ণনাকারী মেটাডেটা সহ একটি একক অনুরোধে স্থানান্তর করে।
• পুনঃসূচনাযোগ্য আপলোড : uploadType=resumable । নির্ভরযোগ্য স্থানান্তরের জন্য, বিশেষ করে বড় ফাইলের ক্ষেত্রে গুরুত্বপূর্ণ। এই পদ্ধতিতে, আপনি একটি সেশন শুরু করার অনুরোধ ব্যবহার করেন, যাতে ঐচ্ছিকভাবে মেটাডেটা অন্তর্ভুক্ত থাকতে পারে। এটি বেশিরভাগ অ্যাপ্লিকেশনের জন্য ব্যবহার করার জন্য একটি ভাল কৌশল, কারণ এটি ছোট ফাইলের জন্যও কাজ করে প্রতি আপলোডে একটি অতিরিক্ত HTTP অনুরোধের খরচে।

যখন আপনি মিডিয়া আপলোড করেন, তখন আপনি একটি বিশেষ URI ব্যবহার করেন। আসলে, মিডিয়া আপলোড সমর্থনকারী পদ্ধতিগুলির দুটি URI এন্ডপয়েন্ট থাকে:

• মিডিয়ার জন্য /upload URI। আপলোড এন্ডপয়েন্টের ফর্ম্যাট হল স্ট্যান্ডার্ড রিসোর্স URI যার একটি "/upload" প্রিফিক্স রয়েছে। মিডিয়া ডেটা স্থানান্তর করার সময় এই URI ব্যবহার করুন।

  উদাহরণ: POST /upload/gmail/v1/users/ userId /messages/send

• মেটাডেটার জন্য স্ট্যান্ডার্ড রিসোর্স URI। যদি রিসোর্সে কোনও ডেটা ফিল্ড থাকে, তাহলে সেই ফিল্ডগুলি আপলোড করা ফাইলের বর্ণনাকারী মেটাডেটা সংরক্ষণ করতে ব্যবহৃত হয়। মেটাডেটা মান তৈরি বা আপডেট করার সময় আপনি এই URI ব্যবহার করতে পারেন।

  উদাহরণ: POST /gmail/v1/users/ userId /messages/send

সহজ আপলোড

ফাইল আপলোড করার সবচেয়ে সহজ পদ্ধতি হল একটি সহজ আপলোড অনুরোধ করা। এই বিকল্পটি একটি ভালো পছন্দ যখন:

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

সহজ আপলোড ব্যবহার করতে, পদ্ধতির /upload URI তে একটি POST অথবা PUT অনুরোধ করুন এবং uploadType=media কোয়েরি প্যারামিটার যোগ করুন। উদাহরণস্বরূপ:

POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=media

একটি সাধারণ আপলোড অনুরোধ করার সময় যে HTTP হেডারগুলি ব্যবহার করতে হবে তার মধ্যে রয়েছে:

• Content-Type । API রেফারেন্সে উল্লেখিত পদ্ধতির গৃহীত আপলোড মিডিয়া ডেটা টাইপগুলির মধ্যে একটিতে সেট করুন।
• Content-Length । আপনি যত বাইট আপলোড করছেন তার সংখ্যা নির্ধারণ করুন। যদি আপনি চাঙ্কড ট্রান্সফার এনকোডিং ব্যবহার করেন তবে এটি প্রয়োজন হবে না।

উদাহরণ: সহজ আপলোড

নিম্নলিখিত উদাহরণটি Gmail API-এর জন্য একটি সাধারণ আপলোড অনুরোধের ব্যবহার দেখায়।

POST /upload/gmail/v1/users/userId/messages/send?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: message/rfc822
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

Email Message data

যদি অনুরোধটি সফল হয়, তাহলে সার্ভার যেকোনো মেটাডেটা সহ HTTP 200 OK স্ট্যাটাস কোড ফেরত পাঠাবে:

HTTP/1.1 200
Content-Type: application/json

{
  "id": string,
  "threadId": string,
  "labelIds": [
    string
  ],
  "snippet": string,
  "historyId": unsigned long,
  "payload": {
    "partId": string,
    "mimeType": string,
    "filename": string,
    "headers": [
      {
        "name": string,
        "value": string
      }
    ],
    "body": users.messages.attachments Resource,
    "parts": [
      (MessagePart)
    ]
  },
  "sizeEstimate": integer,
  "raw": bytes
}

মাল্টিপার্ট আপলোড

যদি আপনার কাছে আপলোড করার জন্য ডেটার সাথে মেটাডেটা পাঠাতে চান, তাহলে আপনি একটি একক multipart/related অনুরোধ করতে পারেন। সংযোগ ব্যর্থ হলে সম্পূর্ণরূপে আবার আপলোড করার জন্য আপনার পাঠানো ডেটা যথেষ্ট ছোট হলে এটি একটি ভাল পছন্দ।

মাল্টিপার্ট আপলোড ব্যবহার করতে, পদ্ধতির /upload URI তে একটি POST অথবা PUT অনুরোধ করুন এবং uploadType=multipart কোয়েরি প্যারামিটার যোগ করুন, উদাহরণস্বরূপ:

POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=multipart

মাল্টিপার্ট আপলোড অনুরোধ করার সময় যে শীর্ষ-স্তরের HTTP হেডারগুলি ব্যবহার করা হবে তার মধ্যে রয়েছে:

• Content-Type । multipart/related এ সেট করুন এবং অনুরোধের অংশগুলি সনাক্ত করতে আপনি যে সীমানা স্ট্রিংটি ব্যবহার করছেন তা অন্তর্ভুক্ত করুন।
• Content-Length । অনুরোধের মূল অংশে মোট বাইটের সংখ্যা নির্ধারণ করুন। অনুরোধের মিডিয়া অংশটি এই পদ্ধতির জন্য নির্দিষ্ট সর্বোচ্চ ফাইল আকারের চেয়ে কম হতে হবে।

অনুরোধের মূল অংশটি একটি multipart/related কন্টেন্ট টাইপ [ RFC2387 ] হিসেবে ফর্ম্যাট করা হয়েছে এবং এতে ঠিক দুটি অংশ রয়েছে। অংশগুলি একটি সীমানা স্ট্রিং দ্বারা চিহ্নিত করা হয় এবং চূড়ান্ত সীমানা স্ট্রিংটি দুটি হাইফেন দ্বারা অনুসরণ করা হয়।

মাল্টিপার্ট রিকোয়েস্টের প্রতিটি অংশের জন্য একটি অতিরিক্ত Content-Type হেডার প্রয়োজন:

1. মেটাডেটা অংশ: প্রথমে আসতে হবে, এবং Content-Type অবশ্যই গৃহীত মেটাডেটা ফর্ম্যাটগুলির একটির সাথে মিলতে হবে।
2. মিডিয়া অংশ: দ্বিতীয় স্থানে থাকা আবশ্যক, এবং Content-Type অবশ্যই পদ্ধতির গৃহীত মিডিয়া MIME প্রকারের সাথে মিলবে।

প্রতিটি পদ্ধতির গৃহীত মিডিয়া MIME প্রকারের তালিকা এবং আপলোড করা ফাইলের আকার সীমার জন্য API রেফারেন্স দেখুন।

দ্রষ্টব্য: শুধুমাত্র মেটাডেটা অংশ তৈরি বা আপডেট করতে, সংশ্লিষ্ট ডেটা আপলোড না করে, স্ট্যান্ডার্ড রিসোর্স এন্ডপয়েন্টে একটি POST বা PUT অনুরোধ পাঠান: https://www.googleapis.com/gmail/v1/users/ userId /messages/send

উদাহরণ: মাল্টিপার্ট আপলোড

নিচের উদাহরণটি Gmail API-এর জন্য একটি মাল্টিপার্ট আপলোড অনুরোধ দেখায়।

POST /upload/gmail/v1/users/userId/messages/send?uploadType=multipart HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=foo_bar_baz
Content-Length: number_of_bytes_in_entire_request_body

--foo_bar_baz
Content-Type: application/json; charset=UTF-8

{
  "id": string,
  "threadId": string,
  "labelIds": [
    string
  ],
  "snippet": string,
  "historyId": unsigned long,
  "payload": {
    "partId": string,
    "mimeType": string,
    "filename": string,
    "headers": [
      {
        "name": string,
        "value": string
      }
    ],
    "body": users.messages.attachments Resource,
    "parts": [
      (MessagePart)
    ]
  },
  "sizeEstimate": integer,
  "raw": bytes
}

--foo_bar_baz
Content-Type: message/rfc822

Email Message data
--foo_bar_baz--

যদি অনুরোধটি সফল হয়, তাহলে সার্ভার যেকোনো মেটাডেটা সহ HTTP 200 OK স্ট্যাটাস কোড ফেরত পাঠাবে:

HTTP/1.1 200
Content-Type: application/json

{
  "id": string,
  "threadId": string,
  "labelIds": [
    string
  ],
  "snippet": string,
  "historyId": unsigned long,
  "payload": {
    "partId": string,
    "mimeType": string,
    "filename": string,
    "headers": [
      {
        "name": string,
        "value": string
      }
    ],
    "body": users.messages.attachments Resource,
    "parts": [
      (MessagePart)
    ]
  },
  "sizeEstimate": integer,
  "raw": bytes
}

পুনরায় শুরু করা যাবে এমন আপলোড

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

রিজিউমেবল আপলোড ব্যবহারের ধাপগুলির মধ্যে রয়েছে:

1. একটি পুনঃসূচনাযোগ্য সেশন শুরু করুন । আপলোড URI-তে একটি প্রাথমিক অনুরোধ করুন যাতে মেটাডেটা, যদি থাকে, অন্তর্ভুক্ত থাকে।
2. পুনঃসূচনাযোগ্য সেশন URI সংরক্ষণ করুন । প্রাথমিক অনুরোধের প্রতিক্রিয়ায় ফিরে আসা সেশন URI সংরক্ষণ করুন; আপনি এই সেশনের অবশিষ্ট অনুরোধগুলির জন্য এটি ব্যবহার করবেন।
3. ফাইলটি আপলোড করুন । মিডিয়া ফাইলটি পুনরায় শুরু করার সেশন URI-তে পাঠান।

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

দ্রষ্টব্য: একটি আপলোড URI এক সপ্তাহ পরে মেয়াদ শেষ হয়ে যায়।

ধাপ ১: একটি পুনরায় শুরুযোগ্য সেশন শুরু করুন

একটি পুনঃসূচনাযোগ্য আপলোড শুরু করতে, পদ্ধতির /upload URI তে একটি POST অথবা PUT অনুরোধ করুন এবং uploadType=resumable কোয়েরি প্যারামিটার যোগ করুন, উদাহরণস্বরূপ:

POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable

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

প্রাথমিক অনুরোধের সাথে নিম্নলিখিত HTTP হেডারগুলি ব্যবহার করুন:

• X-Upload-Content-Type । পরবর্তী অনুরোধগুলিতে স্থানান্তরিত করার জন্য আপলোড ডেটার মিডিয়া MIME টাইপে সেট করুন।
• X-Upload-Content-Length । পরবর্তী অনুরোধগুলিতে স্থানান্তরিত করার জন্য আপলোড ডেটার বাইটের সংখ্যা সেট করুন। যদি এই অনুরোধের সময় দৈর্ঘ্য অজানা থাকে, তাহলে আপনি এই হেডারটি বাদ দিতে পারেন।
• যদি মেটাডেটা প্রদান করা হয়: Content-Type । মেটাডেটার ডেটা টাইপ অনুসারে সেট করুন।
• Content-Length । এই প্রাথমিক অনুরোধের মূল অংশে প্রদত্ত বাইটের সংখ্যায় সেট করুন। যদি আপনি চাঙ্কড ট্রান্সফার এনকোডিং ব্যবহার করেন তবে প্রয়োজন নেই।

প্রতিটি পদ্ধতির গৃহীত মিডিয়া MIME প্রকারের তালিকা এবং আপলোড করা ফাইলের আকার সীমার জন্য API রেফারেন্স দেখুন।

উদাহরণ: পুনঃসূচনাযোগ্য সেশন শুরু করার অনুরোধ

নিম্নলিখিত উদাহরণে Gmail API-এর জন্য একটি পুনঃসূচনাযোগ্য সেশন কীভাবে শুরু করতে হয় তা দেখানো হয়েছে।

POST /upload/gmail/v1/users/userId/messages/send?uploadType=resumable HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Type: message/rfc822
X-Upload-Content-Length: 2000000

{
  "id": string,
  "threadId": string,
  "labelIds": [
    string
  ],
  "snippet": string,
  "historyId": unsigned long,
  "payload": {
    "partId": string,
    "mimeType": string,
    "filename": string,
    "headers": [
      {
        "name": string,
        "value": string
      }
    ],
    "body": users.messages.attachments Resource,
    "parts": [
      (MessagePart)
    ]
  },
  "sizeEstimate": integer,
  "raw": bytes
}

দ্রষ্টব্য: মেটাডেটা ছাড়া প্রাথমিক পুনঃসূচনাযোগ্য আপডেট অনুরোধের জন্য, অনুরোধের মূল অংশটি খালি রাখুন এবং Content-Length হেডারটি 0 এ সেট করুন।

পরবর্তী অংশে প্রতিক্রিয়া কীভাবে পরিচালনা করতে হবে তা বর্ণনা করা হয়েছে।

ধাপ ২: পুনঃসূচনাযোগ্য সেশন URI সংরক্ষণ করুন

যদি সেশন শুরু করার অনুরোধ সফল হয়, তাহলে API সার্ভার 200 OK HTTP স্ট্যাটাস কোড দিয়ে সাড়া দেয়। এছাড়াও, এটি একটি Location হেডার প্রদান করে যা আপনার পুনঃসূচনাযোগ্য সেশন URI নির্দিষ্ট করে। নীচের উদাহরণে দেখানো Location হেডারে একটি upload_id কোয়েরি প্যারামিটার অংশ রয়েছে যা এই সেশনের জন্য ব্যবহারের জন্য অনন্য আপলোড আইডি দেয়।

উদাহরণ: পুনঃসূচনাযোগ্য সেশন শুরুর প্রতিক্রিয়া

ধাপ ১-এ অনুরোধের প্রতিক্রিয়া এখানে দেওয়া হল:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

উপরের উদাহরণের প্রতিক্রিয়ায় দেখানো Location শিরোনামের মান হল সেই সেশন URI যা আপনি প্রকৃত ফাইল আপলোড করার জন্য বা আপলোডের স্থিতি অনুসন্ধানের জন্য HTTP এন্ডপয়েন্ট হিসাবে ব্যবহার করবেন।

সেশন URI কপি করে সংরক্ষণ করুন যাতে আপনি পরবর্তী অনুরোধের জন্য এটি ব্যবহার করতে পারেন।

ধাপ ৩: ফাইলটি আপলোড করুন

ফাইলটি আপলোড করার জন্য, পূর্ববর্তী ধাপে প্রাপ্ত আপলোড URI-তে একটি PUT অনুরোধ পাঠান। আপলোড অনুরোধের ফর্ম্যাট হল:

PUT session_uri

পুনরায় শুরু করার জন্য ফাইল আপলোড অনুরোধ করার সময় যে HTTP হেডারগুলি ব্যবহার করতে হবে তার মধ্যে রয়েছে Content-Length । এই অনুরোধে আপনি যত বাইটের আপলোড করছেন তার সংখ্যার উপর এটি সেট করুন, যা সাধারণত আপলোড ফাইলের আকার।

উদাহরণ: পুনরায় শুরু করার যোগ্য ফাইল আপলোডের অনুরোধ

বর্তমান উদাহরণের জন্য সম্পূর্ণ ২০,০০,০০০ বাইট ইমেল বার্তা ফাইলটি আপলোড করার জন্য এখানে একটি পুনঃসূচনা অনুরোধ করা হল।

PUT https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: message/rfc822

bytes 0-1999999

যদি অনুরোধটি সফল হয়, তাহলে সার্ভারটি একটি HTTP 201 Created , এবং এই রিসোর্সের সাথে সম্পর্কিত যেকোনো মেটাডেটা দিয়ে সাড়া দেবে। যদি পুনঃসূচনাযোগ্য সেশনের প্রাথমিক অনুরোধটি একটি PUT হয়ে থাকে, তাহলে বিদ্যমান রিসোর্স আপডেট করার জন্য, সাফল্যের প্রতিক্রিয়া হবে 200 OK , এবং এই রিসোর্সের সাথে সম্পর্কিত যেকোনো মেটাডেটাও থাকবে।

যদি আপলোড অনুরোধটি বাধাগ্রস্ত হয় অথবা আপনি যদি সার্ভার থেকে HTTP 503 Service Unavailable বা অন্য কোনও 5xx প্রতিক্রিয়া পান, তাহলে "রিজিউম অ্যান ইন্টারাপ্টেড আপলোড" এ বর্ণিত পদ্ধতি অনুসরণ করুন।

---

ফাইলটি খণ্ড খণ্ড করে আপলোড করা হচ্ছে

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

আরও তথ্যের জন্য প্রসারিত করুন

যদি আপনি খণ্ড খণ্ডে ডেটা আপলোড করেন, তাহলে সম্পূর্ণ ফাইল আপলোডের জন্য প্রয়োজনীয় Content-Length হেডারের সাথে Content-Range হেডারটিও প্রয়োজন:

• Content-Length । শেষ অনুরোধের ক্ষেত্রে যেমনটি হতে পারে, তেমনই চাঙ্ক আকারে বা সম্ভবত কম সেট করুন।
• Content-Range : আপনি যে ফাইলটি আপলোড করছেন তাতে কোন বাইটগুলি দেখানোর জন্য সেট করা আছে। উদাহরণস্বরূপ, Content-Range: bytes 0-524287/2000000 দেখায় যে আপনি 2,000,000 বাইট ফাইলে প্রথম 524,288 বাইট (256 x 1024 x 2) প্রদান করছেন।

খণ্ডের আকারের সীমাবদ্ধতা: আপলোড সম্পূর্ণ করার জন্য চূড়ান্ত খণ্ডটি ছাড়া, সমস্ত খণ্ডের আকার 256 KB (256 x 1024 বাইট) এর গুণিতক হতে হবে। যদি আপনি খণ্ড ব্যবহার করেন, তাহলে আপলোড কার্যকর রাখার জন্য খণ্ডের আকার যতটা সম্ভব বড় রাখা গুরুত্বপূর্ণ।

উদাহরণ: পুনঃসূচনাযোগ্য খণ্ডিত ফাইল আপলোডের অনুরোধ

প্রথম ৫২৪,২৮৮ বাইট পাঠানোর অনুরোধটি এরকম দেখতে হতে পারে:

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: message/rfc822
Content-Range: bytes 0-524287/2000000

bytes 0-524288

যদি অনুরোধটি সফল হয়, তাহলে সার্ভার 308 Resume Incomplete দিয়ে সাড়া দেবে, সাথে একটি Range হেডার থাকবে যা এখন পর্যন্ত মোট কত বাইটের সংরক্ষিত সংখ্যা চিহ্নিত করবে:

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

পরবর্তী অংশটি কোথা থেকে শুরু করবেন তা নির্ধারণ করতে Range হেডারে প্রদত্ত উপরের মানটি ব্যবহার করুন। সম্পূর্ণ ফাইলটি আপলোড না হওয়া পর্যন্ত ফাইলের প্রতিটি অংশ PUT থাকুন।

যদি কোনও চাঙ্কের PUT অনুরোধ বাধাগ্রস্ত হয় অথবা আপনি যদি সার্ভার থেকে HTTP 503 Service Unavailable অথবা অন্য কোনও 5xx প্রতিক্রিয়া পান, তাহলে resume an interrupted upload এ বর্ণিত পদ্ধতি অনুসরণ করুন, তবে বাকি ফাইল আপলোড করার পরিবর্তে, কেবল সেই বিন্দু থেকে চাঙ্ক আপলোড চালিয়ে যান।

গুরুত্বপূর্ণ নোট:

• পরবর্তী অংশটি কোথা থেকে শুরু করবেন তা নির্ধারণ করতে প্রতিক্রিয়ায় Range হেডার ব্যবহার করতে ভুলবেন না; ধরে নিবেন না যে সার্ভারটি পূর্ববর্তী অনুরোধে প্রেরিত সমস্ত বাইট পেয়েছে।
• প্রতিটি আপলোড URI-এর একটি নির্দিষ্ট সময়কাল থাকে এবং অবশেষে মেয়াদ শেষ হয়ে যায় (যদি ব্যবহার না করা হয়, তাহলে এক বা তারও বেশি দিনের মধ্যে)। এই কারণে, আপলোড URI পাওয়ার সাথে সাথে একটি পুনরায় শুরুযোগ্য আপলোড শুরু করা এবং বাধা আসার কিছুক্ষণ পরেই একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করা ভাল।
• যদি আপনি একটি মেয়াদোত্তীর্ণ আপলোড সেশন আইডি সহ একটি অনুরোধ পাঠান, তাহলে সার্ভার একটি 404 Not Found স্ট্যাটাস কোড ফেরত পাঠাবে। যখন আপলোড সেশনে একটি অপ্রত্যাশিত ত্রুটি দেখা দেয়, তখন সার্ভার একটি 410 Gone স্ট্যাটাস কোড ফেরত পাঠাবে। এই ক্ষেত্রে, আপনাকে একটি নতুন পুনঃসূচনাযোগ্য আপলোড শুরু করতে হবে, একটি নতুন আপলোড URI পেতে হবে এবং নতুন এন্ডপয়েন্ট ব্যবহার করে শুরু থেকে আপলোড শুরু করতে হবে।

সম্পূর্ণ ফাইল আপলোড সম্পূর্ণ হলে, সার্ভারটি এই রিসোর্সের সাথে সম্পর্কিত যেকোনো মেটাডেটা সহ একটি HTTP 201 Created সাড়া দেয়। যদি এই অনুরোধটি একটি নতুন তৈরি করার পরিবর্তে একটি বিদ্যমান সত্তা আপডেট করা হত, তাহলে সম্পূর্ণ আপলোডের জন্য HTTP প্রতিক্রিয়া কোড 200 OK হত।

---

একটি বাধাগ্রস্ত আপলোড পুনরায় শুরু করুন

যদি কোনও আপলোড অনুরোধ প্রতিক্রিয়া পাওয়ার আগেই বন্ধ হয়ে যায় অথবা আপনি যদি সার্ভার থেকে HTTP 503 Service Unavailable প্রতিক্রিয়া পান, তাহলে আপনাকে বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করতে হবে। এটি করার জন্য:

1. অনুরোধের স্থিতি। আপলোড URI-তে একটি খালি PUT অনুরোধ জারি করে আপলোডের বর্তমান স্থিতি জিজ্ঞাসা করুন। এই অনুরোধের জন্য, HTTP হেডারগুলিতে একটি Content-Range হেডার অন্তর্ভুক্ত করা উচিত যা নির্দেশ করে যে ফাইলের বর্তমান অবস্থান অজানা। উদাহরণস্বরূপ, যদি আপনার মোট ফাইলের দৈর্ঘ্য 2,000,000 হয় তবে Content-Range */2000000 এ সেট করুন। যদি আপনি ফাইলের পূর্ণ আকার না জানেন, Content-Range */* এ সেট করুন।

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

2. আপলোড করা বাইটের সংখ্যা পান। স্ট্যাটাস কোয়েরি থেকে প্রতিক্রিয়া প্রক্রিয়া করুন। সার্ভারটি তার প্রতিক্রিয়ায় Range হেডার ব্যবহার করে এখন পর্যন্ত কোন বাইট পেয়েছে তা নির্দিষ্ট করে। উদাহরণস্বরূপ, 0-299999 এর একটি Range হেডার নির্দেশ করে যে ফাইলের প্রথম 300,000 বাইট প্রাপ্ত হয়েছে।
3. অবশিষ্ট ডেটা আপলোড করুন। অবশেষে, এখন আপনি জানেন যে অনুরোধটি কোথায় পুনরায় শুরু করতে হবে, অবশিষ্ট ডেটা অথবা বর্তমান অংশটি পাঠান। মনে রাখবেন যে আপনাকে অবশিষ্ট ডেটা উভয় ক্ষেত্রেই একটি পৃথক অংশ হিসাবে বিবেচনা করতে হবে, তাই আপলোড পুনরায় শুরু করার সময় আপনাকে Content-Range হেডারটি পাঠাতে হবে।

উদাহরণ: একটি বাধাগ্রস্ত আপলোড পুনরায় শুরু করা

১) আপলোড স্ট্যাটাসের জন্য অনুরোধ করুন।

নিম্নলিখিত অনুরোধটি Content-Range হেডার ব্যবহার করে নির্দেশ করে যে 2,000,000 বাইট ফাইলের বর্তমান অবস্থান অজানা।

PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000

২) প্রতিক্রিয়া থেকে এখন পর্যন্ত আপলোড করা বাইটের সংখ্যা বের করুন।

সার্ভারের প্রতিক্রিয়াটি Range হেডার ব্যবহার করে নির্দেশ করে যে এটি এখন পর্যন্ত ফাইলের প্রথম ৪৩ বাইট পেয়েছে। পুনরায় শুরু করা আপলোডটি কোথা থেকে শুরু করবেন তা নির্ধারণ করতে Range হেডারের উপরের মানটি ব্যবহার করুন।

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42

দ্রষ্টব্য: আপলোড সম্পূর্ণ হলে স্ট্যাটাস রেসপন্স 201 Created অথবা 200 OK হতে পারে। সমস্ত বাইট আপলোড করার পরে কিন্তু ক্লায়েন্ট সার্ভার থেকে কোনও রেসপন্স পাওয়ার আগেই সংযোগটি ভেঙে গেলে এটি ঘটতে পারে।

৩) আপলোডটি যেখান থেকে শেষ হয়েছিল সেখান থেকে পুনরায় শুরু করুন।

নিম্নলিখিত অনুরোধটি ফাইলের অবশিষ্ট বাইটগুলি পাঠিয়ে আপলোড পুনরায় শুরু করে, বাইট 43 থেকে শুরু করে।

PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999

সেরা অনুশীলন

মিডিয়া আপলোড করার সময়, ত্রুটি পরিচালনার সাথে সম্পর্কিত কিছু সেরা অনুশীলন সম্পর্কে সচেতন থাকা সহায়ক।

• সংযোগ বিঘ্নিত হওয়ার কারণে বা 5xx ত্রুটির কারণে ব্যর্থ হওয়া আপলোডগুলি পুনরায় শুরু করুন বা পুনরায় চেষ্টা করুন, যার মধ্যে রয়েছে:
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
• আপলোড অনুরোধ পুনরায় শুরু করার সময় বা পুনরায় চেষ্টা করার সময় যদি কোনও 5xx সার্ভার ত্রুটি ফিরে আসে তবে একটি সূচকীয় ব্যাকঅফ কৌশল ব্যবহার করুন। কোনও সার্ভার ওভারলোড হয়ে গেলে এই ত্রুটিগুলি ঘটতে পারে। উচ্চ পরিমাণে অনুরোধ বা ভারী নেটওয়ার্ক ট্র্যাফিকের সময় সূচকীয় ব্যাকঅফ এই ধরণের সমস্যাগুলি কমাতে সাহায্য করতে পারে।
• অন্যান্য ধরণের অনুরোধগুলি এক্সপোনেনশিয়াল ব্যাকঅফ দ্বারা পরিচালনা করা উচিত নয় তবে আপনি এখনও সেগুলির বেশ কয়েকটি পুনরায় চেষ্টা করতে পারেন। এই অনুরোধগুলি পুনরায় চেষ্টা করার সময়, আপনি কতবার পুনরায় চেষ্টা করবেন তা সীমাবদ্ধ করুন। উদাহরণস্বরূপ, আপনার কোডটি ত্রুটি রিপোর্ট করার আগে দশটি পুনরায় চেষ্টা বা তার কম সীমাবদ্ধ করতে পারে।
• পুনঃসূচনাযোগ্য আপলোড করার সময় সম্পূর্ণ আপলোডটি শুরু থেকে শুরু করে 404 Not Found এবং 410 Gone ত্রুটিগুলি পরিচালনা করুন।

সূচকীয় ব্যাকঅফ

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

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

সরল সূচকীয় ব্যাকঅফ বাস্তবায়নের প্রবাহ নিম্নরূপ:

1. API-তে একটি অনুরোধ করুন।
2. একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
3. ১ সেকেন্ড অপেক্ষা করুন + র‍্যান্ডম_নম্বর_মিলিসেকেন্ড এবং অনুরোধটি পুনরায় চেষ্টা করুন।
4. একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
5. ২ সেকেন্ড অপেক্ষা করুন + র‍্যান্ডম_নম্বর_মিলিসেকেন্ড, এবং অনুরোধটি পুনরায় চেষ্টা করুন।
6. একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
7. ৪ সেকেন্ড অপেক্ষা করুন + র‍্যান্ডম_নম্বর_মিলিসেকেন্ড, এবং অনুরোধটি পুনরায় চেষ্টা করুন।
8. একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
9. ৮ সেকেন্ড অপেক্ষা করুন + র‍্যান্ডম_নম্বর_মিলিসেকেন্ড, এবং অনুরোধটি পুনরায় চেষ্টা করুন।
10. একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
11. ১৬ সেকেন্ড অপেক্ষা করুন + র‍্যান্ডম_নম্বর_মিলিসেকেন্ড, এবং অনুরোধটি পুনরায় চেষ্টা করুন।
12. থামো। ত্রুটি রিপোর্ট করুন অথবা লগ করুন।

উপরের প্রবাহে, random_number_milliseconds হল ১০০০ এর কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি প্রয়োজনীয়, কারণ একটি ছোট এলোমেলো বিলম্ব প্রবর্তন লোডকে আরও সমানভাবে বিতরণ করতে সাহায্য করে এবং সার্ভারে স্ট্যাম্পিং হওয়ার সম্ভাবনা এড়াতে সাহায্য করে। প্রতিটি অপেক্ষার পরে random_number_milliseconds এর মান পুনরায় সংজ্ঞায়িত করতে হবে।

দ্রষ্টব্য: অপেক্ষা সর্বদা (2 ^ n) + র‍্যান্ডম_সংখ্যা_মিলিসেকেন্ড হয়, যেখানে n হল একটি একঘেয়ে ক্রমবর্ধমান পূর্ণসংখ্যা যা প্রাথমিকভাবে 0 হিসাবে সংজ্ঞায়িত করা হয়। প্রতিটি পুনরাবৃত্তির জন্য (প্রতিটি অনুরোধের জন্য) পূর্ণসংখ্যা n 1 দ্বারা বৃদ্ধি করা হয়।

n ৫ হলে অ্যালগরিদমটি সমাপ্তির জন্য সেট করা থাকে। এই সিলিং ক্লায়েন্টদের অসীমভাবে পুনরায় চেষ্টা করতে বাধা দেয় এবং একটি অনুরোধকে "অপুনরুদ্ধারযোগ্য ত্রুটি" হিসাবে বিবেচনা করার আগে মোট প্রায় ৩২ সেকেন্ড বিলম্বের সৃষ্টি করে। সর্বাধিক সংখ্যক পুনরায় চেষ্টা করা ঠিক আছে, বিশেষ করে যদি একটি দীর্ঘ আপলোড প্রক্রিয়াধীন থাকে; কেবল যুক্তিসঙ্গত কিছুতে পুনরায় চেষ্টা করার বিলম্ব সীমাবদ্ধ করতে ভুলবেন না, যেমন, এক মিনিটেরও কম।

API ক্লায়েন্ট লাইব্রেরি নির্দেশিকা

• .নেট
• জাভা
• পিএইচপি
• পাইথন
• রুবি