আমি মনে করি আপনার এখানে ব্যবহারকারীর অমিলের ব্যবহারকারীর একটি প্রক্রিয়া থাকতে পারে।
প্রথম: একজন ব্যবহারকারী কি একযোগে কোনও ফাইলে একাধিক পরিবর্তন সম্পাদন করতে চান ? একটি পুনর্নামকরণ (যা পথের পরিবর্তনের অন্তর্ভুক্ত হতে পারে বা নাও থাকতে পারে?), মালিকানা পরিবর্তন এবং সম্ভবত ফাইল সামগ্রীর পরিবর্তন (যুক্তির স্বার্থে) পৃথক ক্রিয়া বলে মনে হয়।
উত্তরটি "হ্যাঁ" যেখানে রয়েছে তা কেসে নেওয়া যাক - আপনার ব্যবহারকারীরা সত্যিই একসাথে এই পরিবর্তনগুলি করতে চান।
যে ক্ষেত্রে, আমি দৃঢ়ভাবে কোনো বাস্তবায়ন একাধিক ঘটনা পাঠায় বিরুদ্ধে বলতে চাই - RenameFileCommand, MoveFileCommand, ChangeOwnerCommand- এই প্রতিনিধিত্ব করতে একক ব্যবহারকারী অভিপ্রায়।
কেন? কারণ ইভেন্টগুলি ব্যর্থ হতে পারে। হতে পারে এটি অত্যন্ত বিরল, তবে আপনার ব্যবহারকারী এমন একটি অপারেশন জমা দিয়েছেন যা পারমাণবিক বলে মনে হয়েছিল - যদি কোনও প্রবাহের ইভেন্টগুলি যদি ব্যর্থ হয় তবে আপনার অ্যাপ্লিকেশনের অবস্থাটি এখন অবৈধ।
আপনি এমন কোনও সংস্থার উপর রেস বিপদের জন্যও আমন্ত্রণ জানাচ্ছেন যা ইভেন্ট হ্যান্ডলারের প্রত্যেকটির মধ্যে স্পষ্টভাবে ভাগ করা হয়। আপনাকে "চেঞ্জওউনারকম্যান্ড" এমনভাবে লিখতে হবে যাতে ফাইলের নাম এবং ফাইলের পাথ গুরুত্বপূর্ণ না, কারণ কমান্ডটি প্রাপ্ত হওয়ার সাথে সাথে এগুলি পুরানো হতে পারে।
ফাইলগুলি মুভিং এবং নামকরণের সাথে একটি অ-ইভেন্ট চালিত বিশ্রামের সিস্টেমটি প্রয়োগ করার সময়, আমি একটি ইটাগ সিস্টেমের মতো কিছু ব্যবহার করে ধারাবাহিকতা নিশ্চিত করতে পছন্দ করি - নিশ্চিত হওয়া উচিত যে সংস্থানটির সংস্থান করা হচ্ছে যে সংস্করণটি ব্যবহারকারী সর্বশেষ পুনরুদ্ধার করেছে এবং যদি এটি ব্যর্থ হয় তারপর থেকে সংশোধন করা হয়েছে। তবে আপনি যদি এই একক ব্যবহারকারীর জন্য একাধিক কমান্ড প্রেরণ করছেন তবে আপনাকে প্রতিটি কমান্ডের পরে আপনার সংস্থান সংস্করণ বৃদ্ধি করতে হবে - সুতরাং আপনার জানার কোনও উপায় নেই যে ব্যবহারকারী যে রিসোর্সটি সম্পাদনা করছে তা হ'ল তারা যে রিসোর্সটি পড়েছে ঠিক একই সংস্করণ read ।
আমি এর দ্বারা যা বোঝাতে চাইছি তা হল - যদি অন্য কেউ প্রায় একই সময়ে ফাইলটিতে অন্য কোনও ক্রিয়াকলাপ সম্পাদন করে। 6 টি কমান্ড যে কোনও ক্রমে স্ট্যাক আপ করতে পারে। যদি আমাদের মাত্র 2 টি পারমাণবিক কমান্ড থাকে তবে পূর্ববর্তী কমান্ডটি সফল হতে পারে এবং পরবর্তী কমান্ডটি ব্যর্থ হতে পারে "শেষ অবধি পুনরুদ্ধার হওয়ার পরে সংস্থানটি পরিবর্তন করা হয়েছে"। কমান্ডগুলি পারমাণবিক না থাকলেও এর বিরুদ্ধে কোনও সুরক্ষা নেই, সুতরাং সিস্টেমের ধারাবাহিকতা লঙ্ঘন করা হয়।
মজার বিষয় হ'ল আরএসটি-তে ইভেন্ট ভিত্তিক আর্কিটেকচারের মতো কিছু দিকে একটি আন্দোলন চলছে, যাকে থ্যাচট্রাক্স প্রযুক্তির রাডার, 2015 এর মধ্যে প্রস্তাবিত, "বিশ্রাম ব্যতীত পিইউটি " বলা হয় । এখানে PUT ছাড়াই বিশ্রামের জন্য যথেষ্ট দীর্ঘ ব্লগ রয়েছে ।
মূলত, ধারণাটি হ'ল পোষ্ট, পুট, ডিলেট এবং জিইটি ছোট অ্যাপ্লিকেশনগুলির জন্য ভাল তবে আপনি যখন ধরে নিতে শুরু করেন যে কীভাবে পোস্ট এবং মুছুন এবং মুছুন অন্য প্রান্তে কীভাবে ব্যাখ্যা করা যেতে পারে, আপনি সংযোগের পরিচয় দিন। (উদাঃ "যখন আমি আমার ব্যাংক অ্যাকাউন্টের সাথে সম্পদটি মুছে ফেলি, তখন অ্যাকাউন্টটি বন্ধ করে দেওয়া উচিত") এবং প্রস্তাবিত সমাধানটি হ'ল আরও ইভেন্টের উত্সাহিত উপায়ে REST এর চিকিত্সা করা। অর্থাত্ ব্যবহারকারীকে একক ইভেন্ট সংস্থান হিসাবে পোষ্ট করতে দেয়।
অন্য ক্ষেত্রে সহজ। যদি আপনার ব্যবহারকারীরা সেই সমস্ত ক্রিয়াকলাপ একই সাথে করতে না চান তবে তাদেরকে দেবেন না। প্রতিটি ব্যবহারকারীর অভিপ্রায় জন্য একটি ইভেন্ট পোস্ট করুন। এখন আপনি আপনার সংস্থানগুলিতে ইটাগ সংস্করণ ব্যবহার করতে পারেন।
অন্যান্য অ্যাপ্লিকেশনগুলির জন্য যা আপনার সংস্থানগুলিতে খুব আলাদা এপিআই ব্যবহার করছে। যে দুর্গন্ধের মত গন্ধ। আপনি কি আপনার RESTful API এর উপরে পুরানো এপিআইয়ের একটি ফ্যাসাদ তৈরি করতে পারেন এবং সেগুলি সম্মুখের দিকে চিহ্নিত করতে পারেন? অর্থাত এমন পরিষেবাটি উন্মোচন করুন যা আরআরএসটি সার্ভারের মাধ্যমে ক্রমানুসারে কোনও ফাইলে একাধিক আপডেট সম্পাদন করে?
আপনি যদি না পুরানো সমাধানের শীর্ষে আরএসটিফুল ইন্টারফেস তৈরি করেন না, বা আরএসটি সমাধানের শীর্ষে পুরাতন ইন্টারফেসের একটি মুখোমুখি তৈরি করেন না এবং ভাগ করে নেওয়া ডেটা রিসোর্সে ইঙ্গিত করে উভয় এপিআই বজায় রাখার চেষ্টা করেন, তবে আপনি বড় মাথাব্যথা অনুভব করবেন।