REST (Representational State Transfer) হলো networked application-এর জন্য একটি architectural style, যা Roy Fielding সংজ্ঞায়িত করেছেন। এটি একটি protocol বা standard নয় — এটি এমন এক সেট constraint যা মেনে চললে একটি API scalable, cacheable, এবং সহজে বিকশিত হয়। একটি "RESTful" API সবকিছুকে resource (user, order, product) হিসেবে মডেল করে যা URI দিয়ে শনাক্ত হয়, এবং standard HTTP method ব্যবহার করে সেগুলো manipulate করে।
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 resource-টির নাম দেয়; GET হলো action; JSON হলো representation। সেই সমন্বয় — path-এ noun, HTTP method হিসেবে verb — হলো REST-এর হৃদয়।
REST হলো web API-র প্রভাবশালী style, তাই interviewer-রা এই প্রশ্ন ব্যবহার করেন যাচাই করতে আপনি বোঝেন কেন এটি কাজ করে, শুধু বানান করতে পারা নয়। বাস্তবে সবচেয়ে গুরুত্বপূর্ণ দুটি constraint হলো statelessness (প্রতিটি request স্ব-সম্পূর্ণ, তাই আপনি একটি load balancer-এর পেছনে যত খুশি server রাখতে এবং sticky session ছাড়াই horizontally scale করতে পারেন) এবং uniform interface (অনুমেয়, resource-oriented URL এবং standard HTTP method ও status code, যার মানে client-এর প্রতি endpoint-এ custom logic দরকার হয় না)। একটি শক্তিশালী উত্তর constraint-গুলোকে সুনির্দিষ্ট সুবিধার সাথে যোগ করে — statelessness scaling সম্ভব করে, cacheability load কমায়, layered system আপনাকে CDN আর gateway ঢোকাতে দেয় — এবং উল্লেখ করে যে বেশিরভাগ "REST" API পূর্ণ RESTful না হয়ে বরং ব্যবহারিক (খুব কমই HATEOAS বাস্তবায়ন করে)। এই constraint-গুলো বোঝা status code বেছে নেওয়া থেকে versioning পর্যন্ত অন্য প্রতিটি REST design সিদ্ধান্তের ভিত্তি।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন