REST এর ওভারভিউ। পর্ব 1: বিশ্রাম কি?

ওহে! আজ আমরা এমন একটি বিষয় সম্পর্কে জানব যা খুবই আকর্ষণীয় এবং সবচেয়ে গুরুত্বপূর্ণভাবে, শ্রমবাজারে উচ্চ চাহিদা: REST। আমরা আমাদের REST এর ওভারভিউকে তিনটি ভাগে ভাগ করব:

1. প্রথম অংশে, আমরা REST এর ইতিহাস কভার করব এবং REST যে নীতির উপর ভিত্তি করে তা বর্ণনা করব।

2. দ্বিতীয়টিতে, আমরা বিবেচনা করব কিভাবে ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ HTTP প্রোটোকলের মাধ্যমে ঘটে।

3. তৃতীয়টিতে, আমরা একটি ছোট RESTful অ্যাপ্লিকেশন লিখব যা আমরা "পোস্টম্যান" নামক একটি প্রোগ্রাম ব্যবহার করে পরীক্ষা করব।

নিবন্ধটি নিম্নলিখিত পদগুলির সাথে পরিচিত পাঠকদের উদ্দেশ্যে করা হয়েছে:

• HTTP
• URL এবং URI
• JSON এবং (একটি কম পরিমাণে) XML
• ইনজেকশন নির্ভরতা

পার্ট 1. REST কি?

REST, আইটি জগতের মতো, একটি সংক্ষিপ্ত রূপ। এটি "রিপ্রেজেন্টেশনাল স্টেট ট্রান্সফার" থেকে উদ্ভূত হয়েছে । এটি একটি কম্পিউটার নেটওয়ার্কে বিতরণ করা সিস্টেমের উপাদানগুলির মধ্যে মিথস্ক্রিয়া করার জন্য একটি স্থাপত্য শৈলী। সহজভাবে বলতে গেলে, REST সিস্টেমের বিভিন্ন উপাদানের মধ্যে মিথস্ক্রিয়া (ডেটা বিনিময়) জন্য শৈলী নির্ধারণ করে, যার প্রতিটি শারীরিকভাবে বিভিন্ন জায়গায় অবস্থিত হতে পারে। এই স্থাপত্য শৈলীটি একটি বিতরণ করা সিস্টেম ডিজাইন করার সময় মেনে চলা সীমাবদ্ধতার একটি ধারাবাহিক সেট। এই সীমাবদ্ধতাগুলিকে কখনও কখনও REST-এর নির্দেশক নীতি বলা হয়। অনেকগুলি নেই, শুধুমাত্র 6. আমরা তাদের সম্পর্কে একটু পরে কথা বলব।

REST এর ইতিহাস

REST শব্দটি রয় ফিল্ডিং দ্বারা প্রবর্তিত হয়েছিল, HTTP প্রোটোকলের অন্যতম নির্মাতা, তার পিএইচডিতে। 2000 সালে "স্থাপত্য শৈলী এবং নেটওয়ার্ক-ভিত্তিক সফ্টওয়্যার আর্কিটেকচারের নকশা" শিরোনামের থিসিস। যদিও REST শব্দটিকে এখনও তরুণ বলা যেতে পারে, তবে এটি যে ধারণাটি উপস্থাপন করে তা ওয়ার্ল্ড ওয়াইড ওয়েবের একেবারে মূলে রয়েছে। আমরা শব্দটির ইতিহাসের গভীরে ডুব দেব না। আপনি যদি প্রাথমিক উত্সগুলিতে ডুব দিতে চান তবে ফিল্ডিংয়ের গবেষণামূলক গবেষণাটি দেখুন ।

REST সীমাবদ্ধতা এবং নীতি

