যদি আরইএসটি অ্যাপ্লিকেশনগুলি রাষ্ট্রহীন বলে মনে করা হয়, আপনি সেশনগুলি কীভাবে পরিচালনা করবেন?


536

আমি কিছু স্পষ্টতার প্রয়োজন। আমি REST সম্পর্কে পড়ছি, এবং RESTful অ্যাপ্লিকেশন তৈরি করছি। উইকিপিডিয়া অনুসারে, আরআরইএসটি নিজেকে প্রতিনিধিত্বমূলক রাজ্য স্থানান্তর হিসাবে সংজ্ঞায়িত করা হয়েছে । অতএব আমি এই সমস্ত রাষ্ট্রবিহীন গাব্বলডিয়ুককে বুঝতে পারি না যে প্রত্যেকে বানান চালিয়ে যায়।

উইকিপিডিয়া থেকে:

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

তারা কি কেবল সেশন / অ্যাপ্লিকেশন স্তরের ডেটা স্টোর ব্যবহার করবেন না বলে ???

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

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

আমি যখনই নতুন বার্তার তালিকার অনুরোধ করব তখনই কি আমাকে বার্তা প্রেরকদের পুরো তালিকাটি ব্লক করতে সত্যিই পাঠাতে হবে? আমার কাছে প্রেরিত বার্তা তালিকাগুলি প্রথমে সর্বজনীনভাবে উপলভ্য সংস্থান হবে না / হবে না ..

আবার, কেবল এটি বোঝার চেষ্টা করছি। কেউ দয়া করে পরিষ্কার করুন।


হালনাগাদ:

আমি একটি স্ট্যাক ওভারফ্লো প্রশ্ন পেয়েছি যার একটি উত্তর রয়েছে যা আমাকে পুরোপুরি পুরোপুরি পায় না: আরইএসটি-র মধ্যে কীভাবে রাজ্য পরিচালনা করবেন যা বলে যে ক্লায়েন্টের রাজ্যটি গুরুত্বপূর্ণ তা সমস্ত অনুরোধে স্থানান্তরিত করা উচিত .... ইউজিজি .. অনেকটা ওভারহেডের মতো মনে হচ্ছে ... এটা কি ঠিক ??


2
@ এসলট: আমি মনে করি এটি ইচ্ছাকৃতভাবে বিভ্রান্তিকর নয়। আমার মনে হয় বিভ্রান্তিকর পরিভাষার কারণে এটি একটি ভুল বোঝাবুঝি।
আমার সঠিক মতামতটি ২

2
@ জাস্ট আমার সঠিক মতামত: আকর্ষণীয় অনুমান। আমি নিজেও এ জাতীয় কথা বিশ্বাস করতে পারি না, যেহেতু "স্টেটলেস" এর থেকে স্পষ্ট বোঝা যাচ্ছে যে আরইএসটি প্রোটোকল নিজেই রাষ্ট্রহীন; যা অন্তর্নিহিত অ্যাপ্লিকেশনের স্থিতি সম্পর্কে এবং PUT, পোস্ট এবং অনুরোধগুলি মুছে ফেলার সাথে কিছুই আপডেট করে না।
এসলট

@ এস.লট: এইচটিটিপি প্রোটোকল নিজেই রাষ্ট্রহীন। আমরা নীচে যা আলোচনা করেছি সেগুলি থেকে, আরআরএসটি হ'ল ওয়েবসভার হ্যান্ডেল সেশন স্টেট না থাকাকালীন আপনার অ্যাপটি কীভাবে তৈরি করবেন তার একটি দৃষ্টিভঙ্গি (ডিবির মতো জিনিসগুলিতে অন্যান্য ধরণের রাষ্ট্রের বিপরীতে)। এমনকি REST কে একটি প্রোটোকল বলে ভাবিনি , বরং HTTP প্রোটোকল কীভাবে ব্যবহার করবেন সে সম্পর্কে একটি দৃষ্টিভঙ্গি। আমি ভেবেছিলাম আপনি ছেলেরা এটিকে পরিষ্কার করে দিয়েছেন যে ক্লায়েন্টের সাইড স্টোরের মাধ্যমে সমস্ত ক্লায়েন্টের নির্দিষ্ট সেশন ডেটা সংরক্ষণ করে এবং ইউআরআই অ্যাক্সেসগুলি যথাসম্ভব আদর্শবান হিসাবে তৈরি করা উচিত যেখানে সেগুলি হওয়া উচিত নয় it হতে পারে না ... :(
জাক

1
"হতে পারে না .." তার মানে কী? আপনার কি নতুন প্রশ্ন আছে? এটির জন্য নির্দ্বিধায় অনুসন্ধান করুন। যদি এটি এখানে উপস্থিত না থাকে, তবে এটি জিজ্ঞাসা করুন।
এসলট

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

উত্তর:


339

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

রাষ্ট্র দুটি ধরণের আছে। অ্যাপ্লিকেশন স্টেট যা ক্লায়েন্ট এবং রিসোর্স স্টেটে থাকে যা সার্ভারে থাকে।

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

রিসোর্স স্টেট প্রতিটি ক্লায়েন্টের জন্য একরকম এবং এর যথাযথ স্থানটি সার্ভারে রয়েছে। আপনি যখন কোনও সার্ভারে ছবি আপলোড করেন আপনি একটি নতুন সংস্থান তৈরি করেন: নতুন ছবিটির নিজস্ব ইউআরআই রয়েছে এবং ভবিষ্যতের অনুরোধগুলির লক্ষ্য হতে পারে। আপনি এইচটিটিপি-র মাধ্যমে এই উত্সটি আনতে, সংশোধন করতে এবং মুছতে পারেন।

