কীভাবে REST API বানাবেন: ডিজাইন, নিরাপত্তা ও ডেপ্লয়মেন্ট
REST API বানাতে প্রথমে আপনার অ্যাপ যেসব রিসোর্স পরিচালনা করে সেগুলোর তালিকা করুন (ব্যবহারকারী, অর্ডার, বুকিং), প্রতিটির জন্য /orders বা /orders/{id} এর মতো একটি URL ঠিক করুন, এবং কাজের জন্য HTTP মেথড ব্যবহার করুন: পড়ার জন্য GET, তৈরির জন্য POST, আপডেটের জন্য PATCH, মুছে ফেলার জন্য DELETE। অর্থবহ স্ট্যাটাস কোড সহ JSON ফেরত দিন, প্রতিটি ইনপুট ভ্যালিডেট করুন, সার্ভারে অথেন্টিকেশন ও প্রতিটি রেকর্ডের জন্য অনুমতি যাচাই বাধ্যতামূলক করুন, এবং তালিকাগুলোতে পেজিনেশন দিন। এরপর এন্ডপয়েন্টগুলো ডকুমেন্ট করুন এবং HTTPS-এর পেছনে API ডেপ্লয় করুন।
এই গাইডে নকশার সিদ্ধান্ত, কয়েকটি কাজের রুটের উদাহরণ, AI অ্যাপ বিল্ডারের জন্য প্রম্পট, এবং যেসব ভুল নিরাপত্তা ফাঁকের কারণ হয় সেগুলো আলোচনা করা হয়েছে। API নতুন হলে আগে API কী দেখে নিন।
কখন REST API লাগে
- আপনার ওয়েব ফ্রন্টএন্ডকে সার্ভারে ডেটা সংরক্ষণ ও লোড করতে হয়
- একটি মোবাইল অ্যাপ, পার্টনার বা অটোমেশন টুলের আপনার ডেটায় প্রবেশ দরকার
- অন্য সার্ভিস আপনাকে ইভেন্ট পাঠায় (ওয়েবহুক)
- আপনি ফ্রন্টএন্ড ও ব্যাকএন্ড টিমের মধ্যে কাজ ভাগ করছেন
REST সবচেয়ে প্রচলিত ধরন, তবে একমাত্ර নয়। REST বনাম GraphQL ব্যাখ্যা করে কখন একটি নমনীয় কোয়েরি এন্ডপয়েন্ট বেশি উপযুক্ত।
আগে ডিজাইন করুন: রিসোর্স ও রুট
আপনার অ্যাপের বিশেষ্যগুলো (নাম) এবং মানুষ সেগুলো দিয়ে কী করে তা লিখে ফেলুন। একটি সহজ বুকিং অ্যাপের জন্য:
| মেথড | রুট | কী করে | সফল কোড |
|---|---|---|---|
GET | /api/bookings | কলকারীর বুকিংগুলোর তালিকা (পেজিনেটেড) | 200 |
POST | /api/bookings | নতুন বুকিং তৈরি | 201 |
GET | /api/bookings/{id} | একটি বুকিং পড়া | 200 |
PATCH | /api/bookings/{id} | কিছু ফিল্ড বদলানো | 200 |
DELETE | /api/bookings/{id} | বুকিং বাতিল | 204 |
GET | /api/health | মনিটরিংয়ের জন্য হেলথ চেক | 200 |
এগুলো তৈরি, পড়া, আপডেট ও মোছা (CRUD)-এর সাথে মেলে; দেখুন CRUD কী। যেসব নিয়ম মেনে চলা ভালো:
- URL-এ বহুবচন বিশেষ্য, ক্রিয়াপদ নয়:
/bookings,/getBookingsনয়। - মালিকানা স্পষ্ট করতে শুধু একটি স্তর নেস্ট করুন:
/bookings/{id}/notes। - CRUD নয় এমন কাজ সাব-রিসোর্স হিসেবে রাখা যায়:
POST /bookings/{id}/cancelএকটি রহস্যময় PATCH-এর চেয়ে স্পষ্ট। - ফিল্ডের নামে সামঞ্জস্য, যেমন সর্বত্র
created_at।
স্ট্যাটাস কোড ও ত্রুটি
ক্লায়েন্ট যেন টেক্সট না পড়েই বুঝতে পারে কী ঘটেছে, তাই স্ট্যান্ডার্ড HTTP কোড ব্যবহার করুন:
| কোড | অর্থ | কখন ব্যবহার করবেন |
|---|---|---|
| 200 | OK | সফল পড়া বা আপডেট |
| 201 | Created | POST দিয়ে কিছু তৈরি হলে |
| 204 | No Content | সফল, কিন্তু ফেরত দেওয়ার কিছু নেই |
| 400 | Bad Request | ইনপুট ভ্যালিডেশনে ব্যর্থ |
| 401 | Unauthorized | লগইন নেই বা টোকেন ভুল |
| 403 | Forbidden | লগইন আছে, কিন্তু অনুমতি নেই |
| 404 | Not Found | নেই, বা কলকারীর জানা উচিত নয় যে এটি আছে |
| 409 | Conflict | ডুপ্লিকেট, বা স্লট আগেই বুক হয়েছে |
| 429 | Too Many Requests | রেট লিমিট ছাড়িয়েছে |
| 500 | Server Error | আপনার দিকে কিছু ভেঙেছে |
ত্রুটিগুলো একটি সঙ্গত JSON কাঠামোয় ফেরত দিন, যেমন {"error": {"code": "slot_taken", "message": "সেই সময়টি আর পাওয়া যাচ্ছে না।"}}, এবং রেসপন্সে কখনও স্ট্যাক ট্রেস বা ডেটাবেস ত্রুটি রাখবেন না।
বিকল্প ও ট্রেড-অফ
| সিদ্ধান্ত | সহজ পছন্দ | বিকল্প |
|---|---|---|
| API কোথায় থাকবে | আপনার ওয়েব ফ্রেমওয়ার্কের API রুট | আলাদা API সার্ভিস, একাধিক ক্লায়েন্ট বা ভিন্ন ভাষার জন্য উপযোগী |
| অথেন্টিকেশন | আপনার নিজের ওয়েব অ্যাপের জন্য সেশন কুকি | মোবাইল অ্যাপ ও তৃতীয় পক্ষের জন্য টোকেন (বেয়ারার টোকেন বা API key) |
| পেজিনেশন | ?page=2&limit=20 | কার্সর-ভিত্তিক (?after=...), বড় ও বদলাতে থাকা তালিকার জন্য বেশি স্থিতিশীল |
| ভার্সনিং | বাইরের ব্যবহারকারী না হওয়া পর্যন্ত কিছু নয় | অন্যরা নির্ভর করলে পাথে /v1/ |
| ডকুমেন্টেশন | রুট তালিকাসহ একটি README | OpenAPI স্পেক, যা থেকে টুল ইন্টারঅ্যাক্টিভ ডকস ও ক্লায়েন্ট কোড বানাতে পারে |
ধাপে ধাপে
- উপরের মতো রিসোর্স ও রুটের তালিকা করুন, কে কোনটিতে প্রবেশ করতে পারবে তাসহ।
- আপনার ডেটাবেসে প্রয়োজনীয় ফিল্ড ও সম্পর্ক দিয়ে ডেটা মডেল করুন।
- আগে পড়ার রুট বানান, তারপর তৈরি, আপডেট ও মোছা।
- প্রতিটি লেখার কাজে একটি স্কিমা লাইব্রেরি দিয়ে ইনপুট ভ্যালিডেট করুন: আবশ্যক ফিল্ড, টাইপ, দৈর্ঘ্য, অনুমোদিত মান। অজানা ফিল্ড প্রত্যাখ্যান করুন।
- অথেন্টিকেশন যোগ করুন, এরপর প্রতি রেকর্ডে অনুমতি যাচাই:
/bookings/42খুললে দেখতে হবে বুকিং 42 কলকারীর কিনা, শুধু কেউ লগইন করা আছে কিনা নয়। - প্রতিটি তালিকায় পেজিনেশন দিন এবং পেজের আকারের সীমা ঠিক করুন।
- লগইন ও ব্যয়বহুল রুটে রেট লিমিট দিন। দেখুন রেট লিমিটিং।
- CORS শুধু তখনই কনফিগার করুন যখন অন্য ডোমেনের ব্রাউজার API-কে ডাকবে, এবং সেই অরিজিনগুলো স্পষ্টভাবে তালিকাভুক্ত করুন। CORS ত্রুটি সমাধান দেখাবে আপনি কী ত্রুটি দেখতে পাবেন।
- প্রতিটি রুটের জন্য ডকস ও টেস্ট লিখুন, ব্যর্থতার ক্ষেত্রগুলোসহ।
- ডেপ্লয় করুন, সিক্রেট পরিবেশ ভ্যারিয়েবলে, HTTPS, লগ ও একটি হেলথ চেকসহ।
AI বিল্ডারকে দেওয়ার প্রম্পট
স্ক্যাফোল্ড:
বুকিংয়ের জন্য একটি REST API বানাও, এই রুটগুলোসহ: GET /api/health, GET /api/bookings (পেজিনেটেড, প্রতি পেজে সর্বোচ্চ 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id। ডেটা আমাদের ডেটাবেসে রাখো। রিকোয়েস্ট বডি একটি স্কিমা লাইব্রেরি দিয়ে ভ্যালিডেট করো এবং অজানা ফিল্ড প্রত্যাখ্যান করো। ত্রুটি {"error": {"code", "message"}} আকারে JSON-এ সঠিক স্ট্যাটাস কোডসহ ফেরত দাও (400, 401, 403, 404, 409)। সিক্রেট পরিবেশ ভ্যারিয়েবলে রাখো।
নিরাপত্তা:
প্রতিটি বুকিং রুটে লগইন বাধ্যতামূলক করো। প্রতিটি পড়া, আপডেট ও মোছার সময় সার্ভারে যাচাই করো যে বুকিংটি বর্তমান ব্যবহারকারীর; না হলে 404 ফেরত দাও। রিকোয়েস্ট বডি থেকে কখনও ব্যবহারকারী ID বা রোল গ্রহণ করো না। POST /api/bookings প্রতি ব্যবহারকারী প্রতি মিনিটে 20-এ সীমিত করো। সার্ভারে ত্রুটি লগ করো, কিন্তু স্ট্যাক ট্রেস ফেরত দিও না।
ডকস:
এই রুটগুলোর একটি OpenAPI বর্ণনা এবং প্রতিটি রুটের উদাহরণ অনুরোধ ও রেসপন্সসহ একটি ছোট README লেখো।
আপনার API টেস্ট করা
ফ্রন্টএন্ডের বাইরে থেকে টেস্ট করুন, কারণ আক্রমণকারীরাও তাই করবে:
- প্রতিটি রুট সঠিক ইনপুটে কাজ করে এবং ডকুমেন্টেড আকৃতি ও কোড ফেরত দেয়
- আবশ্যক বা ভুল ফিল্ডে স্পষ্ট বার্তাসহ 400 আসে
- প্রতিটি সুরক্ষিত রুটে টোকেন না থাকলে 401 আসে
- ব্যবহারকারী A, ID দিয়ে ব্যবহারকারী B-র রেকর্ড চাইলে 404 বা 403 আসে
- তালিকাগুলো পেজিনেটেড, এবং বড়
limitসীমিত হয় - ডুপ্লিকেট বা বিরোধপূর্ণ তৈরিতে 500 নয়, 409 আসে
- রেট লিমিট ছাড়ালে 429 আসে
- ত্রুটির রেসপন্সে স্ট্যাক ট্রেস, SQL বা সিক্রেট নেই
- CORS শুধু আপনার উদ্দেশ্যমূলক অরিজিনগুলোকে অনুমতি দেয়
সাধারণ ভুল
- লগইন যাচাই করা, কিন্তু মালিকানা নয়। API-র সবচেয়ে সাধারণ ফাঁক: যেকোনো লগইন করা ব্যবহারকারী ID বদলে যেকোনো রেকর্ড পড়তে পারে।
- ক্লায়েন্টকে বিশ্বাস করা। রিকোয়েস্ট বডির দাম, রোল বা ব্যবহারকারী ID বদলানো যায়।
- পুরো ডেটাবেস সারি ফেরত দেওয়া। পাসওয়ার্ড হ্যাশ ও ভেতরের ফিল্ড ফাঁস হয়ে যায়। প্রতিটি রেসপন্সে কী যাবে তা বেছে নিন।
- সীমাহীন তালিকা। প্রতিটি রেকর্ডের জন্য একটি অনুরোধ পুরো অ্যাপকে ধীর করে দিতে পারে।
200 OKদিয়ে ভেতরে ত্রুটি বার্তা। ক্লায়েন্ট ও মনিটরিং বুঝতে পারে না যে কাজটি ব্যর্থ হয়েছে।- সব origin-কে অনুমতি দেওয়া CORS, যখন API কুকি ব্যবহার করে।
- কোনো হেলথ চেক বা লগ নেই, তাই ব্যবহারকারীদের কাছ থেকে জানতে হয় যে সার্ভিস বন্ধ।
লঞ্চের আগে বিস্তৃত পর্যালোচনার জন্য দেখুন AI দিয়ে বানানো অ্যাপের নিরাপত্তা চেকলিস্ট।
Mythex-এ REST API বানানো
আপনার অ্যাপের অংশ হিসেবে, অথবা আলাদা সার্ভিস হিসেবে Mythex-এর কাছে একটি API চাইতে পারেন। ডক্সের REST API ব্যাকএন্ড রেসিপিতে একটি স্টার্টার প্রম্পট আছে: আপনার ফ্রেমওয়ার্ক ও রুট নাম দিন, স্পষ্ট JSON ত্রুটি চান, সিক্রেট পরিবেশ ভ্যারিয়েবলে রাখুন, এবং একটি Dockerfile অন্তর্ভুক্ত করুন। Node, Python, C#, Java ও অন্যান্য ভাষার কন্টেইনার ব্যাকএন্ড একটি Dockerfile দিয়ে প্রকাশ হয়, এবং Mythex Publish থেকে ডেপ্লয় সামলায় (API ব্যাকএন্ড)। একটি প্রজেক্ট পাশাপাশি ওয়েবসাইট ও API সার্ভার চালাতে পারে, এবং প্রিভিউতে আপনি দুটির মধ্যে বদলাতে পারেন। সিক্রেটগুলো প্রজেক্ট সিক্রেট হিসেবে রাখুন, এবং API-র ডেটাবেস লাগলে চ্যাটে চাইবেন। API-র আশেপাশে নির্ধারিত কাজের জন্য দেখুন ব্যাকগ্রাউন্ড জব চালানোর নিয়ম।
প্রশ্নোত্তর
REST API কী?
REST API হলো HTTP-এর মাধ্যমে প্রোগ্রামগুলো আপনার অ্যাপের ডেটার সাথে কাজ করার একটি উপায়। প্রতিটি ধরনের ডেটা একটি রিসোর্স, যার নিজস্ব URL থাকে, যেমন /orders। এর ওপর স্ট্যান্ডার্ড মেথড কাজ করে: পড়ার জন্য GET, তৈরির জন্য POST, আপডেটের জন্য PATCH বা PUT, এবং মুছে ফেলার জন্য DELETE। ডেটা সাধারণত JSON আকারে পাঠানো হয়।
REST API কোন ভাষায় বানাব?
যে ভাষায় আপনি বা আপনার টিম সহজে রক্ষণাবেক্ষণ করতে পারেন, সেটিই ব্যবহার করুন। Express বা Fastify সহ Node.js, FastAPI সহ Python, এবং C# বা Java-র ফ্রেমওয়ার্ক সবই ভালো কাজ করে। রুট, স্ট্যাটাস কোড, ভ্যালিডেশন ও অথেন্টিকেশনের নিয়মগুলো ভাষার চেয়ে বেশি গুরুত্বপূর্ণ।
REST API কীভাবে নিরাপদ রাখব?
প্রতিটি পাবলিক নয় এমন রুটে লগইন বাধ্যতামূলক করুন, সার্ভারে যাচাই করুন যে কলকারী নির্দিষ্ট প্রতিটি রেকর্ড দেখার অধিকারী কিনা, সব ইনপুট ভ্যালিডেট করুন, HTTPS ব্যবহার করুন, অনুরোধের সংখ্যা সীমিত করুন এবং সিক্রেট পরিবেশ ভ্যারিয়েবলে রাখুন। ক্লায়েন্ট থেকে পাঠানো ID বা রোলকে কখনও বিশ্বাস করবেন না।
REST API-র জন্য কি আলাদা ব্যাকএন্ড লাগবে?
সবসময় লাগে না। Next.js-এর মতো ফ্রেমওয়ার্ক পেজের পাশাপাশি API রুটও সার্ভ করতে পারে। একাধিক ক্লায়েন্ট (ওয়েব, মোবাইল, পার্টনার) একই API ব্যবহার করলে, অথবা এর নিজস্ব ভাষা বা স্কেলিং দরকার হলে আলাদা API সার্ভিস তৈরি করা যুক্তিসংগত।