উপরে উল্লিখিত হিসাবে, REST সংজ্ঞায়িত করে কিভাবে একটি বিতরণ করা সিস্টেমের উপাদানগুলি একে অপরের সাথে যোগাযোগ করা উচিত। সাধারণভাবে, এটি একটি অনুরোধ-প্রতিক্রিয়া প্রক্রিয়ার মাধ্যমে ঘটে। যে উপাদানটি অনুরোধ পাঠায় তাকে ক্লায়েন্ট বলা হয় এবং যে উপাদানটি অনুরোধটি প্রক্রিয়া করে এবং ক্লায়েন্টকে একটি প্রতিক্রিয়া পাঠায় তাকে সার্ভার বলা হয়. অনুরোধ এবং প্রতিক্রিয়া প্রায়শই HTTP প্রোটোকলের মাধ্যমে পাঠানো হয়। HTTP মানে হাইপারটেক্সট ট্রান্সফার প্রোটোকল। সাধারণত, একটি সার্ভার হল কিছু ওয়েব অ্যাপ্লিকেশন। ক্লায়েন্ট প্রায় কিছু হতে পারে. উদাহরণস্বরূপ, একটি মোবাইল অ্যাপ যা একটি সার্ভার থেকে ডেটা অনুরোধ করে। অথবা একটি ব্রাউজার যা ডেটা ডাউনলোড করার জন্য একটি ওয়েব পৃষ্ঠা থেকে সার্ভারে অনুরোধ পাঠায়। অ্যাপ্লিকেশন A অ্যাপ্লিকেশন B থেকে ডেটার জন্য অনুরোধ করতে পারে। এই ক্ষেত্রে, A হল B এর সাপেক্ষে একটি ক্লায়েন্ট, এবং B হল A এর সাপেক্ষে একটি সার্ভার। একই সময়ে, A B, C, D, ইত্যাদির অনুরোধগুলি প্রক্রিয়া করতে পারে। এই ক্ষেত্রে, অ্যাপ্লিকেশন A একটি সার্ভার এবং একটি ক্লায়েন্ট উভয়ই। সবকিছুই প্রেক্ষাপটের উপর নির্ভর করে। একটি জিনিস নিশ্চিত: যে উপাদানটি অনুরোধ পাঠায় সেটি হল ক্লায়েন্ট। যে উপাদানটি একটি অনুরোধ গ্রহণ করে, প্রক্রিয়া করে এবং প্রতিক্রিয়া জানায় সেটি হল সার্ভার। যাহোক, প্রতিটি সিস্টেম নয় যার উপাদানগুলি একটি অনুরোধ-প্রতিক্রিয়া প্রক্রিয়ার মাধ্যমে যোগাযোগ করে একটি শান্ত সিস্টেম নয়৷ একটি সিস্টেমকে আরামদায়ক হিসাবে বিবেচনা করার জন্য, এটিকে অবশ্যই ছয়টি REST সীমাবদ্ধতা মেনে চলতে হবে:

1. ক্লায়েন্ট-সার্ভার আর্কিটেকচার

এই সীমাবদ্ধতা উদ্বেগ বিচ্ছেদ সম্পর্কে. ডেটা সঞ্চয় করে এমন সার্ভারের প্রয়োজনীয়তা থেকে ক্লায়েন্ট ইন্টারফেসের প্রয়োজনীয়তাগুলি আলাদা করা প্রয়োজন। এই সীমাবদ্ধতা ক্লায়েন্ট কোডটিকে অন্যান্য প্ল্যাটফর্মের জন্য আরও বহনযোগ্য করে তোলে এবং সার্ভারের দিকটি সরল করে সিস্টেমের মাপযোগ্যতা উন্নত করে। "ক্লায়েন্ট" এবং "সার্ভার" এর মধ্যে একটি পার্থক্য তৈরি করা তাদের একে অপরের থেকে স্বাধীনভাবে বিকাশ করার অনুমতি দেয়।

2. রাষ্ট্রহীন

একটি আরামদায়ক আর্কিটেকচারের জন্য নিম্নলিখিত শর্তগুলি পূরণ করা প্রয়োজন। অনুরোধের মধ্যে সময়ের মধ্যে, সার্ভার অবশ্যই ক্লায়েন্টের অবস্থা এবং এর বিপরীতে তথ্য সঞ্চয় করবে না। ক্লায়েন্টের সমস্ত অনুরোধ অবশ্যই এমনভাবে রচনা করতে হবে যা সার্ভারকে অনুরোধটি সম্পূর্ণ করার জন্য প্রয়োজনীয় সমস্ত তথ্য দেয়। সুতরাং, সার্ভার এবং ক্লায়েন্ট উভয়ই পূর্ববর্তী বার্তাগুলির উপর নির্ভর না করে যে কোনও প্রাপ্ত বার্তা "বুঝতে" পারে৷

3. ক্যাশেযোগ্য

ক্লায়েন্ট সার্ভার প্রতিক্রিয়া ক্যাশে করতে পারেন. এইগুলি, ঘুরে, স্পষ্টভাবে বা পরোক্ষভাবে ক্যাশে বা নন-ক্যাশেড হিসাবে মনোনীত করা আবশ্যক, যাতে ক্লায়েন্টরা পরবর্তী অনুরোধের প্রতিক্রিয়াতে পুরানো বা ভুল ডেটা না পায়। সঠিক ক্যাশিং সম্পূর্ণ বা আংশিকভাবে কিছু ক্লায়েন্ট-সার্ভার মিথস্ক্রিয়া দূর করতে সাহায্য করে, সিস্টেমের কার্যক্ষমতা এবং মাপযোগ্যতা আরও বৃদ্ধি করে।

