অ্যাটাচমেন্ট আপলোড করুন

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

আপলোড করার বিকল্প

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

  • আপলোড করা ফাইলের সর্বাধিক সাইজ: এই পদ্ধতিতে আপনি সর্বাধিক যত পরিমাণ ডেটা স্টোর করতে পারবেন।
  • গ্রহণযোগ্য মিডিয়া 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-এর নির্দিষ্ট কিছু অনুরোধের ক্ষেত্রে হয়। এছাড়াও, এটি আপনাকে লিগ্যাসি ব্রাউজারের জন্য আপলোড প্রগ্রেস ইন্ডিকেশন প্রদান করার মতো কাজ করতে দেয় যেগুলিতে ডিফল্টভাবে আপলোড প্রগ্রেস সাপোর্ট নেই।

বাধাগ্রস্ত আপলোড আবার শুরু করা

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

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

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

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

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

নিম্নলিখিত অনুরোধে Content-Range হেডার ব্যবহার করে দেখানো হয়েছে যে ২,০০০,০০০ বাইট ফাইলের বর্তমান পজিশন অজানা।

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 হতে পারে। সব বাইট আপলোড হওয়ার পরে কিন্তু ক্লায়েন্ট সার্ভার থেকে উত্তর পাওয়ার আগে কানেকশন বিচ্ছিন্ন হয়ে গেলে এটি হতে পারে।

৩) যেখানে আপলোড বন্ধ হয়ে গিয়েছিল সেখান থেকে আবার শুরু করুন।

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

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. ১ সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার করুন।
  4. HTTP 503 উত্তর পান, যা ইঙ্গিত করে যে আপনাকে অনুরোধটি আবার চেষ্টা করতে হবে।
  5. ২ সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার করুন।
  6. HTTP 503 উত্তর পান, যা ইঙ্গিত করে যে আপনাকে অনুরোধটি আবার চেষ্টা করতে হবে।
  7. ৪ সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার করার চেষ্টা করুন।
  8. HTTP 503 উত্তর পান, যা ইঙ্গিত করে যে আপনাকে অনুরোধটি আবার চেষ্টা করতে হবে।
  9. ৮ সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার করার চেষ্টা করুন।
  10. HTTP 503 উত্তর পান, যা ইঙ্গিত করে যে আপনাকে অনুরোধটি আবার চেষ্টা করতে হবে।
  11. ১৬ সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার করার চেষ্টা করুন।
  12. বন্ধ করো। কোনও সমস্যার ব্যাপারে অভিযোগ জানান বা লগ করুন।

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

মনে রাখবেন: অপেক্ষার সময় সবসময় (২ ^ n) + random_number_milliseconds, যেখানে n হল একটি একঘেয়ে ক্রমবর্ধমান পূর্ণসংখ্যা যা প্রাথমিকভাবে ০ হিসাবে সংজ্ঞায়িত করা হয়। প্রতিটি ইটারেশনের (প্রতিটি অনুরোধ) জন্য পূর্ণসংখ্যা n-এর মান ১ করে বৃদ্ধি পায়।

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

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