পাঠ্যক্রম খুলুন
প্রাথমিক পর্যায়

Client–Server: request ও response-এর সম্পর্ক

Client–Server Architecture

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12
আগে পড়ে নিনSystem Design কী ও কেন ↗
এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

  • Client ও server-এর আলাদা দায়িত্ব
  • Request ও response-এর সীমা বোঝা
  • Server-side validation কেন দরকার

সমস্যা দিয়ে শুরু

একটি mobile app-এ product-এর price ৫০০ টাকা। কেউ request বদলে price ১ টাকা পাঠাল। Server যদি client-এর price দিয়েই order তৈরি করে, সুন্দর interface থাকা সত্ত্বেও ভুল order হবে। Client ও server কোন তথ্যের জন্য দায়ী—এটি প্রথম architecture decision-গুলোর একটি।

সহজ করে বুঝি

Client ব্যবহারকারীর কাজ প্রকাশ করে: browser, mobile app অথবা অন্য service। Server request গ্রহণ করে, পরিচয় ও permission যাচাই করে, business rule চালায় এবং response দেয়। একই server একাধিক ধরনের client-এর সেবা দিতে পারে।

Client UI-তে validation করলে দ্রুত feedback পাওয়া যায়। কিন্তু client আপনার নিয়ন্ত্রণে আছে ধরে নেওয়া যাবে না। Authorization, price calculation এবং stock-এর মতো authoritative সিদ্ধান্ত server-এ হবে। HTTP status code outcome জানায়; JSON body তার বিস্তারিত বলে।

পরিচিত একটি উপমা

রেস্তোরাঁয় customer order slip-এ খাবারের নাম ও পরিমাণ দেন। তিনি নিজের ইচ্ছেমতো দাম লিখে bill নির্ধারণ করেন না। Cashier menu ও discount rule দেখে final bill করেন। Customer হলো client, cashier ও kitchen-এর সম্মিলিত ব্যবস্থা server-এর মতো।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

একাধিক client একই API ব্যবহার করতে পারে, কিন্তু authoritative price database থেকে আসে।
Diagram-এর text flow দেখুন
flowchart LR
 A[Browser] -->|Product ID and quantity| B[Laravel API]
 C[Mobile App] -->|Product ID and quantity| B
 B -->|Trusted price lookup| D[(Products DB)]
 B -->|JSON response| A

Client product ID পাঠায়। API input যাচাই করে। Server database থেকে বর্তমান product ও price পড়ে। Business rule অনুযায়ী response তৈরি হয়। ভুল input হলে validation error, permission না থাকলে authorization error—এই outcome-গুলো আলাদা করা উচিত।

PHP ও Laravel-এ প্রয়োগ

নিচের route একটি read-only API example। Product model-এ id, name ও price_minor আছে ধরে নেওয়া হয়েছে। Money ছোট unit-এ integer রাখা floating-point rounding এড়াতে সাহায্য করে; currency-ও বাস্তব schema-তে আলাদা রাখুন।

php
use App\Models\Product;
use Illuminate\Support\Facades\Route;

Route::get('/products/{product}', function (Product $product) {
    return response()->json([
        'id' => $product->id,
        'name' => $product->name,
        'price_minor' => $product->price_minor,
    ]);
});

সুবিধা, সীমাবদ্ধতা ও trade-off

একটি API অনেক client support করলে business logic পুনর্ব্যবহার হয়। তবে contract বদলালে পুরোনো mobile client ভাঙতে পারে। সব internal database field JSON-এ প্রকাশ না করে explicit response বা API Resource ব্যবহার করুন। Client-server separation network latency ও timeout-এর বাস্তবতাও নিয়ে আসে।

সাধারণ ভুল

  • Hidden input বা disabled button-কে security boundary মনে করা।
  • Eloquent model-এর সব field অনিচ্ছায় প্রকাশ করা।
  • Error হলেও সব response-এ 200 পাঠানো।
  • Browser ও server একই machine-এ আছে বলে network failure উপেক্ষা করা।

আরও একটু গভীরে

একটি machine-এ client ও server process দুটোই চলতে পারে; ভূমিকা দিয়ে এদের চেনা হয়। আবার Laravel service payment provider-এর কাছে HTTP request করলে সেই call-এ Laravel নিজেই client। তাই “server সবসময় শুধু response দেয়” ধারণাটি অতিরিক্ত সরলীকরণ।

মনে রাখুন

  • Client input প্রস্তাব, trusted business truth নয়।
  • API contract database schema থেকে আলাদা রাখুন।
  • এক service অন্য service-এর client হতে পারে।

নিজে চেষ্টা করুন

Product response-এ কোন field public হবে তা লিখুন। supplier_cost ও internal_notes কেন বাদ দেবেন? একটি 404 এবং একটি validation error-এর expected response design করুন।

নিজের বোঝা যাচাই করুন

1. Browser-এ price lock করলে কি নিরাপদ?

না। Request যেকোনো HTTP client দিয়ে পাঠানো যায়। Server-এ authoritative price হিসাব করতে হবে।

2. Client কি সবসময় UI?

না। CLI, worker বা অন্য backend service-ও client হতে পারে।

3. এক API কি browser ও mobile ব্যবহার করতে পারে?

হ্যাঁ। Stable contract ও উপযুক্ত authentication থাকলে একই business capability ব্যবহার করা যায়।

4. Raw model response-এর ঝুঁকি কী?

নতুন private column যোগ হলে অসাবধানতায় তা প্রকাশ হতে পারে। Explicit resource contract ঝুঁকি কমায়।

5. Server timeout হলে কাজ নিশ্চিত ব্যর্থ?

না। Response হারালেও write commit হতে পারে। Retry-safe write-এর জন্য idempotency দরকার।

আরও পড়ুন

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

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

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।