API কী? REST-এর বেসিক

সমস্যাটা কী?

ধরো তুমি একটা ফুড-ডেলিভারি অ্যাপ বানাচ্ছ। তোমার অ্যাপকে bKash দিয়ে পেমেন্ট নিতে হবে। কিন্তু তুমি তো bKash-এর ভেতরের কোড জানো না, আর তোমাকে জানতেও দেবে না! তাহলে কীভাবে তোমার অ্যাপ bKash-এর সাথে কথা বলবে?

এখানেই API আসে। bKash তোমাকে একটা নির্দিষ্ট দরজা দিয়ে দেয় — "এই ঠিকানায় এই ফরম্যাটে তথ্য পাঠাও, আমি পেমেন্ট প্রসেস করে এই ফরম্যাটে উত্তর দেব।" তোমাকে ভেতরের কিছুই জানতে হয় না। এই চুক্তিটাই API। প্রায় প্রতিটা আধুনিক অ্যাপ অসংখ্য API-এর উপর দাঁড়িয়ে আছে।

মূল ধারণা

API (Application Programming Interface) হলো দুটো software-এর মধ্যে কথা বলার একটা নির্দিষ্ট চুক্তি বা ইন্টারফেস। এটা ঠিক করে দেয় — তুমি কী চাইতে পারবে, কীভাবে চাইবে, আর বিনিময়ে কী পাবে।

API ভেতরের জটিলতা লুকিয়ে রাখে আর শুধু একটা পরিষ্কার "মেনু" দেখায়। তুমি মেনু থেকে অর্ডার করো, ভেতরে কীভাবে রান্না হয় তা জানার দরকার নেই।

REST (Representational State Transfer) হলো API বানানোর সবচেয়ে জনপ্রিয় স্টাইল। এটা HTTP-এর উপর দাঁড়িয়ে — মানে web যে নিয়মে চলে, REST API-ও সেই নিয়মেই কথা বলে।

কীভাবে কাজ করে

REST-এর মূল নীতি

REST কয়েকটা সহজ নীতির উপর দাঁড়ানো:

• Resource-কেন্দ্রিক — সবকিছুকে একটা "resource" ধরা হয় (user, product, order) আর প্রতিটার একটা URL থাকে।
• Stateless — প্রতিটা request স্বয়ংসম্পূর্ণ; server আগের request মনে রাখে না।
• HTTP method দিয়ে কাজ বোঝানো — কী করতে চাও তা method-ই বলে দেয়।
• JSON-এ ডেটা — আজকাল প্রায় সব REST API ডেটা পাঠায় JSON (JavaScript Object Notation) ফরম্যাটে।

HTTP methods আর endpoint

Endpoint হলো একটা নির্দিষ্ট URL যা কোনো resource-কে নির্দেশ করে, যেমন /users/42। সেই endpoint-এ কোন method পাঠাচ্ছ তার উপর কাজ নির্ভর করে:

Method	কাজ	উদাহরণ	Idempotent?
GET	পড়া/আনা	GET /users/42	হ্যাঁ
POST	নতুন তৈরি	POST /users	না
PUT	পুরো বদলানো	PUT /users/42	হ্যাঁ
DELETE	মুছে ফেলা	DELETE /users/42	হ্যাঁ

Request ও response উদাহরণ

একটা নতুন user বানানোর request:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Rahim",
  "city": "Dhaka"
}

Server-এর response:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 42,
  "name": "Rahim",
  "city": "Dhaka"
}

লক্ষ করো: response-এর শুরুতে একটা status code (201 Created) আছে, যা বলে কাজটা সফল হয়েছে এবং নতুন resource তৈরি হয়েছে।

কৌশল — status code আর idempotency

Status code দিয়ে server এক নজরে ফলাফল জানায়:

• 2xx — সফল (200 OK, 201 Created)
• 4xx — তোমার (client-এর) ভুল (400 Bad Request, 401 Unauthorized, 404 Not Found)
• 5xx — server-এর সমস্যা (500 Internal Server Error)

Idempotency হলো একটা গুরুত্বপূর্ণ ধারণা: একই request বারবার পাঠালেও যদি ফল একই থাকে, তবে সেটা idempotent। DELETE /users/42 দশবার পাঠালেও user-টা একবারই মুছবে — তাই idempotent। কিন্তু POST /users দশবার পাঠালে দশটা user তৈরি হবে — তাই idempotent নয়। নেটওয়ার্ক fail করে retry করতে হলে এই ধারণাটা খুব কাজে লাগে।

কখন ব্যবহার করবে / করবে না

REST API ব্যবহার করো যখন তোমার সাধারণ CRUD (Create-Read-Update-Delete) দরকার, public API লাগে, বা সহজ-বোঝা একটা স্ট্যান্ডার্ড চাও। খুব জটিল, একে অপরের সাথে জড়ানো ডেটার জন্য GraphQL, বা খুব দ্রুত internal service-to-service যোগাযোগের জন্য gRPC বিবেচনা করতে পারো — কিন্তু শুরুতে REST-ই সবচেয়ে নিরাপদ পছন্দ।

বাস্তব উদাহরণ

Stripe-এর payment API দুনিয়াজুড়ে REST design-এর আদর্শ উদাহরণ হিসেবে ধরা হয়। তাদের endpoint পরিষ্কার (/charges, /customers), method যথাযথ, আর সবকিছু JSON-এ। বিশেষ করে তারা idempotency খুব গুরুত্ব দিয়ে সামলায় — তুমি একটা Idempotency-Key header পাঠাতে পারো, যাতে নেটওয়ার্ক সমস্যায় request retry করলেও কোনো গ্রাহকের কাছ থেকে দুবার টাকা না কাটে। এই ছোট ব্যাপারটাই production-grade API-কে আলাদা করে।