4. ইউনিফর্ম ইন্টারফেস

একটি RESTful স্থাপত্যের মৌলিক প্রয়োজনীয়তাগুলির মধ্যে একটি ইউনিফাইড, অভিন্ন ইন্টারফেস অন্তর্ভুক্ত রয়েছে। একটি অনুরোধ পাঠানোর সময় ক্লায়েন্টকে সর্বদা যে বিন্যাস এবং ঠিকানাগুলি ব্যবহার করতে হবে তা অবশ্যই বুঝতে হবে এবং সার্ভারকে অবশ্যই ক্লায়েন্টের অনুরোধের উত্তর দেওয়ার সময় এটি যে বিন্যাসটি ব্যবহার করা উচিত তাও বুঝতে হবে। এই সামঞ্জস্যপূর্ণ ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশন যা বর্ণনা করে যে কী, কোথায়, কী আকারে এবং কীভাবে ডেটা পাঠাতে হয় তা একটি ইউনিফাইড ইন্টারফেস।

5. স্তর

স্তর দ্বারা, আমরা নেটওয়ার্কের শ্রেণীবিন্যাস কাঠামো বোঝায়। কখনও কখনও একটি ক্লায়েন্ট সার্ভারের সাথে সরাসরি যোগাযোগ করতে পারে, এবং কখনও কখনও এটি শুধুমাত্র একটি মধ্যবর্তী নোডের সাথে যোগাযোগ করে। লোড ব্যালেন্সিং এবং ডিস্ট্রিবিউটেড ক্যাশিংয়ের জন্য মধ্যবর্তী সার্ভারের ব্যবহার স্কেলেবিলিটি বৃদ্ধি করতে পারে। এর একটি উদাহরণ প্রদান করা যাক. একটি মোবাইল অ্যাপ কল্পনা করুন যা সারা বিশ্বে জনপ্রিয়। অ্যাপের একটি অবিচ্ছেদ্য অংশ হল ছবি লোড করা। এর ব্যবহারকারীর সংখ্যা লক্ষ লক্ষ, তাই একটি একক সার্ভার এত ভারী লোড পরিচালনা করতে পারে না। সিস্টেমটিকে স্তরগুলিতে আলাদা করা এই সমস্যার সমাধান করবে। যদি ক্লায়েন্ট একটি মধ্যবর্তী নোড থেকে একটি ছবির অনুরোধ করে, তাহলে মধ্যবর্তী নোডটি সার্ভার থেকে ছবিটির অনুরোধ করে যা এই মুহূর্তে সবচেয়ে কম লোড হয় এবং ক্লায়েন্টকে ছবিটি ফেরত দেয়। যদি ক্যাশিং অনুক্রমের প্রতিটি স্তরে সঠিকভাবে প্রয়োগ করা হয়,

6. চাহিদা অনুযায়ী কোড (ঐচ্ছিক)

এই সীমাবদ্ধতাটি বোঝায় যে ক্লায়েন্ট অ্যাপলেট বা স্ক্রিপ্ট আকারে সার্ভার থেকে কোড ডাউনলোড করে তার কার্যকারিতা প্রসারিত করতে পারে।

আরামদায়ক আর্কিটেকচারের সুবিধা

উল্লিখিত সমস্ত সীমাবদ্ধতা মেনে চলা অ্যাপ্লিকেশনগুলির নিম্নলিখিত সুবিধা রয়েছে: নির্ভরযোগ্যতা (ক্লায়েন্টের অবস্থা সংরক্ষণ করার প্রয়োজন নেই, যা হারিয়ে যেতে পারে)

• কর্মক্ষমতা (একটি ক্যাশে ব্যবহারের কারণে)
• মাপযোগ্যতা
• স্বচ্ছ যোগাযোগ
• সহজ ইন্টারফেস
• বহনযোগ্যতা
• সহজে পরিবর্তন করার ক্ষমতা
• বিকশিত এবং নতুন প্রয়োজনীয়তার সাথে খাপ খাইয়ে নেওয়ার ক্ষমতা

REST এর ওভারভিউ। পার্ট 2: ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ REST এর ওভারভিউ। পার্ট 3: স্প্রিং বুটে একটি আরামদায়ক পরিষেবা তৈরি করা