আশা করি এর দ্বারা রাষ্ট্রহীনতা এবং বিভিন্ন রাজ্য কী বোঝায় তা পার্থক্য করতে সহায়তা করে।


4
এর অর্থ কি এই যে প্রতিবার কোনও অনুরোধ ক্লায়েন্টকে প্রেরণ করা উচিত তার ব্যবহারকারীর / পাসওয়ার্ডটি প্রমাণীকরণের জন্য পাঠানো উচিত? কারণ আমি অনুমান করি যে একটি সেশনটি সংরক্ষণ করা হয়েছে, এমনকি যদি এটি সমস্ত সার্ভারের মধ্যে ভাগ করে নেওয়া নং-এসকিএল ডিবিতে থাকে, তা রাষ্ট্রহীন নয়, নাকি?
কার্লোস নাভরো অস্টিয়াসারন

1
@ কার্লোসনাভারো অস্টিয়াসারনে স্টেটলেস প্রমাণীকরণ পরিচালনা করার জন্য বিভিন্ন কৌশল রয়েছে। গুগল JWT উদাহরণস্বরূপ।
জিওএইডসিক

1
@ জিওয়েডেসিক: "যেহেতু জেএসএন ওয়েব টোকেন রাষ্ট্রহীন, তাই সার্ভারের স্টেট সংরক্ষণ না করে এগুলিকে অকার্যকর করার কোনও উপায় নেই, এভাবে স্টেটলেস টোকেনের সুবিধাটিকে পরাস্ত করে" " উইকিপিডিয়া
ulatekh

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

@ অ্যান্ড্রুটিফিনেল: আপনাকে যদি সার্ভারে অনুমোদিত আইডি সংরক্ষণ করতে হয়, তবে এটি সমস্ত সম্ভাব্য সার্ভারগুলিতে সংরক্ষণ করতে হবে যা REST লগইনকে প্রক্রিয়া করতে পারে, এটি একটি বিশাল পরিমাণে সমান্তরাল ওয়েব-সার্ভার আর্কিটেকচার জুড়ে অনেকগুলি সার্ভারের রাজ্যকে জড়িত করতে পারে।
উলাতেখ

491

মৌলিক ব্যাখ্যা হ'ল:

সার্ভারে কোনও ক্লায়েন্ট সেশন স্টেট নেই।

রাষ্ট্রবিহীনভাবে এর অর্থ সার্ভারটি ক্লায়েন্ট সেশন সম্পর্কে সার্ভারের পাশে কোনও রাজ্য সঞ্চয় করে না ।

ক্লায়েন্ট অধিবেশন ক্লায়েন্ট মধ্যে সংরক্ষিত হয়। সার্ভারটি রাষ্ট্রবিহীন মানে প্রতিটি সার্ভার যে কোনও সময় যে কোনও ক্লায়েন্টকে সেবা দিতে পারে, কোনও সেশন অ্যাফিনিটি বা স্টিকি সেশন নেই । সম্পর্কিত সেশন সম্পর্কিত তথ্য ক্লায়েন্টে সঞ্চয় করা হয় এবং প্রয়োজনীয় হিসাবে সার্ভারে দেওয়া হয় passed

এটি কেবলমাত্র ক্লায়েন্টের বর্তমান অ্যাপ্লিকেশন / সেশনের স্থিতি সম্পর্কে নয়, শপিং কার্টের মতো ব্যবসায়িক বিষয়গুলি সম্পর্কে রাষ্ট্র বজায় রাখা থেকে ওয়েব সার্ভারের সাথে কথিত অন্যান্য পরিষেবাগুলিকে আটকায় না।

ক্লায়েন্টের আবেদন রাষ্ট্র সার্ভারে কখনোই সংরক্ষণ করা উচিত, কিন্তু থেকে প্রায় পাস ক্লায়েন্ট প্রত্যেক জায়গা দরকার যে।

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

সমস্ত ক্লায়েন্ট জুড়ে সেশন ম্যানেজমেন্টের ভার লোড করা হয়, ক্লায়েন্টরা তাদের সেশন স্টেটটি সংরক্ষণ করে এবং সার্ভাররা স্টেটহীন ফ্যাশনে বহু পরিমাণ বা আরও বেশি ক্লায়েন্টের অর্ডার সরবরাহ করতে পারে।

এমনকি এমন একটি পরিষেবার জন্য যা আপনি মনে করেন যে কেবলমাত্র হাজারের সহস্রাধিক ব্যবহারকারীর 10 এর দশকে আপনার প্রয়োজন হবে , তবুও আপনার পরিষেবাটি রাষ্ট্রহীন করা উচিত। হাজার হাজার হাজার এখনও কয়েক হাজার হাজার এবং এর সাথে সময় এবং স্থান ব্যয় যুক্ত হবে associated

স্টেটলেস হ'ল এইচটিটিপি প্রোটোকল এবং সাধারণভাবে ওয়েবটি কীভাবে পরিচালনার জন্য ডিজাইন করা হয়েছিল এবং এটি সামগ্রিক সরল বাস্তবায়ন এবং সেশন স্থিতির একগুচ্ছ বজায় রাখতে আপনার একক সার্ভার সাইড লজিকের পরিবর্তে একক কোডের পথ রয়েছে।

কিছু খুব প্রাথমিক বাস্তবায়ন নীতি আছে:

এগুলি নীতিগুলি বাস্তবায়ন নয়, আপনি কীভাবে এই নীতিগুলি পূরণ করেন তা ভিন্ন হতে পারে।

