fetch, HTTP আর JSON API — সার্ভারের সাথে কথা বলা

১ · পাতা রিলোড ছাড়াই সার্ভারের সাথে কথা — request আর response

একটি অনলাইন বাজারের ওয়েবসাইট খুলুন। চালের দাম হঠাৎ বদলে গেল, অথচ আপনি পাতা রিলোড করেননি। “অর্ডার করুন” চাপলেন, বোতামের পাশে ছোট্ট একটি ঘূর্ণি ঘুরল, তারপর লেখা এল “অর্ডার নম্বর A-101”. পুরো পাতা একবারও নতুন করে লোড হয়নি। পেছনে যা ঘটল তা হলো: পাতার JavaScript চুপচাপ দূরের একটি সার্ভারকে বার্তা পাঠিয়েছে, উত্তর পেয়েছে, আর সেই উত্তর দিয়ে পাতার একটি অংশ বদলে দিয়েছে। এই বার্তা আদান-প্রদানের ভাষার নাম HTTP — HyperText Transfer Protocol.

HTTP-র কথোপকথন সবসময় একই ছাঁচে হয়। একপক্ষ — client, সাধারণত ব্রাউজার বা মোবাইল অ্যাপ — একটি request পাঠায়। অন্যপক্ষ — server — একটি response ফেরত দেয়। সার্ভার নিজে থেকে কখনো কথা শুরু করে না; প্রতিটি উত্তর কোনো একটি অনুরোধের জবাব (সার্ভার থেকে নিজে বার্তা পাঠানোর ব্যবস্থা পর্ব ৫১-এ)। দুই বার্তারই নির্দিষ্ট গঠন আছে:

ব্রাউজারে JavaScript দিয়ে এই কাজের আধুনিক পথ হলো fetch() — একটি Web API, ভাষার অংশ নয়, কিন্তু সব আধুনিক ব্রাউজারে আর Node.js 18 থেকে Node-এও আছে। fetch তৈরি হয়েছে Promise-এর ওপর, তাই পর্ব ৩৪-এর async/await দিয়েই এর সব কাজ লেখা যায়। আর যেসব সার্ভার প্রোগ্রামকে ডেটা দেওয়ার জন্যই বানানো, তাদের বলে API — Application Programming Interface: মানুষের জন্য HTML পাতা নয়, প্রোগ্রামের জন্য JSON.

২ · URL — ঠিকানার অংশ, আর query string নিরাপদে বানানো

প্রতিটি request যায় একটি URL-এ। একটি URL ভাঙলে কয়েকটি অংশ পাওয়া যায়, আর প্রতিটির আলাদা কাজ:

