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

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

Gmail API আপনাকে একটি খসড়া তৈরি বা আপডেট করার সময় বা একটি বার্তা সন্নিবেশ বা পাঠানোর সময় ফাইল ডেটা আপলোড করতে দেয়৷

আপলোড অপশন

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

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

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

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

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

মিডিয়ার জন্য /আপলোড ইউআরআই। আপলোড এন্ডপয়েন্টের ফর্ম্যাট হল "/আপলোড" উপসর্গ সহ স্ট্যান্ডার্ড রিসোর্স URI। মিডিয়া ডেটা স্থানান্তর করার সময় এই URI ব্যবহার করুন।
উদাহরণ: POST /upload/gmail/v1/users/ userId /messages/send
মেটাডেটার জন্য স্ট্যান্ডার্ড রিসোর্স URI। যদি সম্পদে কোনো ডেটা ক্ষেত্র থাকে, সেই ক্ষেত্রগুলি আপলোড করা ফাইলের বর্ণনা মেটাডেটা সংরক্ষণ করতে ব্যবহৃত হয়। মেটাডেটা মান তৈরি বা আপডেট করার সময় আপনি এই URI ব্যবহার করতে পারেন।
উদাহরণ: POST /gmail/v1/users/ userId /messages/send

সহজ আপলোড

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

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

সহজ আপলোড ব্যবহার করতে, পদ্ধতির /আপলোড 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 অনুরোধ করতে পারেন। সংযোগ ব্যর্থ হলে আপনি যে ডেটা পাঠাচ্ছেন তা সম্পূর্ণরূপে আবার আপলোড করার জন্য যথেষ্ট ছোট হলে এটি একটি ভাল পছন্দ।

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

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

মাল্টিপার্ট আপলোড রিকোয়েস্ট করার সময় ব্যবহার করা টপ-লেভেল HTTP হেডারগুলির মধ্যে রয়েছে:

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

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

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

মেটাডেটা অংশ: প্রথমে আসতে হবে, এবং Content-Type অবশ্যই একটি গৃহীত মেটাডেটা ফর্ম্যাটের সাথে মিলবে।
মিডিয়া অংশ: দ্বিতীয় স্থানে আসতে হবে, এবং 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/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
}

পুনরায় শুরুযোগ্য আপলোড

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

পুনঃসূচনাযোগ্য আপলোড ব্যবহার করার পদক্ষেপগুলির মধ্যে রয়েছে:

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

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

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

ধাপ 1: একটি পুনরায় শুরু করা সেশন শুরু করুন

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

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

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

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 এ সেট করুন।

পরবর্তী বিভাগ বর্ণনা করে কিভাবে প্রতিক্রিয়া পরিচালনা করতে হয়।

ধাপ 2: পুনরায় শুরু করা সেশন URI সংরক্ষণ করুন

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

উদাহরণ: পুনরায় শুরু করা সেশন শুরুর প্রতিক্রিয়া

এখানে 1 ধাপে অনুরোধের প্রতিক্রিয়া রয়েছে:

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 শিরোলেখের মান, উপরের উদাহরণের প্রতিক্রিয়া হিসাবে দেখানো হয়েছে, প্রকৃত ফাইল আপলোড করার জন্য বা আপলোড স্থিতি অনুসন্ধান করার জন্য আপনি HTTP এন্ডপয়েন্ট হিসাবে ব্যবহার করবেন সেশন URI।

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

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

ফাইলটি আপলোড করতে, আপলোড URI-তে একটি PUT অনুরোধ পাঠান যা আপনি আগের ধাপে পেয়েছেন। আপলোড অনুরোধের বিন্যাস হল:

PUT session_uri

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

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

বর্তমান উদাহরণের জন্য সম্পূর্ণ 2,000,000 বাইট ইমেল বার্তা ফাইলটি আপলোড করার জন্য এখানে একটি পুনরায় শুরু করার অনুরোধ রয়েছে৷

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 অ্যাপ ইঞ্জিন অনুরোধের নির্দিষ্ট শ্রেণীর জন্য সত্য। এটি আপনাকে লিগ্যাসি ব্রাউজারগুলির জন্য আপলোড অগ্রগতির ইঙ্গিত প্রদান করার মতো জিনিসগুলিও করতে দেয় যেখানে ডিফল্টরূপে আপলোড অগ্রগতি সমর্থন নেই৷

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

আপনি যদি খণ্ডে ডেটা আপলোড করছেন, সম্পূর্ণ ফাইল আপলোডের জন্য প্রয়োজনীয় 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 বাইট) আকারের একাধিক হতে হবে। আপনি যদি চাঙ্কিং ব্যবহার করেন, আপলোডটি কার্যকর রাখতে খণ্ডের আকার যতটা সম্ভব বড় রাখা গুরুত্বপূর্ণ।

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

একটি অনুরোধ যা প্রথম 524,288 বাইট পাঠায় তা দেখতে এইরকম হতে পারে:

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 প্রতিক্রিয়া পান, তবে একটি বাধাপ্রাপ্ত আপলোড পুনরায় শুরু করুন- এ বর্ণিত পদ্ধতিটি অনুসরণ করুন, তবে বাকি ফাইল আপলোড করার পরিবর্তে, কেবলমাত্র থেকে খণ্ডগুলি আপলোড করা চালিয়ে যান যে বিন্দু.

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

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

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

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

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

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

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

1) আপলোড স্থিতি অনুরোধ.

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

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

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

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

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

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

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

নিম্নলিখিত অনুরোধটি ফাইলের অবশিষ্ট বাইট পাঠিয়ে আপলোড পুনরায় শুরু করে, বাইট 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 ত্রুটিগুলি হ্যান্ডেল করুন।

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

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

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

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

API এ একটি অনুরোধ করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
1 সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
2 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
4 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
8 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
16 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
থামো। একটি ত্রুটি রিপোর্ট বা লগ.

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

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

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