সংক্ষেপে, পাঁচটি মূল নীতি হ'ল:

  1. প্রতিটি "জিনিস" একটি আইডি দিন
  2. জিনিসগুলিকে একসাথে লিঙ্ক করুন
  3. স্ট্যান্ডার্ড পদ্ধতি ব্যবহার করুন
  4. একাধিক উপস্থাপনা সহ সম্পদ
  5. রাষ্ট্রহীনভাবে যোগাযোগ করুন

আরআরটি গবেষণামূলক প্রবন্ধে প্রমাণীকরণ বা অনুমোদনের বিষয়ে কিছুই নেই ।

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

আপনার নির্দিষ্ট প্রয়োজনীয়তার জন্য কীভাবে একটি রাজ্যবিহীন অ্যাপ্লিকেশন তৈরি করবেন তা ব্যাখ্যা করা, স্ট্যাকওভারফ্লোয়ের পক্ষে খুব বিস্তৃত

অনুমোদনের অনুমোদন এবং অনুমোদনের বাস্তবায়ন যেমন এটি আরআরএসটির সাথে সম্পর্কিত তাই আরও বেশি বিস্তৃত এবং বাস্তবায়নের ক্ষেত্রে বিভিন্ন পদ্ধতির সাধারণভাবে ইন্টারনেটে খুব বিস্তারিতভাবে ব্যাখ্যা করা হয়।

এই বিষয়ে সহায়তা / তথ্যের জন্য জিজ্ঞাসা করা মন্তব্যগুলি কেবল দীর্ঘায়িত নয় হিসাবে পতাকাঙ্কিত করা উচিত


22
এটি একটি দুর্দান্ত সাহসী বক্তব্যের মতো মনে হচ্ছে এটি কয়েক মিলিয়ন ব্যবহারকারীর কাছে স্কেল করার একমাত্র উপায় । কেন সার্ভার সাইড সেশনগুলি কেবল অন্য পরিষেবা হতে পারে না?
জাক

27
@ জাক: কারণ মিলিয়ন মিলিয়ন মিলিয়ন সেশন। মুল বক্তব্যটি হ'ল এই সমস্ত সেশন ম্যানেজমেন্টের ওভারহেড এড়ানো।
এসলট

91
এটি সাহসের মতো নয় এটি অভিজ্ঞতা

21
আমার উত্তরের কোনও কিছুই প্রতিটি অনুরোধে ডাটাবেস অ্যাক্সেসের উপর ভিত্তি করে কোনও সমাধান বোঝায় না, যদি আপনি মনে করেন এটি করে, এটি আপনার পক্ষে সেই স্কেলটিতে প্রমাণীকরণ এবং অনুমোদন বুঝতে ব্যর্থ। এই প্রমাণীকরণটি রাজ্যে অন্তর্ভুক্ত থাকতে পারে, আপনি কি মনে করেন যে ফেসবুক তার REST এপিআইয়ের প্রতিটি অনুরোধে একটি "ডাটাবেস অ্যাক্সেস" করে? গুগল নাকি এই বিষয়ে? ইঙ্গিত: না

6
সুতরাং, যদি আমি ব্যবহারকারীর রাজ্যকে বিতরণকৃত ক্যাশে মেমক্যাচ বলে রাখি, এবং আমার সমস্ত ওয়েব সার্ভারে এখন কোনও রাজ্য সংরক্ষণ করার দরকার নেই তবে গিয়ে মেমক্যাচ থেকে রাজ্য অর্জন করতে পারি, আমি কি এই আবেদনকে রাষ্ট্রহীন বিবেচনা করতে পারি?
জেসকি

76

তারা কি কেবল সেশন / অ্যাপ্লিকেশন স্তরের ডেটা স্টোর ব্যবহার করবেন না বলে ???

না তারা তুচ্ছভাবে বলছেন না।

তারা বলছেন যে "সেশন" সংজ্ঞায়িত করবেন না। লগইন করবেন না। লগআউট করবেন না। অনুরোধের সাথে শংসাপত্র সরবরাহ করুন। প্রতিটি অনুরোধ একা দাঁড়িয়ে।

আপনার কাছে এখনও ডেটা স্টোর রয়েছে। আপনার কাছে এখনও প্রমাণীকরণ এবং অনুমোদন রয়েছে। আপনি সেশন স্থাপন এবং সেশনের স্থিতি বজায় রাখতে সময় নষ্ট করবেন না।

মুল বক্তব্যটি হ'ল প্রতিটি অনুরোধ (ক) সম্পূর্ণ একা দাঁড়িয়ে আছে এবং (খ) কোনও আসল কাজ ছাড়াই তুচ্ছভাবে একটি দৈত্য সমান্তরাল সার্ভার ফার্মে আনা যায়। অ্যাপাচি বা স্কুইড অন্ধভাবে এবং সফলতার সাথে RESTful অনুরোধগুলি পাস করতে পারে।

আমার কী বার্তাগুলির একটি সারি থাকে এবং আমার ব্যবহারকারী বার্তাগুলি পড়তে চেয়েছিলেন তবে তিনি সেগুলি পড়ার সাথে সাথে তাঁর সেশনের সময়কালের জন্য নির্দিষ্ট কিছু প্রেরক বার্তাগুলি ব্লক করতে চেয়েছিলেন?

যদি ব্যবহারকারী কোনও ফিল্টার চায় তবে প্রতিটি অনুরোধে কেবল ফিল্টার সরবরাহ করুন।

সার্ভারের কেবল এমন বার্তাগুলি (বা মেসেজ আইডির) পাঠানো উচিত যা ব্যবহারকারীর দ্বারা অবরুদ্ধ ছিল না?