এখন একটি সাধারণ ভুল দেখুন। সার্চ বক্সে কেউ লিখলেন চা & দই, আর কোড হাতে জোড়া দিল: "/api/products?q=" + text + "&page=2". ফল দাঁড়াল ?q=চা & দই&page=2. সার্ভারের চোখে & মানে “নতুন জোড়া শুরু”, তাই সে পড়ে q = "চা " আর " দই" নামে একটি খালি key — খোঁজার শব্দ অর্ধেক হারিয়ে গেল। কেউ ইচ্ছা করে x&admin=true লিখলে বাড়তি শর্ত ঢুকে যেত। URL-এ বিশেষ অক্ষর (&, =, ?, #, ফাঁকা) আর বাংলার মতো non-ASCII লেখা পাঠাতে হয় percent-encoding করে — প্রতিটি byte %XX আকারে। এই কাজের সঠিক যন্ত্র হলো built-in URL আর URLSearchParams:

1const url = new URL("/api/products", "https://shop.example.com");2url.searchParams.set("category", "rice");3url.searchParams.set("q", "চা & দই");4url.searchParams.set("page", 2);5console.log(url.searchParams.get("q"), url.href);

ছোট কাজে আরও সংক্ষেপে লেখা যায়: new URLSearchParams({ category: "rice", page: 2 }) একটি object থেকেই query বানায়, আর template literal-এ বসালে নিজে থেকে string হয় — `/api/products?${params}`. Path-এর ভেতরে ব্যবহারকারীর লেখা বসাতে হলে (/api/users/${name}) encodeURIComponent(name) দিন; নইলে নামের / পথটিকেই বদলে দেবে।

৩ · Method, status code আর header — HTTP-র শব্দভান্ডার

Method — কী করতে চাই

Request-এর প্রথম শব্দটি HTTP method — সার্ভারকে জানায় আপনার উদ্দেশ্য কী। ওয়েব API-তে পাঁচটি method-ই বেশি দেখবেন:

শেষ কলামটি গুরুত্বপূর্ণ। কোনো অনুরোধ idempotent মানে একবার পাঠানো আর পরপর দশবার পাঠানোর ফল সার্ভারের অবস্থায় একই। “কার্টে item 7-এর পরিমাণ ৩ করুন” (PUT) দশবার পাঠালেও পরিমাণ ৩-ই থাকে। কিন্তু “নতুন অর্ডার দিন” (POST) দশবার গেলে দশটি অর্ডার! নেটওয়ার্ক মাঝপথে কেটে গেলে আপনি জানেন না অনুরোধ পৌঁছেছিল কি না — idempotent অনুরোধ তখন নিশ্চিন্তে আবার পাঠানো যায়, POST নয়। এজন্য পেমেন্ট API-গুলো (যেমন অনেক payment gateway) POST-এর সাথে একটি Idempotency-Key header চায়, যাতে একই key দুবার এলে সার্ভার দ্বিতীয়টি চিনে বাদ দিতে পারে। Retry নিয়ে আরও কথা পর্ব ৩৬-এ।

Status code — উত্তরের সারকথা এক সংখ্যায়

Response-এর প্রথম লাইনে থাকে তিন অঙ্কের status code. প্রথম অঙ্ক দেখেই পরিবার চেনা যায়: 2xx সফল, 3xx অন্য জায়গায় দেখুন, 4xx client-এর ভুল (অনুরোধে সমস্যা), 5xx server-এর ভুল। যেগুলো সবচেয়ে বেশি দেখবেন:

Header — বার্তার খামের ওপর লেখা তথ্য

Header হলো নাম: মান আকারের লাইন — body-র বাইরে বাড়তি তথ্য। নাম case মানে না (content-type আর Content-Type একই)। সবচেয়ে দরকারি কয়েকটি: Content-Type জানায় body কোন ফরম্যাটে (application/json, text/html, multipart/form-data); Accept জানায় client কোন ফরম্যাটে উত্তর চায়; Authorization-এ থাকে পরিচয়ের প্রমাণ, যেমন Bearer <token>; আর Cache-Control, ETag ঠিক করে উত্তর কতক্ষণ জমিয়ে রাখা যাবে (অংশ ৮)। JavaScript-এ res.headers.get("content-type") দিয়ে পড়া যায়।

REST আর JSON API

বেশিরভাগ ওয়েব API একটি সহজ রীতি মেনে বানানো হয়, যাকে বলে REST: সার্ভারের সবকিছু হলো resource (পণ্য, অর্ডার, ব্যবহারকারী), প্রতিটির একটি ঠিকানা আছে, আর কী করবেন তা বলে method. পণ্যের তালিকা GET /api/products, একটি পণ্য GET /api/products/7, নতুন অর্ডার POST /api/orders, একটি অর্ডার বাতিল DELETE /api/orders/A-101. প্রতিটি “method + ঠিকানা” জোড়াকে বলে একটি endpoint. URL-এ ক্রিয়াপদ (/getProducts, /deleteOrder?id=…) না রেখে নামপদ রাখা আর কাজ method-কে দেওয়া — এটুকু মানলেই API অনেক বেশি অনুমানযোগ্য হয়। এমন একটি API নিজে বানাবেন পর্ব ৫০-এ।

৪ · fetch() — একটি অনুরোধের জীবন, আর দুই ধাপের Promise

সবচেয়ে সরল ব্যবহার এক লাইনের: const res = await fetch("/api/products?category=rice&page=2");. দ্বিতীয় argument-এ একটি options object দেওয়া যায় — method, headers, body, signal, credentials, cache ইত্যাদি। কিন্তু ভেতরে আসলে কী ঘটে, আর কেন একটি নয়, দুটি await লাগে? ধাপে ধাপে দেখুন:

const p = fetch("/api/products?category=rice&page=2",
  { headers: { Accept: "application/json" } });
console.log(p);        // Promise { <pending> }
const res = await p;   // এখানে অপেক্ষা — main thread কিন্তু খালি

GET /api/products?category=rice&page=2 HTTP/1.1
Host: shop.example.com
Accept: application/json
User-Agent: Mozilla/5.0 …         ← ব্রাউজার যোগ করেছে
Cookie: session=…                 ← একই origin হলে

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

// JavaScript-এ:
res.status    // 200
res.ok        // true  (200–299 হলে true)
res.bodyUsed  // false
// 404 হলেও এই ধাপে Promise পূর্ণ হয় — শুধু ok হতো false

const data = await res.json();   // বা res.text(), res.blob()
// টুকরো ১: {"category":"rice","items":[{"id":7,"na
// টুকরো ২: me":"মিনিকেট চাল ৫ কেজি","price":420}, …
// সব টুকরো জমিয়ে → UTF-8 decode → JSON.parse

data.items[0].name   // "মিনিকেট চাল ৫ কেজি"
res.bodyUsed         // true
await res.text();     // TypeError — body একবারই পড়া যায়

৫ · res.ok যাচাই — getJSON helper আর HttpError

প্রতিটি fetch-এর পাশে একই যাচাই লিখলে কোড পুনরাবৃত্তিতে ভরে যায়, আর কোথাও না কোথাও ভুলে যাবেনই। পেশাদার কোডে তাই একটি ছোট helper থাকে — getJSON(url) বা api(path, options) — যা তিনটি সম্ভাব্য ফলকে তিনটি স্পষ্ট পথে পাঠায়। সিদ্ধান্তের গাছটি দেখুন:

TypeError: Failed to fetch                          ← Edge/Chrome
TypeError: NetworkError when attempting to fetch resource.  ← Firefox
TypeError: fetch failed   (cause: ECONNREFUSED …)   ← Node.js
→ “ইন্টারনেট সংযোগ দেখে আবার চেষ্টা করুন”

if (!res.ok) { … }        // ok = status 200–299
// এখনো body ছোঁয়া হয়নি — কোন method-এ পড়ব তা পরে ঠিক হবে

const body = isJSON ? await res.json() : await res.text();
throw new HttpError(res.status, body);
// 401 → লগইন পাতায় · 404 → “পণ্যটি নেই” · 422 → ফর্মে লাল দাগ
// 429/503 → একটু পরে আবার চেষ্টা · 500 → “আমাদের দিকে সমস্যা”

if (res.status === 204) return null;   // body নেই
return await res.json();   // JSON না হলে SyntaxError — সেটাও ধরা পড়বে

এবার পুরো ধারণাটি চালিয়ে দেখুন। এই পাতার কোড-বক্সে ইন্টারনেট নেই, তাই আমরা একটি নকল fakeFetch বানিয়েছি, যা সত্যিকারের Response object ফেরত দেয় — ব্রাউজারের আসল fetch ঠিক এই class-এর object-ই দেয়। একটি পণ্য পাওয়া যায়, একটি 404, আর একটি 502 যার body HTML:

const products = { 7: { name: "মিনিকেট চাল ৫ কেজি", price: 420 } };
const reply = (body, status, type = "application/json") =>
  new Response(body, { status, headers: { "Content-Type": type } });
async function fakeFetch(url) {                 // নেটওয়ার্ক ছাড়া "সার্ভার"
  const id = url.split("/").at(-1);
  if (id === "boom") return reply("<h1>502 Bad Gateway</h1>", 502, "text/html");
  return products[id] ? reply(JSON.stringify(products[id]), 200) : reply('{"error":"পণ্য পাওয়া যায়নি"}', 404);
}
class HttpError extends Error {
  name = "HttpError";
  constructor(status, body) { super(`HTTP ${status}`); this.status = status; this.body = body; }
}
async function getJSON(url) {
  const res = await fakeFetch(url);              // 404 হলেও এখানে reject হয় না
  const body = res.headers.get("Content-Type")?.includes("json") ? await res.json() : await res.text();
  if (!res.ok) throw new HttpError(res.status, body);
  return body;
}
(async () => {
  for (const id of ["7", "99", "boom"]) {
    try { const p = await getJSON(`/api/products/${id}`); console.log("পেলাম:", p.name, p.price); }
    catch (e) { console.log(e.name, e.status, e.body.error ?? e.body); }
  }
  const res = await fakeFetch("/api/products/7");
  console.log(res.ok, res.status, res.bodyUsed, await res.json(), res.bodyUsed);
  await res.text().catch((e) => console.log(`${e.name}: ${e.message}`));
})();

৬ · ডেটা পাঠানো — POST JSON, 201 বনাম 422, আর FormData

GET দিয়ে ডেটা আনা হলো, এবার পাঠানোর পালা। অর্ডার দিতে তিনটি জিনিস লাগে: method: "POST", body কোন ফরম্যাটে তা জানাতে Content-Type header, আর body নিজে — string হিসেবে। JavaScript object সরাসরি body-তে দিলে fetch তাকে "[object Object]" লেখায় বদলে পাঠায়; তাই JSON.stringify অবশ্যই। Request আর উত্তর দুটোকেই খুলে দেখুন:

POST /api/orders HTTP/1.1
Host: shop.example.com

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 24          ← ব্রাউজার নিজে গোনে

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 24

{"productId":7,"qty":2}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/A-101

{"id":"A-101","productId":7,"qty":2}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors":{"qty":"পরিমাণ অন্তত ১ হতে হবে"}}
// res.ok === false → HttpError → ফর্মের qty ঘরের নিচে লাল লেখা

এখন সত্যিকারের নেটওয়ার্ক। নিচের বক্সটি Node.js 20-এ চলে, যেখানে fetch global হিসেবে আছে। একই প্রোগ্রামে আমরা ছোট্ট একটি HTTP সার্ভার চালু করি (port 0 মানে “যেকোনো খালি port দিন”), তারপর তার কাছে সত্যিকারের অনুরোধ পাঠাই — GET with query, দুটি POST (একটি সফল, একটি যাচাইয়ে ব্যর্থ), একটি 404, আর শেষে সার্ভার বন্ধ করে একটি network error:

const http = require("node:http");
const send = (res, status, data) =>
  res.writeHead(status, { "Content-Type": "application/json", Connection: "close" }).end(JSON.stringify(data));
const server = http.createServer(async (req, res) => {          // ছোট্ট সার্ভার
  const url = new URL(req.url, "http://127.0.0.1");
  if (req.method === "GET" && url.pathname === "/api/products")
    return send(res, 200, { category: url.searchParams.get("category"), page: +url.searchParams.get("page") });
  if (req.method !== "POST" || url.pathname !== "/api/orders") return send(res, 404, { error: "পাওয়া যায়নি" });
  let text = "";
  for await (const chunk of req) text += chunk;                // body টুকরো টুকরো আসে
  const order = JSON.parse(text);
  order.qty > 0 ? send(res, 201, { id: "A-101", ...order }) : send(res, 422, { error: "qty ০-এর বেশি হতে হবে" });
});
server.listen(0, "127.0.0.1", async () => {                     // client অংশ
  const base = `http://127.0.0.1:${server.address().port}`;
  const q = new URLSearchParams({ category: "rice", page: 2 });
  let res = await fetch(`${base}/api/products?${q}`);
  console.log(res.status, res.headers.get("content-type"), await res.json());
  for (const qty of [2, 0]) {
    res = await fetch(`${base}/api/orders`, { method: "POST",
      headers: { "Content-Type": "application/json" }, body: JSON.stringify({ productId: 7, qty }) });
    console.log(res.status, res.ok, await res.json());
  }
  res = await fetch(`${base}/api/products/999`);
  console.log(res.status, res.ok, await res.json());
  server.close(() => fetch(base).catch((e) => console.log(e.name, e.message, e.cause.code)));
});

FormData আর ফাইল আপলোড

প্রোফাইল ছবি বা NID-এর স্ক্যান পাঠাতে JSON সুবিধার নয় — binary ফাইলকে লেখায় বদলালে আকার প্রায় এক-তৃতীয়াংশ বাড়ে। এর জন্য আছে FormData, যা multipart/form-data ফরম্যাটে পাঠায় — HTML ফর্ম যেভাবে পাঠায়:

const form = document.querySelector("#profile-form");      // <input type="file" name="photo"> আছে
const data = new FormData(form);                            // ফর্মের সব ঘর একসাথে
data.append("userId", "12");

const res = await fetch("/api/profile/photo", {
  method: "POST",
  body: data,            // Content-Type নিজে লিখবেন না!
});
if (!res.ok) throw new HttpError(res.status, await res.text());

একটি সূক্ষ্ম কথা: FormData-র সাথে Content-Type header নিজে লিখবেন না। ব্রাউজার নিজে multipart/form-data; boundary=----… লেখে, যেখানে boundary হলো অংশগুলোর মাঝের বিভাজক চিহ্ন; আপনি হাতে লিখলে boundary বাদ পড়ে আর সার্ভার body ভাঙতে পারে না। ছোট সাধারণ ফর্মের জন্য URLSearchParams-কে body করলে যায় application/x-www-form-urlencoded. আপলোডের অগ্রগতি (৪০% … ৮০%) দেখানো fetch-এ এখনো সহজ নয় — এই একটি কাজে অনেকে আজও পুরোনো XMLHttpRequest-এর upload.onprogress ব্যবহার করেন (অংশ ৮)।

৭ · ব্যর্থতার রকমফের — network error, timeout, cookie আর CORS

বাস্তবের নেটওয়ার্ক অনির্ভরযোগ্য: লোডশেডিংয়ে রাউটার বন্ধ, মেট্রোরেলে সুড়ঙ্গে ঢুকে মোবাইল ডেটা নেই, সার্ভার ব্যস্ত। ভালো অ্যাপ আগে থেকেই জানে কোন ব্যর্থতা কেমন দেখায়:

Timeout — অনন্ত অপেক্ষা নয়

fetch-এর নিজের কোনো সময়সীমা নেই। সার্ভার উত্তর না দিলে ব্রাউজার বা অপারেটিং সিস্টেমের নিজস্ব সীমা (প্রায়ই কয়েক মিনিট) পর্যন্ত ব্যবহারকারী ঘূর্ণির দিকে তাকিয়ে থাকেন। আধুনিক সমাধান এক লাইনের: fetch(url, { signal: AbortSignal.timeout(8000) }) — ৮ সেকেন্ডে উত্তর না এলে Promise reject হয় TimeoutError নামের DOMException দিয়ে। এখানে AbortSignal হলো একটি “থামার সংকেত”, যা fetch-কে মাঝপথে বাতিল করতে পারে। ব্যবহারকারী অন্য পাতায় চলে গেলে বা নতুন করে সার্চ করলে পুরোনো অনুরোধ বাতিল করা, একাধিক সংকেত জোড়া দেওয়া আর বুদ্ধিমান retry — সবকিছু পর্ব ৩৬-এ।

Cookie আর credentials

লগইন করার পর সার্ভার সাধারণত একটি session cookie দেয় (cookie-র খুঁটিনাটি পর্ব ৪০-এ)। fetch cookie পাঠাবে কি না তা ঠিক করে credentials option: "same-origin" (ডিফল্ট — শুধু নিজের সাইটে পাঠায়), "include" (অন্য origin-এও পাঠায়, যেমন shop.example.com থেকে api.example.com), আর "omit" (কখনো না)। "include" দিলেও সার্ভারকে স্পষ্টভাবে অনুমতি দিতে হয়, নইলে ব্রাউজার উত্তর আটকে দেয় — যা আমাদের নিয়ে যায় CORS-এ।

CORS — এক অনুচ্ছেদে

ধরুন আপনি evil.example সাইটে ঢুকলেন, আর সেই পাতার JavaScript চুপিচুপি আপনার ব্যাংকের API-তে fetch করে আপনার cookie দিয়ে ব্যালান্স পড়ে নিল — ভয়ংকর। এটি ঠেকাতে ব্রাউজার same-origin policy মানে: একটি পাতার JavaScript সাধারণত শুধু নিজের origin-এর (protocol + host + port একই) উত্তর পড়তে পারে। CORS (Cross-Origin Resource Sharing) হলো এই নিয়মের নিয়ন্ত্রিত ব্যতিক্রম: সার্ভার উত্তরের header-এ (Access-Control-Allow-Origin) জানায় কোন origin তার উত্তর পড়তে পারবে; অনুমতি না থাকলে ব্রাউজার উত্তরটি JavaScript-এর হাতে দেয় না, আর fetch reject হয় একই সাধারণ TypeError দিয়ে। মনে রাখার দুটি কথা: CORS প্রয়োগ করে ব্রাউজার (Node.js বা curl-এ CORS নেই), আর সিদ্ধান্ত নেয় সার্ভার — তাই CORS error front-end কোড বদলে সারানো যায় না, এবং mode: "no-cors" দিলে কেবল একটি পড়া-যায়-না এমন “opaque” উত্তর পাবেন। Preflight, credentials-এর নিয়ম আর নিরাপদ কনফিগারেশন পর্ব ৪৩-এ।

৮ · বাস্তব অ্যাপে — loading অবস্থা, cache, গোপন key আর DevTools

UI-র চারটি অবস্থা

প্রতিটি fetch-নির্ভর অংশের অন্তত চারটি অবস্থা থাকে, আর ব্যবহারকারীকে প্রতিটি দেখাতে হয়: loading (spinner বা skeleton — “আনছি”), success (ডেটা), empty (সফল কিন্তু কিছু নেই — “এই ক্যাটাগরিতে এখন কোনো পণ্য নেই”, যা error নয়!), আর error (বোধগম্য বার্তা আর একটি “আবার চেষ্টা করুন” বোতাম)। AI-এর লেখা অনেক কোডে শুধু success অবস্থা থাকে; ধীর নেটওয়ার্কে পাতা ফাঁকা পড়ে থাকে আর ব্যবহারকারী বোতাম বারবার চাপেন — ফলে একই POST কয়েকবার যায়। তাই অনুরোধ চলার সময় বোতাম নিষ্ক্রিয় রাখুন। একটি আবহাওয়া বা মুদ্রার হার দেখানোর widget-এর জন্য ভাবনাটি এরকম:

function bnMessage(err) {
  if (err.name === "TimeoutError") return "সার্ভার সাড়া দিতে দেরি করছে, একটু পরে চেষ্টা করুন।";
  if (err instanceof HttpError) {
    if (err.status === 404) return "এই শহরের তথ্য পাওয়া যায়নি।";
    if (err.status === 429) return "খুব দ্রুত অনেকবার চাওয়া হয়েছে, এক মিনিট অপেক্ষা করুন।";
    if (err.status >= 500) return "আমাদের দিকে সমস্যা হয়েছে, আমরা দেখছি।";
    return "অনুরোধটি গ্রহণ করা যায়নি।";
  }
  return "ইন্টারনেট সংযোগ দেখে আবার চেষ্টা করুন।";   // network error
}

async function showRate(box, currency) {
  box.textContent = "লোড হচ্ছে…";                          // loading
  try {
    const url = new URL("/api/rates", location.origin);
    url.searchParams.set("base", currency);
    const data = await getJSON(url, { signal: AbortSignal.timeout(8000) });
    box.textContent = data.rate ? `১ ${currency} = ${data.rate} টাকা` : "এখন হার পাওয়া যাচ্ছে না।";
  } catch (err) {
    box.textContent = bnMessage(err);                       // error + retry বোতাম দেখান
  }
}

এখানে getJSON ধরে নেওয়া হয়েছে অংশ ৫-এর মতো, তবে দ্বিতীয় argument-এ options নিয়ে আসল fetch-এ পাঠায়। দেখুন, বার্তাগুলো ব্যবহারকারীর ভাষায়, কারিগরি শব্দ ছাড়া; আর আসল error-এর বিস্তারিত (status, body) পাঠানো উচিত আপনার log বা error monitoring ব্যবস্থায়, পর্দায় নয়।

Cache — একই জিনিস বারবার না আনা

পণ্যের তালিকা প্রতি সেকেন্ডে বদলায় না। সার্ভার উত্তরের সাথে Cache-Control header দিয়ে বলে দিতে পারে কতক্ষণ কপিটি জমিয়ে রাখা চলবে — যেমন Cache-Control: max-age=60 মানে “৬০ সেকেন্ড আমাকে আবার জিজ্ঞেস না করে এই কপিই ব্যবহার করুন”, আর no-store মানে “কখনো জমাবেন না” (ব্যাংকের তথ্যের জন্য)। সময় পেরোলে ব্রাউজার ETag দিয়ে জিজ্ঞেস করে “আমার কপি কি এখনো ঠিক?” — না বদলালে সার্ভার body ছাড়াই 304 Not Modified পাঠায়। এই cache ব্রাউজার নিজেই সামলায়, আপনার fetch কোড বদলাতে হয় না; চাইলে fetch(url, { cache: "no-store" }) দিয়ে প্রতি অনুরোধে নিয়ন্ত্রণ করা যায়। অফলাইনে চলা অ্যাপের জন্য নিজের হাতে cache সামলানো পর্ব ৪৪-এ।

গোপন API key কখনো front-end-এ নয়

XMLHttpRequest আর axios — পুরোনো আর বিকল্প পথ

fetch-এর আগে ছিল XMLHttpRequest (XHR) — callback-ভিত্তিক, event-এ ভরা API, যা দিয়ে Ajax যুগ শুরু হয়েছিল (ভাবনার প্রশ্ন ২)। পুরোনো কোডে আজও দেখবেন:

// পুরোনো ধাঁচ — শুধু চেনার জন্য
const xhr = new XMLHttpRequest();
xhr.open("GET", "/api/products/7");
xhr.onload = () => {
  if (xhr.status === 200) console.log(JSON.parse(xhr.responseText));
};
xhr.onerror = () => console.log("network error");
xhr.send();

// axios (npm library) — একই কাজ
const { data } = await axios.get("/api/products/7");   // 4xx/5xx-এ নিজে থেকে reject করে

axios একটি জনপ্রিয় npm library (পর্ব ৪৬), যা ব্রাউজারে XHR আর Node-এ নিজস্ব HTTP ব্যবস্থার ওপর বানানো। এর সুবিধা: 2xx-এর বাইরে নিজে থেকেই reject করে, JSON নিজে parse করে, timeout আর “interceptor” (প্রতিটি অনুরোধে token যোগ করার মতো কাজ) সহজ, আপলোডের অগ্রগতি দেখায়। অসুবিধা: আলাদা একটি dependency, যা bundle-এর আকার বাড়ায়। আজ অনেক দল অংশ ৫-এর মতো ২০–৩০ লাইনের নিজস্ব fetch wrapper দিয়েই কাজ সারে।

Streaming — পুরো body-র জন্য অপেক্ষা না করা

res.json() পুরো body আসা পর্যন্ত অপেক্ষা করে। কিন্তু AI চ্যাটের উত্তর যেভাবে শব্দে শব্দে ভেসে ওঠে, বা বড় ফাইলের ডাউনলোডের অগ্রগতি — এসবের জন্য body-কে টুকরো ধরে পড়তে হয়। res.body একটি ReadableStream: const reader = res.body.getReader(), তারপর লুপে const { done, value } = await reader.read(); প্রতিটি value একটি byte-এর টুকরো (Uint8Array), যা TextDecoder দিয়ে লেখায় বদলানো যায়। ব্রাউজারে আর Node 20-এ for await (const chunk of res.body)-ও চলে (পর্ব ২৭-এর async iterator). লাইনে লাইনে JSON (পর্ব ১৯-এর NDJSON) বা Server-Sent Events (পর্ব ৫১) এভাবেই পড়া হয়।

DevTools-এর Network tab — আপনার সেরা বন্ধু

fetch-এর যেকোনো সমস্যায় প্রথম কাজ: DevTools (F12) খুলে Network tab, তারপর পাতায় কাজটি আবার করুন। প্রতিটি অনুরোধের একটি সারি দেখবেন — method, status, ধরন, আকার, সময়। সারিতে ক্লিক করলে Headers (কোন URL-এ কোন header গেল, কোন status এল), Payload (আপনার পাঠানো body — [object Object] দেখলেই বুঝবেন JSON.stringify ভুলেছেন), Response (সার্ভার আসলে কী পাঠাল) আর Timing. “Fetch/XHR” ফিল্টার শুধু API অনুরোধ দেখায়, “Throttling” দিয়ে ধীর 3G-র মতো নেটওয়ার্ক নকল করে loading অবস্থা পরীক্ষা করা যায়, আর “Offline” দিয়ে network error. সারিতে ডান-ক্লিক করে “Copy as fetch” দিলে পুরো অনুরোধটি কোড হিসেবে পাওয়া যায়।

৯ · AI-এর যুগে — fetch কোডে AI-এর চেনা ভুল

“একটি API থেকে পণ্য এনে দেখাও” — AI এক সেকেন্ডে কোড দেবে, আর ডেমোতে সেটি নিখুঁত চলবে। কারণ ডেমোতে নেটওয়ার্ক ভালো, সার্ভার সুস্থ, ডেটা ঠিক। সমস্যা আসে প্রোডাকশনে, প্রথম 500, প্রথম ধীর মোবাইল সংযোগ বা প্রথম দুষ্টু ইনপুটে। AI-এর লেখা fetch কোডে বারবার যে ভুলগুলো দেখা যায়:

AI-এর লেখা fetch কোড — যাচাইয়ের চেকলিস্ট

• প্রতিটি fetch-এর পর body পড়ার আগে res.ok (বা status) যাচাই আছে, আর ব্যর্থতায় status-সহ error ছোড়া হয়
• Query আর path-এ ব্যবহারকারীর লেখা URLSearchParams বা encodeURIComponent দিয়ে বসানো
• POST/PUT/PATCH-এ body JSON.stringify করা, Content-Type ঠিক; FormData-র সাথে Content-Type হাতে লেখা নেই
• Timeout আছে, আর network error, timeout ও HTTP error আলাদা বার্তা পায়
• UI-তে loading, empty আর error অবস্থা আছে; অনুরোধ চলার সময় বোতাম নিষ্ক্রিয়
• কোনো গোপন key, token বা পাসওয়ার্ড front-end কোডে বা প্রকাশ্য env-এ নেই; দাম বা অনুমতির মতো সিদ্ধান্ত সার্ভারে
• DevTools-এর Network tab-এ Offline আর ধীর 3G দিয়ে নিজে চালিয়ে দেখেছি