REST এর ভূমিকা

8.1 দূরবর্তী API পদ্ধতি

ক্লায়েন্ট-সার্ভার আর্কিটেকচার তৈরি করার সময় সমস্ত প্রোগ্রামার একই ভুল করে। তারা সার্ভারে অনুরোধগুলিকে মেথড কল হিসাবে বিবেচনা করতে শুরু করে ।

আপনি সার্ভারে প্রতিবেদন তৈরির প্রক্রিয়া শুরু করতে চান, কেন এটি একটি অনুরোধ পাঠাবেন না:

http://server.com/startDocumentGeneration?params

এবং রিপোর্ট সম্পূর্ণ হওয়ার পর কিভাবে ডাউনলোড করবেন? এটি করার জন্য, আমরা অন্য পদ্ধতি লিখব:

http://server.com/getDocument

সার্ভার HttpSessionআমাদের নথিতে তথ্য সঞ্চয় করে, এবং নথিটি তৈরি হওয়ার সাথে সাথে সার্ভার তা ফেরত দেবে।

মহান পন্থা. অথবা না?

পদ্ধতি সত্যিই ভয়ানক. ব্যাপারটা হল সার্ভারকে অবশ্যই ডকুমেন্ট নম্বর মনে রাখতে হবে। অন্য কথায়, নতুন পদ্ধতির কলগুলি সঠিকভাবে প্রক্রিয়া করার জন্য, সার্ভারকে পূর্ববর্তী পদ্ধতিগুলি কল করার ফলাফলগুলি মনে রাখতে হবে।

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

সার্ভারের সাথে আরামদায়ক কাজের জন্য, আপনি আশা করতে পারেন না যে সার্ভারে আপনার কাছে সর্বদা পূর্বের অনুরোধের ডেটা থাকবে।

তাহলে কিভাবে সার্ভারের পদ্ধতি কল করবেন? সঠিক উত্তর ভয়ানক হবে: কোন উপায় নেই!

8.2 REST পদ্ধতি

প্রোগ্রামাররা বেসিকগুলিতে ফিরে গিয়েছিল এবং মনে রেখেছিল যে প্রাথমিকভাবে অনুরোধটিতে সার্ভারে ফাইলের পথ রয়েছে:

http://server.com/path?params

এবং আমরা এই পদ্ধতিটি সর্বাধিক ব্যবহার করার সিদ্ধান্ত নিয়েছি।

এখন সার্ভারটিকে ডেটার ভান্ডার হিসাবে বিবেচনা করা হয় যা একটি গাছের আকারে বাইরে থেকে দৃশ্যমান হয় ।

আপনি যদি সমস্ত ব্যবহারকারীর একটি তালিকা পেতে চান, প্রশ্নটি কল করুন:

http://server.com/users

আপনি যদি ব্যবহারকারী 113-এ ডেটা পেতে চান, প্রশ্নটি চালান:

http://server.com/users/113

এবং তাই, একই শিরা সব.

আবারও, সার্ভারটিকে ডেটার ভান্ডার হিসাবে দেখা হয় যা একটি গাছের আকারে বাইরে থেকে দৃশ্যমান হয়।

ডেটা গ্রহণ করা যেতে পারে - অনুরোধগুলি পান , সংশোধন করুন - অনুরোধ পোস্ট করুন এবং মুছে ফেলুন - অনুরোধ মুছুন ৷

8.3 রাষ্ট্র নেই

ক্লায়েন্ট এবং সার্ভারের মধ্যে ইন্টারঅ্যাকশনের REST প্রোটোকলের জন্য নিম্নলিখিত শর্ত প্রয়োজন: ক্লায়েন্টের অনুরোধগুলির মধ্যে সময়কালে, ক্লায়েন্টের অবস্থা সম্পর্কে কোনও তথ্য সার্ভারে সংরক্ষণ করা হয় না।

ক্লায়েন্টের সমস্ত অনুরোধ এমনভাবে তৈরি করা উচিত যাতে সার্ভার প্রতিবার অনুরোধটি পূরণ করার জন্য প্রয়োজনীয় সমস্ত তথ্য পায় । সেশন স্টেট ক্লায়েন্ট সাইডে সংরক্ষিত হয়।

ক্লায়েন্ট অনুরোধ প্রক্রিয়াকরণের সময়, ক্লায়েন্ট একটি ক্রান্তিকালীন অবস্থায় বিবেচিত হয়। প্রতিটি স্বতন্ত্র অ্যাপ্লিকেশন স্টেটকে লিঙ্কগুলির দ্বারা প্রতিনিধিত্ব করা হয় যা পরবর্তী সময়ে ক্লায়েন্ট হিট করার জন্য আহ্বান করা যেতে পারে।

8.4 ইন্টারফেসের অভিন্নতা

সার্ভার থেকে বস্তু পুনরুদ্ধার করতে ব্যবহৃত সমস্ত পাথ প্রমিত। এটি খুব সুবিধাজনক, বিশেষ করে যদি আপনি অন্যান্য REST সার্ভার থেকে ডেটা পান।

সমস্ত অবজেক্ট ইন্টারফেস তিনটি শর্ত মেনে চলতে হবে:

সম্পদ সনাক্তকরণ

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

একটি দৃশ্যের মাধ্যমে সম্পদ ম্যানিপুলেট করা

যদি ক্লায়েন্ট মেটাডেটা সহ সম্পদের একটি উপস্থাপনা সঞ্চয় করে, তাহলে সার্ভারে রিসোর্স পরিবর্তন বা মুছে ফেলার জন্য এটির কাছে যথেষ্ট তথ্য রয়েছে।

"স্ব-বর্ণনাকারী" বার্তা

প্রতিটি বার্তায় এটি কীভাবে পরিচালনা করা যায় তা বোঝার জন্য যথেষ্ট তথ্য রয়েছে৷ উদাহরণস্বরূপ, যদি আপনার ব্যবহারকারী সম্পর্কে তথ্যের প্রয়োজন হয়, তাহলে সার্ভার আপনাকে একটি JSON অবজেক্ট ফিরিয়ে দেবে, যেখানে নাম, ঠিকানা ক্ষেত্র থাকবে।

এমন পরিস্থিতি থাকা উচিত নয় যেখানে ক্লায়েন্টকে জানতে হবে যে প্রতিক্রিয়ার প্রথম নম্বরটি বয়স, এবং দ্বিতীয়টি হল জন্ম তারিখ।

8.5 ক্যাশিং

REST পদ্ধতি অনুমান করে যে ডেটা অনুরোধগুলি HTTP প্রোটোকলের মাধ্যমে করা হয়। অতএব, একটি GET অনুরোধ কল করে বস্তু প্রাপ্ত করা হয়. এর মানে হল যে তারা, একটি GET অনুরোধের মাধ্যমে প্রাপ্ত সমস্ত সংস্থানগুলির মতো, HTTP সংস্থান ক্যাশ করার জন্য সমস্ত নিয়মের অধীন৷

অর্থাৎ, REST API-এর মাধ্যমে প্রাপ্ত ডেটা ওয়েব সার্ভারের যেকোনো স্ট্যাটিক রিসোর্সের মতোই ক্যাশে করা হয়। সৌন্দর্য :)