হ্যাঁ. RESTful URI অনুরোধে ফিল্টার সরবরাহ করুন

আমি যখনই নতুন বার্তার তালিকার অনুরোধ করব তখনই কি আমাকে বার্তা প্রেরকদের পুরো তালিকাটি ব্লক করতে সত্যিই পাঠাতে হবে?

হ্যাঁ. এই "ব্লক করতে বার্তা প্রেরকদের তালিকা" কত বড় হতে পারে? পিকে এর একটি সংক্ষিপ্ত তালিকা?

একটি জিইটি অনুরোধ খুব বড় হতে পারে। যদি প্রয়োজন হয় তবে আপনি পোষ্ট অনুরোধটি চেষ্টা করে দেখতে পারেন যদিও এটি এক ধরণের কোয়েরির মতো মনে হয়।


28
"লগইন করবেন না log লগআউট করবেন না the অনুরোধের সাথে শংসাপত্র সরবরাহ করুন" " আমি কখন / কীভাবে ক্লায়েন্টের কাছে এই শংসাপত্রগুলি সংরক্ষণ করতে হবে সে সম্পর্কে কোনও বিবরণ ছাড়াই কোনও REST এপিআইতে কীভাবে স্টেটলেস থাকতে হবে সে সম্পর্কে প্রশ্নের মধ্যে আমি সর্বদা এর মতো প্রতিক্রিয়াগুলি দেখি। অবশ্যই আমাদের স্থানীয় স্টোরেজে ব্যবহারকারীর নাম এবং পাসওয়ার্ড সংরক্ষণ করা উচিত নয়!
বেনিরোজ

2
@ বেনিরোজ আমরা কী লোকাল স্টোরেজে একটি টোকেন সংরক্ষণ করতে পারি না এবং অনুরোধে সেই টোকেনটি ব্যবহার করতে পারি না যা ব্যবহারকারীকে অনন্যভাবে সনাক্ত করতে পারে?
নিখিল সাহু

1
আমি যা বুঝি তার থেকে লোকালস্টোরেজে প্রচুর সুরক্ষা উদ্বেগ রয়েছে। তবে ক্লায়েন্টের সাইড সেশনগুলির সাথে অন্যান্য উদ্বেগগুলির একটি গোছা রয়েছে, যেমন
টোকেনকে

3
আপনি JWT ব্যবহার করেন যার স্বাক্ষর রয়েছে, স্বাক্ষর যাচাই দ্রুত হয় তাই আপনি সেই রাজ্যের মেয়াদ পরীক্ষা করতে পারেন।
আর্কিমিডিজ ট্রাজানো

36

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

কোনও নির্দিষ্ট ক্লায়েন্টের মিথস্ক্রিয়া সম্পর্কিত কিছু তথ্য পরিচালনা করার জন্য আপনি সার্ভারের উপর একটি সামান্য দায়িত্ব চাপার সাথে সাথেই সেই ভারটি সার্ভারটি গ্রাস করতে দ্রুত বাড়তে পারে।

এটি একটি বাণিজ্য বন্ধ।


32

ব্যবহারকারীর অ্যাপ্লিকেশন রাষ্ট্র পরিচালনার viewতিহাসিক দৃষ্টিভঙ্গি

প্রচলিত অর্থে সেশনগুলি ব্যবহারকারীর অবস্থা সার্ভারের ভিতরে থাকা অ্যাপ্লিকেশনটিতে রাখে। এটি কোনও প্রবাহের বর্তমান পৃষ্ঠা বা যা পূর্বে সন্নিবেশিত হয়েছে তবে মূল ডাটাবেসে এখনও অবিরত নেই।

এই প্রয়োজনের কারণ হ'ল ক্লায়েন্টের সুনির্দিষ্ট (যেমন ব্রাউজার নির্দিষ্ট) অ্যাপ্লিকেশন বা প্লাগ-ইন না করে কার্যকরভাবে রাষ্ট্র বজায় রাখতে ক্লায়েন্টের পক্ষে মানগুলির অভাব।

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

আরইএসটি পরিষেবাদির সাধারণ ব্যবহার

আরআরইএসটি পরিষেবাগুলি সাধারণত বলা হয় যখন কোনও লেনদেন হয় যা সম্পাদন করা প্রয়োজন হয় বা যদি এটি পুনরুদ্ধার করার প্রয়োজন হয়।

আরআরএসটি পরিষেবাদিগুলি ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন দ্বারা ডাকা হয় এবং শেষ ব্যবহারকারী সরাসরি হয় না।

প্রমাণীকরণ

সার্ভারে কোনও অনুরোধের জন্য, অনুরোধের অংশে অনুমোদনের টোকেন থাকা উচিত। এটি কীভাবে প্রয়োগ করা হয় তা অ্যাপ্লিকেশন নির্দিষ্ট, তবে সাধারণভাবে হয় প্রমাণীকরণের একটি BASICবা CERTIFICATEরূপ।

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

এই উদাহরণগুলি অনুসারে, প্রমাণীকরণটি ক্লায়েন্টের পক্ষ থেকে পরিচালিত হয় (যদিও সাইটমাইন্ডার বা গুগল তাদের শেষের দিকে প্রমাণীকরণ সেশনটি সংরক্ষণ করে), সেই অবস্থা সম্পর্কে কিছুই করা যায় না, তবে এটি আরএসটি পরিষেবা অ্যাপ্লিকেশনটির অংশ নয়।

পুনরুদ্ধার অনুরোধ

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

লেনদেন স্ক্রিপ্ট

উপরে উল্লিখিত হিসাবে, ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন নিজেই আরআরটি পরিষেবাদিগুলির সাথে এটি প্রমাণীকরণের সাথে সাথে এটি ক্লায়েন্টের পক্ষেও পরিচালনা করে calls

