API-র ধরন — REST, GraphQL, SOAP, WebSocket (সহজ ব্যাখ্যা)

🎥 উপরে পুরো ভিডিওটি দেখে নিতে পারেন — অথবা নিচে পড়ে নিন। দুটোতেই একই জিনিস সহজ করে বোঝানো হয়েছে।

REST, GraphQL, SOAP — এই শব্দগুলো শুনতে অনেকটা "alphabet soup"-এর মতো, তাই না? কিন্তু আসল কথাটা হলো: এগুলো ভয়ের কিছু নয়। এগুলো শুধু একই খাবার অর্ডার করার ভিন্ন ভিন্ন স্টাইল। আর একবার রেস্টুরেন্টের চোখে দেখলে সবকিছু পরিষ্কার হয়ে যায়।

প্রথমে একটা বিষয় পরিষ্কার করি: প্রতিটা API আসলে একই কাজ করে — আপনি একটা request পাঠান, একটা response পান (মনে আছে পর্ব ২?)। তাহলে ধরনগুলোর মধ্যে পার্থক্য কী? শুধু স্টাইল — কীভাবে অর্ডার করছেন, আর খাবারটা কীভাবে ফিরে আসছে। চারটা ধরন আপনি বাস্তবে শুনবেন।

১. REST — ফিক্সড মেনু

একটা রেস্টুরেন্ট কল্পনা করুন যেখানে একটা নির্দিষ্ট মেনু আছে। আইটেম এক, আইটেম দুই, আইটেম তিন — প্রতিটা ডিশের নিজের জায়গা, আপনি দেখিয়ে অর্ডার করেন। এটাই REST। পর্ব ৪-এর endpoint মনে আছে — /users, /products? ওগুলোই মেনু আইটেম। আপনি একটা বেছে নেন, GET বা POST-এর মতো সহজ একটা action ব্যবহার করেন, আর রান্নাঘর JSON আকারে খাবার ফেরত পাঠায়।

২. GraphQL — নিজের প্লেট নিজে সাজান

REST ভালো, কিন্তু দুটো ছোট সমস্যা আছে। কখনো একটা ডিশ চাইলে সাথে অনেক side dish-ও চলে আসে যা আপনি চাননি (over-fetching — বেশি ডেটা)। আবার কখনো এক ডিশে পেট ভরে না, তাই তিনটা আলাদা অর্ডার দিতে হয় (under-fetching — বেশি ট্রিপ)।

GraphQL দুটোই সমাধান করে। এটা অনেকটা কাউন্টারে গিয়ে বলার মতো: "আমার প্লেটে ঠিক এই, এই আর এই দাও — বেশিও না, কমও না।" আপনি ঠিক যা চান বলে দেন, এক ট্রিপেই হুবহু সেটাই পান। একটা profile স্ক্রিনে নাম, ছবি আর শেষ ৩টা পোস্ট দরকার? REST-এ হয়তো ৩টা request; GraphQL-এ একটাই — যেখানে আপনি শুধু field-গুলো (name, photo, posts) লিখে দেন, সব একসাথে আসে। তাই Facebook (যারা GraphQL বানিয়েছে) এর মতো ডেটা-ভারী অ্যাপ এটা পছন্দ করে। ট্রেড-অফ: সেট আপ করা একটু কঠিন, তাই বেশিরভাগ মানুষ REST দিয়ে শুরু করে।

৩. SOAP — পুরোনো, ফরমাল কাগজপত্র

SOAP হলো পুরোনো দিনের ফরমাল পদ্ধতি। ভাবুন একটা সরকারি ফর্ম পূরণ করছেন — কঠোর ফরম্যাট, প্রতিটা ঘর বাধ্যতামূলক, অনেক নিয়ম যা ভাঙা যায় না। এটা ভারী, শব্দবহুল, আর বন্ধুত্বপূর্ণ JSON-এর বদলে সবকিছু XML নামের কঠিন কাঠামোয় মুড়ে রাখে।

তাহলে এখনও টিকে আছে কেন? কারণ ব্যাংক, বীমা কোম্পানি আর পুরোনো বড় এন্টারপ্রাইজ সিস্টেম বছরের পর বছর SOAP-এ বানানো — আর সেগুলো খুব নিরাপদ ও স্থিতিশীল। নতুন হিসেবে আপনি নতুন প্রজেক্টে SOAP দিয়ে শুরু করবেন না, তবে কোনো বড় ব্যাংকে চাকরি করলে এটা দেখলে অবাক হবেন না।

৪. WebSocket — খোলা ফোন লাইন

এতক্ষণের সব স্টাইল একই মূলনীতিতে চলে: আপনি জিজ্ঞেস করেন, উত্তর আসে, কথা শেষ — অনেকটা চিঠি পাঠানোর মতো। কিন্তু যদি জিনিস লাইভ, ঘটার সাথে সাথে দরকার হয়? তখনই আসে WebSocket।

WebSocket চিঠির বদলে একটা ফোন কল-এর মতো। একবার লাইন খুললে সেটা খোলা থাকে; দুপক্ষই যেকোনো সময়, সাথে সাথে কথা বলতে পারে — আবার ডায়াল করতে হয় না। আপনি প্রতিদিন এটা ব্যবহার করছেন: বন্ধু মেসেজ পাঠানোর সাথে সাথে চ্যাটে পপ আপ হওয়া, লাইভ স্কোর নিজে নিজে আপডেট হওয়া, নোটিফিকেশন, একই ডকুমেন্টে দুজনের একসাথে টাইপ করা, লাইভ রাইড-ট্র্যাকিং ম্যাপ — সবই WebSocket।

কোনটা কখন ব্যবহার করবেন? (চিট-শিট)

নতুনদের ২টি ভুল ধারণা

• ❌ "GraphQL মানে REST শেষ।" না — REST এখনও সবচেয়ে বেশি ব্যবহৃত। GraphQL নির্দিষ্ট ক্ষেত্রে (ডেটা-ভারী অ্যাপ) বেশি কাজের, প্রতিস্থাপন নয়।
• ❌ "type যত নতুন, তত ভালো।" না — সঠিক type নির্ভর করে কাজের ওপর। ছোট প্রজেক্টে REST-ই যথেষ্ট।

সংক্ষেপে — আজকের মূল কথা

প্রায়ই জিজ্ঞেস করা প্রশ্ন (FAQ)

শুরুতে কোনটা শিখব?

REST। এটাই সবচেয়ে বেশি ব্যবহৃত, সহজ, আর এই কোর্সে যা শিখেছেন তার ভিত্তি। পরে দরকার হলে GraphQL ধরবেন।

REST আর REST API — আলাদা কিছু?

একই জিনিস। "REST" একটা স্টাইল/নিয়ম, আর সেই নিয়মে বানানো API-কে বলে REST API।

পরবর্তী ধাপ

এতক্ষণ অনেক কথা হলো — পরের পর্বে আমরা থামব না, হাতে-কলমে কাজ করব! আপনি নিজে একটা সত্যিকারের, লাইভ API ব্যবহার করবেন, ধাপে ধাপে, আর নিজের চোখে আসল ডেটা ফিরে আসতে দেখবেন। এটাই কোর্সের মজার পর্ব।

📧 প্রশ্ন আছে? hello@shadhinpath.com