আরআরএসটি পরিষেবাদির জন্য এর অর্থ [সঠিকভাবে করা থাকলে] হ'ল একটি সার্ভারের কাছে একক অনুরোধ নেওয়া হ'ল একক ব্যবহারকারীর ক্রিয়াকলাপের জন্য প্রয়োজনীয় সমস্ত কিছু যা একটি একক লেনদেনের জন্য প্রয়োজনীয় সমস্ত কিছু করে থাকে, একটি লেনদেন স্ক্রিপ্ট হ'ল প্যাটার্নটি বলা হয়.

এটি POSTসাধারণত একটি অনুরোধের মাধ্যমে করা হয় , তবে অন্য যেমন PUTব্যবহার করা যেতে পারে।

আরইএসটি-র অনেকগুলি সংঘবদ্ধ উদাহরণ (আমি নিজে এটি করেছি) এইচটিটিপি প্রোটোকলে যা সংজ্ঞায়িত হয়েছে তার অনেকগুলি অনুসরণ করার চেষ্টা করেছি, এর পরে আমি আরও বাস্তববাদী হওয়ার সিদ্ধান্ত নিয়েছি এবং এটি কেবল জিইটি এবং পোষ্টে রেখেছি । POSTপদ্ধতি এমনকি পোস্ট-পুনর্নির্দেশ-get প্যাটার্ন বাস্তবায়ন নেই।

নির্বিশেষে, যেমনটি আমি উপরে উল্লেখ করেছি, ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনটি পরিষেবাটিকে কল করবে এবং এটি POSTযখন প্রয়োজন হবে তখনই সমস্ত ডেটা সহ অনুরোধটি কল করবে (প্রতিবার নয়)। এটি সার্ভারে অবিরাম অনুরোধগুলি বাধা দেয়।

ভোটদান

যদিও আরইএসটি পাশাপাশি পোলিংয়ের জন্যও ব্যবহার করা যেতে পারে, ব্রাউজারের সামঞ্জস্যের কারণে আপনি যদি এটি ব্যবহার না করেন তবে আমি এটির সুপারিশ করব না। তার জন্য আমি ওয়েবসকেটগুলি ব্যবহার করব যা আমি পাশাপাশি একটি এপিআই চুক্তিও তৈরি করেছিলাম । পুরানো ব্রাউজারগুলির জন্য আরেকটি বিকল্প হ'ল কমেটডি।


27

REST খুব বিমূর্ত। এটি কিছু ভাল, সহজ, বাস্তব-বিশ্বের উদাহরণ পেতে সহায়তা করে।

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

কারণটি হ'ল সার্ভারটি আপনার সেশন স্থিতি সংরক্ষণ করে নি। দুঃখের বিষয়, আপনার স্ক্রোলের অবস্থানটি কেবলমাত্র ক্লায়েন্টের র‍্যামে সঞ্চিত ছিল।

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

সার্ভারে আপনার কোনও লগইন সেশন নেই, কারণ তারা REST মেনে চলে।


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

তবে ওয়েব ব্রাউজারগুলির সম্পর্কে এক সেকেন্ডের জন্য কথা বলতে দিন, কারণ এটি আরইএসটি-র আরও একটি বড় সুবিধা নিয়ে আসে যা এখানে কেউই কথা বলছে না।

যদি সার্ভারটি সেশন স্থিতি সংরক্ষণের চেষ্টা করে, তবে প্রতিটি পৃথক ক্লায়েন্টকে কীভাবে সনাক্ত করা যায়?

এটি তাদের আইপি ঠিকানাটি ব্যবহার করতে পারেনি, কারণ অনেক লোক ভাগ করা রাউটারে একই ঠিকানা ব্যবহার করতে পারে। তাহলে কীভাবে?

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

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


সুতরাং ... আমি আশা করি যে আপনি এখনই দেখেন কেন স্কেলেবিলিটির জন্য বিশ্রাম এত গুরুত্বপূর্ণ। আমি আশা করি আপনি কেন সার্ভার-সাইড সেশন স্টেটটি সার্ভার স্কেলাবিলিটিতে যা ওয়েলড-অন এনভিলগুলি গাড়ির ত্বরণে রয়েছে তা দেখতে শুরু করতে পারেন।


যেখানে লোকেরা বিভ্রান্ত হয় তা এই ভেবে যে "স্টেট" ডেটাবেজে সংরক্ষিত তথ্য, যেমন উল্লেখ করে। না, এটি সার্ভারের র‍্যামে থাকা যখনই আপনি এটি ব্যবহার করার সময় থাকা কোনও তথ্যকে বোঝায়।


13

আমি দেখতে যে এখানে মৌলিক ইস্যু আপ মিশ হয় সেশন সঙ্গে রাজ্য । আরআরইএসটি নির্দিষ্ট করে যে সার্ভারে আপনার স্টেটটি সংরক্ষণ করা উচিত নয় , কোনও কিছুই আপনাকে ব্যবহারকারীর সেশন সংরক্ষণ করতে বাধা দেয় না ।

সার্ভারে রাজ্য পরিচালনা করার অর্থ আপনার সার্ভারটি ক্লায়েন্ট কী করছে তা ঠিক জানেন (অ্যাপ্লিকেশনের কোন বিভাগে তারা কোন পৃষ্ঠাটি দেখছেন)। এবং এটিই আপনার করা উচিত নয়।

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

কেউ তর্ক করতে পারে যে ক্লায়েন্টের আরও ভাল টোকেন উত্পন্ন করা উচিত। আমি বলছি এটি উভয় উপায়েই কাজ করে, এবং এটি অ্যাপ্লিকেশনটির উপর নির্ভর করবে এবং কে API এর সাথে কাজ করবে।

এছাড়াও সার্ভারে কিছু সংবেদনশীল সেশন ডেটা রাখা সঠিক উপায় হওয়া উচিত। আপনি ক্লায়েন্টকে তাদের শপিং কার্ট রাখতে বিশ্বাস করতে পারবেন না (উদাহরণস্বরূপ) "isFreeGift" নামে একটি ক্ষেত্র রয়েছে। এই জাতীয় তথ্য সার্ভারে রাখা উচিত।

তার উত্তরে সন্তানু দে প্রদত্ত ভিডিও লিঙ্কটি সহায়ক। আপনি না থাকলে এটি দেখুন।

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

প্রশ্নটি কয়েক বছরের পুরনো, আশা করি আমার উত্তরটি এখনও সহায়ক হবে।


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

11

স্টেটলেস মানে হল পরিষেবাগুলির স্থিতি পরবর্তী অনুরোধ এবং প্রতিক্রিয়ার মধ্যে স্থির থাকে না। প্রতিটি অনুরোধ নিজস্ব ব্যবহারকারীর শংসাপত্র বহন করে এবং স্বতন্ত্রভাবে প্রমাণীকরণ করা হয়। তবে রাষ্ট্রীয়ভাবে প্রতিটি অনুরোধ যে কোনও পূর্ববর্তী অনুরোধ থেকে জানা যায়। সমস্ত রাষ্ট্রীয় অনুরোধগুলি সেশন-ওরিয়েন্টেড অর্থাৎ প্রতিটি অনুরোধের পূর্ববর্তী অনুরোধগুলিতে করা পরিবর্তনগুলি জানতে এবং ধরে রাখতে হবে।

ব্যাংকিং অ্যাপ্লিকেশন রাষ্ট্রীয় প্রয়োগের একটি উদাহরণ। যেখানে ব্যবহারকারীরা প্রথমে লগইন করে তার পরে লেনদেন এবং লগ আউট করে। লগআউট করার পরে যদি ব্যবহারকারী লেনদেন করার চেষ্টা করে তবে তিনি তা করতে সক্ষম হবেন না।

হ্যাঁ, এইচটিপি প্রোটোকল মূলত একটি স্টেটলেস প্রোটোকল তবে এটিকে রাষ্ট্রীয় করে তুলতে আমরা আমাদের এইচটিটিপি কুকি তৈরি করি। সুতরাং, ডিফল্টরূপে এসওএপি হয়। তবে এটি একইভাবে রাজ্যময় করা যায়, আপনি যে কাঠামোটি ব্যবহার করছেন তার উপর নির্ভর করে।

এইচটিটিপি রাষ্ট্রবিহীন তবে তবুও আমরা আমাদের বিভিন্ন জাভা অ্যাপ্লিকেশনটিতে বিভিন্ন সেশন ট্র্যাকিং প্রক্রিয়াটি ব্যবহার করে সেশন বজায় রাখতে পারি।

হ্যাঁ, আমরা ওয়েব সার্ভিসে সেশন বজায় রাখতে পারি যদিও তা রেস্ট বা এসওএপি হয়। এটি কোনও তৃতীয় পক্ষের গ্রন্থাগার ব্যবহার করে প্রয়োগ করা যেতে পারে বা আপনি আমাদের নিজস্ব দ্বারা প্রয়োগ করতে পারেন।

থেকে নেওয়া Http://gpaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap


11

এখানে কোন চামচ নেই.

" আপনার সমস্ত জিনিস বার বার সার্ভারে প্রেরণ করা" এর মতো রাষ্ট্রহীনতার কথা ভাবেন না । কোনভাবেই না. সেখানে রাষ্ট্র হবে, সবসময় - ডাটাবেসের নিজেই হয় সব পরে রাষ্ট্র এক ধরনের, যদি আপনি নিবন্ধীকৃত ব্যবহারকারী, তাই ক্লায়েন্ট-সাইড তথ্য কোন সেট সার্ভার প্রান্তের ছাড়া বৈধ হবে না। প্রযুক্তিগতভাবে, আপনি সত্যই কখনও রাষ্ট্রহীন হন না

লগইন প্রতি বার একটি শব্দ বিতর্ক

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

পদচিহ্ন হ্রাস করুন

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

একটি ভাগ স্টোরেজ আবশ্যক। সার্ভারের জানা দরকার যে কেউ লগ ইন করেছে কিনা। (এবং আপনি যখনই এটি সিদ্ধান্ত নেওয়ার প্রয়োজনবোধে ডাটাবেসটিকে বিরক্ত করেন তবে আপনি কার্যত ডুমড হন)) ভাগ করে নেওয়া স্টোরগুলি ডাটাবেসের তুলনায় অনেক দ্রুত হওয়া দরকার। এটি প্রলোভন এনেছে: ঠিক আছে, আমার খুব দ্রুত স্টোরেজ আছে, কেন সেখানে সবকিছু করা যায় না? - এবং সেখানেই জিনিসগুলি অন্য উপায়ে খারাপ হয়।

সুতরাং আপনি বলছেন, নূন্যতম সেশন স্টোরেজ রাখুন?

আবার, এটি আপনার সিদ্ধান্ত। পারফরম্যান্সের কারণে আপনি সেখানে স্টাফ রাখতে পারেন (ডাটাবেসগুলি রেডিসের তুলনায় প্রায় ধীর গতিতে), আপনি অতিরিক্ত পরিমাণে তথ্য সংরক্ষণ করতে পারেন, আপনার নিজস্ব ক্যাচিং বাস্তবায়ন করতে পারেন - কেবল মনে রাখবেন যে আপনি প্রচুর আবর্জনা সঞ্চয় করলে ওয়েব সার্ভারগুলির একটি বড় লোড হবে তাদের উপর এছাড়াও, যদি তারা ভারী বোঝা (এবং তারা করবে) এর নিচে ভেঙে যায়, আপনি মূল্যবান তথ্য হারাবেন; বিশ্রামের চিন্তাভাবনার সাথে, এক্ষেত্রে যা ঘটে তা হ'ল ক্লায়েন্টটি আবার একই (!) অনুরোধটি প্রেরণ করে এবং এটি এবার পরিবেশন করা হবে।

ঠিক তখন কীভাবে করবেন?

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

চিন্তা করুন এবং সিদ্ধান্ত নিন, ডিজাইনের ট্রেন্ডগুলি আপনার জন্য চিন্তা না করে।


1
"ভাবুন এবং সিদ্ধান্ত নিন, ডিজাইন ট্রেন্ডগুলি আপনার জন্য চিন্তা না করে don't" দুর্ভাগ্যক্রমে আজকাল খুব সাধারণ হয়ে ওঠে কেবল বোকামিভাবে ট্রেন্ডগুলি অনুসরণ করা। কখনও কখনও এস ও পড়তে আপনি কেবল প্রবণতার কারণে সমস্ত একই উত্তর পেয়ে যাবেন।
l00k

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

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

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

5

এই উপস্থাপনাটি দেখুন।

http://youtu.be/MRxTP-rQ-S8

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


1
দয়া করে পড়ুন আমি কীভাবে একটি ভাল উত্তর লিখতে পারি? আরও প্রশ্নের উত্তর দেওয়ার চেষ্টা করার আগে।

3

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

আইএমও, এপিআই স্টেটলেস হওয়া উচিত যা দেয়ালাই সত্যিই দ্রুত স্কেল করতে দেয়।


2

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

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


আপনি যদি প্রতিটি অনুরোধের সাথে প্রমাণী ডেটা প্রেরণ করেন তবে আপনি ক্লায়েন্টে শংসাপত্রগুলি কোথায় / কীভাবে সংরক্ষণ করবেন যাতে ব্যবহারকারীর প্রতিটি অনুরোধে এটি পুনরায় প্রবেশ করতে না হয়?
অ্যাম্বার

1

আপনি যখন কোনও রেস্টস্টুল সার্ভিস বিকাশ করেন, লগ ইন করার জন্য আপনাকে আপনার ব্যবহারকারীর সত্যতা প্রমাণ করতে হবে। একটি সম্ভাব্য বিকল্প হ'ল প্রতিবার আপনি কোনও ব্যবহারকারী ক্রিয়া করার ইচ্ছামত ব্যবহারকারী নাম এবং পাসওয়ার্ড প্রেরণ করা। এই ক্ষেত্রে সার্ভারটি মোটেও সেশন-ডেটা সঞ্চয় করবে না।

অন্য বিকল্পটি হ'ল সার্ভারে একটি সেশন-আইডি তৈরি করা এবং এটি ক্লায়েন্টকে প্রেরণ করা, যাতে ক্লায়েন্টটি সার্ভারে সেশন-আইডি প্রেরণ করতে সক্ষম হবে এবং এটির সাথে প্রমাণীকরণ করবে। এটি প্রতিবার ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রেরণের চেয়ে অনেক বেশি নিরাপদ, যেহেতু যদি কেউ সেই ডেটাটির উপরে হাত দেয়, তবে ব্যবহারকারীর নাম এবং পাসওয়ার্ড পরিবর্তন না হওয়া পর্যন্ত সে / সে ব্যবহারকারীর ছদ্মবেশ তৈরি করতে পারে। আপনি বলতে পারেন যে সেশন আইডিটিও চুরি হয়ে যেতে পারে এবং ব্যবহারকারী সেই ক্ষেত্রে নকল করা হবে এবং আপনি ঠিক বলেছেন। তবে সেক্ষেত্রে সেশন আইডি বৈধ থাকাকালীন ক্ষেত্রে এই ক্ষেত্রে ব্যবহারকারীর ছদ্মবেশ তৈরি করা সম্ভব হবে।

যদি RESTful API এ ব্যবহারকারীর নাম এবং পাসওয়ার্ড পরিবর্তন করার জন্য ব্যবহারকারীর নাম এবং পাসওয়ার্ডের প্রত্যাশা করে তবে সেশন আইডি ব্যবহার করে কেউ ব্যবহারকারীর ছদ্মবেশ ধারণ করলেও হ্যাকার আসল ব্যবহারকারীকে লক আউট করতে সক্ষম হবে না।

সেশন-আইডি এমন কোনও উপায়ে-লকিং (এনক্রিপশন) দ্বারা উত্পন্ন করা যেতে পারে যা ব্যবহারকারীকে সনাক্ত করে এবং সেশন আইডিতে সময় যুক্ত করে, এইভাবে সেশনের মেয়াদ শেষ হওয়ার সময়টি সংজ্ঞায়িত করা যায়।

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


এটি বোধগম্য
মেস্টার্ডেড

0

পুরো ধারণাটি ভিন্ন ... সেক্ষেত্রে প্রতিটি অনুরোধে প্রমাণীকরণ প্রক্রিয়া করা আরও ভাল (যেখানে পারফরম্যান্সের ক্ষেত্রে এটিতে অতিরিক্ত ব্যয় হয় - হ্যাশিং পাসওয়ার্ড একটি ভাল উদাহরণ হতে পারে a কোনও বড় ব্যাপার নয় ...)। আপনি যদি সেশনগুলি ব্যবহার করেন - আপনি কীভাবে একাধিক সার্ভারগুলিতে লোড বিতরণ করতে পারেন? আমি বাজি দিয়ে বলছি যে RESTFul প্রোটোকলটি যা কিছু হোক সেশনগুলি নির্মূল করার জন্য - আপনার সত্যিকারের এগুলির দরকার নেই ... এজন্য এটিকে "রাষ্ট্রবিহীন" বলা হয়। সেশনগুলি কেবল তখনই প্রয়োজন হয় যখন আপনি কুকি ব্যতীত কোনও ক্লায়েন্টের পাশে কোনও রেকেষ্ট তৈরির পরে আর কিছু সঞ্চয় করতে পারবেন না (উদাহরণস্বরূপ পুরানো, জাভাস্ক্রিপ্ট / এইচটিএমএল 5-সমর্থনকারী ব্রাউজারটি নিন)। "সম্পূর্ণ বৈশিষ্ট্যযুক্ত" আরএসটিএফুল ক্লায়েন্টের ক্ষেত্রে এটি সাধারণত সঞ্চয় করা নিরাপদbase64(login:password) অ্যাপ্লিকেশনটি এখনও লোড না হওয়া অবধি ক্লায়েন্টের (মেমোরিতে) - অ্যাপ্লিকেশনটি কেবলমাত্র হোস্টে অ্যাক্সেস করতে ব্যবহৃত হয় এবং তৃতীয় পক্ষের স্ক্রিপ্টগুলির মাধ্যমে কুকিকে আপস করা যাবে না ...

আমি আরইএসটিএফুল সেভেসির জন্য কুকি প্রমাণীকরণ অক্ষম করার জন্য দৃ stron়ভাবে সুপারিশ করব ... বেসিক / ডাইজেস্ট আথ পরীক্ষা করে দেখুন - এটি আরইএসটিএফ ভিত্তিক পরিষেবাগুলির জন্য পর্যাপ্ত হওয়া উচিত।


3
কী a client side (in memory) এবং কীভাবে এটি base64(login:password)ক্লায়েন্টের পক্ষে সংরক্ষণ করা নিরাপদ ?
আরএন কুশওয়াহা

1
কিছুই "সম্পূর্ণ নিরাপদ" হিসাবে সংজ্ঞায়িত করা হয় না। তবে, আপনি এপিআই অনুরোধের জন্য বেস 64 স্ট্রিং সংরক্ষণের চেয়ে ভাল সুরক্ষা সরবরাহ করার জন্য OAuth2 ব্যবহার করার কথা বিবেচনা করতে পারেন (বেসিক আথ), আপনি যদি বেসিক লেখাকে আঁকড়ে রাখেন তবে আপনি ভাল সুরক্ষার জন্য এইচটিটিপিএস ব্যবহার করতে পারেন।
felixwcf

3
আরএন কুশওয়াহা, এই প্রশ্নটি কেউই উত্তর দিতে চায় বলে মনে হয় না যখন তারা আপনাকে বলে সার্ভারে সেশন সংরক্ষণ এবং ক্লায়েন্টে এটি সঞ্চয় করে।
বেনিরোজ

0

REST রাষ্ট্রহীন এবং অনুরোধগুলির মধ্যে কোনও রাজ্য বজায় রাখে না। ক্লায়েন্ট কুকিজ / শিরোনাম প্রমাণীকরণের মতো ব্যবহারকারীর অবস্থা বজায় রাখতে সেট করা আছে। ক্লায়েন্টের ব্যবহারকারীর নাম / পাসওয়ার্ডটি তৃতীয় অংশের প্রমাণীকরণ প্রক্রিয়া - ২ য় স্তরের ওটিপি জার্নেশন ইত্যাদি দ্বারা বৈধ হয়ে গেছে user । এখন আইপির মতো ব্যবহারকারীর নির্দিষ্ট তথ্য হয় হয় ক্যাশে রক্ষণাবেক্ষণ করা হয় এবং এরপরে যদি তালিকাভুক্ত সংস্থানগুলির জন্য একই আইপি (ম্যাক ঠিকানা) থেকে অনুরোধ আসে তবে ব্যবহারকারীকে অনুমতি দেওয়া হবে। এবং ক্যাশে কিছু নির্দিষ্ট সময়ের জন্য রক্ষণাবেক্ষণ করা হয় যা একবার সময় পরে যায় invalid সুতরাং হয় ক্যাশে ব্যবহার করা যেতে পারে বা ডিবি এন্ট্রিগুলি তথ্য বি / ডাব্লু অনুরোধগুলি অব্যাহত রাখতে ব্যবহার করা যেতে পারে।


0

রাজ্যহীন এখানে অর্থ হ'ল অনুরোধের রাজ্য বা মেটা ডেটা সার্ভারের পাশেই রক্ষণ করা হয় না। সার্ভারে প্রতিটি অনুরোধ বা ব্যবহারকারীর অবস্থা বজায় রাখার ফলে এটি পারফরম্যান্সের বাধা সৃষ্টি করে। কোনও নির্দিষ্ট ক্রিয়াকলাপ সম্পাদনের জন্য প্রয়োজনীয় বৈশিষ্ট্য সহ সার্ভারকে অনুরোধ করা হয়েছে।

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

এটি অ্যাপ্লিকেশনটিতে ব্যবহারকারীর অবস্থা বজায় রাখতে বা রাখতে পারে।

আশাকরি এটা সাহায্য করবে!

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.