REST এ লেনদেন?

Question

আমি ভাবছি কীভাবে আপনি বিশ্রামে নিম্নলিখিত ব্যবহার-কেসটি প্রয়োগ করবেন। ধারণাগত মডেলটির সাথে আপস না করে কী করাও সম্ভব?

একক লেনদেনের সুযোগের মধ্যে একাধিক সংস্থান পড়ুন বা আপডেট করুন। উদাহরণস্বরূপ, ববের ব্যাংক অ্যাকাউন্ট থেকে জনের অ্যাকাউন্টে $ 100 স্থানান্তর করুন।

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

Answer 1

একটি বিশ্রামের শপিং ঝুড়ি দৃশ্য বিবেচনা করুন। শপিং ঝুড়ি ধারণাটি আপনার লেনদেনের মোড়ক। আপনি শপিংয়ের ঝুড়িতে একাধিক আইটেম যুক্ত করতে পারেন এবং অর্ডার প্রক্রিয়া করার জন্য সেই ঝুড়িটি জমা দিতে পারেন, আপনি লেনদেনের মোড়কে ববের অ্যাকাউন্ট এন্ট্রি এবং তারপরে বিলের অ্যাকাউন্টে প্রবেশ করতে পারেন। সমস্ত টুকরা স্থানে থাকলে আপনি সমস্ত উপাদান টুকরা দিয়ে লেনদেনের মোড়ক পোস্ট / পুট করতে পারেন।

Comments

ট্রান্সফারমনিট্রান্স্যাকশন কেন একটি কার্যকর ব্যাঙ্কিং সংস্থান হবে না?

— ড্যারেল মিলার

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

— ড্যারেল মিলার

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

— ড্যারেল মিলার

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

— meandmycode

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

— ড্যারেল মিলার

Answer 2

এই প্রশ্নটির দ্বারা উত্তর দেওয়া হয়নি এমন কয়েকটি গুরুত্বপূর্ণ মামলা রয়েছে, যা আমার মনে হয় খুব খারাপ, কারণ অনুসন্ধানের পদগুলির জন্য গুগলে এটির উচ্চমানের অবস্থান রয়েছে :-)

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

এটি পেতে, আপনি একটি অবজেক্ট হিসাবে একটি লেনদেন তৈরি করেন। এটিতে আপনার ইতিমধ্যে জানা সমস্ত ডেটা থাকতে পারে এবং লেনদেনটিকে একটি মুলতুবি অবস্থায় রাখতে পারে।

POST /transfer/txn
{"source":"john's account", "destination":"bob's account", "amount":10}

{"id":"/transfer/txn/12345", "state":"pending", "source":...}

আপনার একবার এই লেনদেন হয়ে গেলে আপনি এটি প্রতিশ্রুতিবদ্ধ করতে পারেন, এরকম কিছু:

PUT /transfer/txn/12345
{"id":"/transfer/txn/12345", "state":"committed", ...}

{"id":"/transfer/txn/12345", "state":"committed", ...}

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

যতক্ষণ আপনি একটি একক ডাটাবেস, বা একটি সংহত লেনদেনের মনিটরের সাথে একটি ডাটাবেসের সাথে কথা বলবেন, এই প্রক্রিয়াটি আসলে ঠিক ঠিক কাজ করবে work আপনি লেনদেনের জন্য অতিরিক্ত সময়-আউটওয়ের পরিচয় দিতে পারেন, যা আপনি চাইলে মেয়াদোত্তীর্ণ শিরোনাম ব্যবহার করে প্রকাশও করতে পারেন।

Comments

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

— ইরক

Answer 3

REST পদগুলিতে, সংস্থানগুলি বিশেষ্য যা CRUD (তৈরি / পঠন / আপডেট / মোছা) ক্রিয়া দ্বারা কাজ করা যেতে পারে। যেহেতু কোনও "ট্রান্সফার মানি" ক্রিয়া নেই তাই আমাদের একটি "লেনদেন" সংস্থান সংজ্ঞা দেওয়া দরকার যা সিআরইউডি দিয়ে কাজ করা যায়। এখানে HTTP + পক্সের একটি উদাহরণ। প্রথম পদক্ষেপটি তৈরি করা (HTTP পোস্ট পদ্ধতি) একটি নতুন ফাঁকা লেনদেন:

POST /transaction

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

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

এরপরে, আমরা স্পষ্টভাবে প্রতিশ্রুতিবদ্ধ সমস্ত ডেটা সহ লেনদেন আপডেট (পুট HTTP পদ্ধতি) করি:

PUT /transaction/1234
<transaction>
  <from>/account/john</from>
  <to>/account/bob</to>
  <amount>100</amount>
</transaction>

আইডি "1234" এর সাথে যদি কোনও লেনদেন আগে PUT হয়ে থাকে তবে সার্ভারটি একটি ত্রুটি প্রতিক্রিয়া দেয়, অন্যথায় একটি সম্পূর্ণ প্রতিক্রিয়া দেখার জন্য একটি ঠিক আছে প্রতিক্রিয়া এবং একটি URL।

এনবি: ইন / অ্যাকাউন্ট / জন, "জন" অবশ্যই জনের অনন্য অ্যাকাউন্ট নম্বর হওয়া উচিত।

Comments

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

মারাত্মক ভুল? আমি জানি PUT এবং POST এর মধ্যে পার্থক্য রয়েছে, তবে CRUD তে একটি আলগা ম্যাপিং রয়েছে। "সিরিয়াসলি"?

— টেড জনসন

হ্যাঁ গম্ভীরভাবে. সিআরইউডি হ'ল ডেটা স্টোরেজ স্ট্রাকচার করার একটি উপায়; আরআরইএসটি হ'ল অ্যাপ্লিকেশন ডেটা প্রবাহকে কাঠামোগত করার একটি উপায়। আপনি REST এ CRUD করতে পারেন, তবে CRUD এ REST করতে পারবেন না। তারা সমতুল্য নয়।

— জন ওয়াট

Answer 4

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

তবে তিনি রাষ্ট্রের মেশিন হিসাবে "প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তর" সম্পর্কে কথা বলেন, লিঙ্কগুলি পরের রাজ্যে স্থানান্তরিত করে। এইভাবে, দস্তাবেজগুলি (উপস্থাপনাগুলি) সার্ভারের পরিবর্তে ক্লায়েন্টের অবস্থার উপর নজর রাখে। এইভাবে, কোনও ক্লায়েন্টের রাষ্ট্র নেই, কেবলমাত্র আপনি কোন লিঙ্কে রয়েছেন তার শর্ত অনুযায়ী state

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

1. আপনি সমস্ত তথ্য সহ একটি লেনদেনের ধারণার উপস্থাপনা আপলোড ( পোস্ট ) করুন। এটি দেখতে কেবল একটি আরপিসি কলের মতো দেখাচ্ছে তবে এটি সত্যিই "প্রস্তাবিত লেনদেনের সংস্থান" তৈরি করছে। উদাহরণস্বরূপ ইউআরআই: /transaction গ্লিচগুলি একাধিক ইউআরআই সহ একাধিক সংস্থান তৈরি করতে পারে cause
2. সার্ভারের প্রতিক্রিয়াটিতে তৈরি হওয়া সংস্থার ইউআরআই, এর উপস্থাপনা - এতে একটি নতুন "প্রতিশ্রুতিবদ্ধ লেনদেন সংস্থান" সম্পর্কিত রিসোর্স তৈরি করতে লিংক ( ইউআরআই ) অন্তর্ভুক্ত রয়েছে । অন্যান্য সম্পর্কিত সংস্থানগুলি প্রস্তাবিত লেনদেন মোছার লিঙ্ক। এগুলি রাষ্ট্র-মেশিনে থাকা রাজ্য, যা ক্লায়েন্ট অনুসরণ করতে পারে। যৌক্তিকভাবে, এগুলি হ'ল সংস্থানটির যে অংশটি সার্ভারে তৈরি হয়েছে, ক্লায়েন্ট সরবরাহিত তথ্যের বাইরে। যেমন URI: /transaction/1234/proposed, /transaction/1234/committed
3. আপনি "প্রতিশ্রুতিবদ্ধ লেনদেনের সংস্থান" তৈরি করতে লিংকে পোষ্ট করুন , যা সেই সংস্থান তৈরি করে, সার্ভারের অবস্থা পরিবর্তন করে (দুটি অ্যাকাউন্টের ভারসাম্য) **। এর প্রকৃতির দ্বারা, এই সংস্থানটি কেবল একবার তৈরি করা যেতে পারে, এবং আপডেট করা যায় না। অতএব, অনেক লেনদেনের প্রতিশ্রুতিবদ্ধ ভুলগুলি ঘটতে পারে না।
4. আপনি এই দুটি সংস্থান পেতে পারেন, তাদের অবস্থা কী তা দেখতে। ধরে নিই যে কোনও পোষ্ট অন্য সংস্থানগুলি পরিবর্তন করতে পারে, প্রস্তাবটি এখন "প্রতিশ্রুতিবদ্ধ" হিসাবে চিহ্নিত করা হবে (বা সম্ভবত, এটি মোটেই উপলব্ধ নয়)।

এটি ওয়েবপৃষ্ঠাগুলি কীভাবে পরিচালিত হয় তার সমান, চূড়ান্ত ওয়েবপৃষ্ঠাটি বলে যে "আপনি কি এটি নিশ্চিত?" সেই চূড়ান্ত ওয়েবপৃষ্ঠাটি নিজেই লেনদেনের রাজ্যের প্রতিনিধিত্ব করে, যাতে পরবর্তী রাজ্যে যাওয়ার জন্য একটি লিঙ্ক অন্তর্ভুক্ত থাকে। শুধু আর্থিক লেনদেন নয়; এছাড়াও (যেমন) পূর্বরূপ উইকিপিডিয়াতে প্রতিশ্রুতিবদ্ধ। আমি অনুমান করি যে আরইএসটি-র মধ্যে পার্থক্যটি হ'ল রাজ্যের ক্রমগুলির প্রতিটি পর্যায়ে একটি সুস্পষ্ট নাম (এটির ইউআরআই) থাকে।

বাস্তব জীবনের লেনদেন / বিক্রয় ক্ষেত্রে, লেনদেনের বিভিন্ন পর্যায়ে (প্রস্তাব, ক্রয়ের আদেশ, রশিদ ইত্যাদি) প্রায়শই বিভিন্ন শারীরিক নথি থাকে। এমনকি বাড়ি কেনার জন্য, বন্দোবস্ত সহ আরও অনেক কিছু

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

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

Comments

আপনি কি দয়া করে ব্যাখ্যা করতে পারেন যে "ক্লায়েন্টের উপরে রাষ্ট্র রাখার দরকার নেই" কীভাবে স্কেলাবিলিটি সাহায্য করে? কী ধরণের স্কেলাবিলিটি? স্কেলিবিলিটি কোন অর্থে?

— heেগেদাস

Answer 5

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

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

Comments

ঠিক আছে, তবে বিতরণ করা মাইক্রো-সার্ভিস আর্কিটেকচারের ক্ষেত্রে বিকল্প কী হওয়া উচিত?

— ভিটামন

Answer 6

আমি 10 বছর ধরে এই বিষয় থেকে সরে এসেছি। ফিরে আসছি, আপনি যখন বিজ্ঞান + নির্ভরযোগ্য গুগল করেন তখন যে বিজ্ঞানের মুখোমুখি হয়েছিল তা আমি বিশ্বাস করতে পারি না। বিভ্রান্তিটি পৌরাণিক।

আমি এই বিস্তৃত প্রশ্নটি তিনটি মধ্যে বিভক্ত:

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

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

Answer 7

আপনাকে নিজের "লেনদেন আইডি" টাইপ টিএক্স পরিচালনার রোল করতে হবে। সুতরাং এটি 4 কল হবে:

http://service/transaction (some sort of tx request)
http://service/bankaccount/bob (give tx id)
http://service/bankaccount/john (give tx id)
http://service/transaction (request to commit)

আপনাকে কোনও ডিবিতে (যদি ভারসাম্য ভারসাম্যপূর্ণ) বা মেমরির মধ্যে বা তার পরে স্ট্রাইক পরিচালনা করতে হবে, তারপরে কমিট, রোলব্যাক, সময়সীমা হ্যান্ডলিং করতে হবে।

পার্কে আসলেই কোনও বিশ্রামের দিন নয়।

Comments

আমি মনে করি না এটি একটি বিশেষত ভাল চিত্রণ। আপনার কেবল দুটি পদক্ষেপের প্রয়োজন: লেনদেন তৈরি করুন ("মুলতুবি" অবস্থায় একটি লেনদেন তৈরি করে) এবং প্রতিশ্রুতিবদ্ধ লেনদেন (অনাবৃত হলে প্রতিশ্রুতি দেয় এবং সংস্থানটি প্রতিশ্রুত বা ঘূর্ণিত-ব্যাক অবস্থায় সরিয়ে দেয়)।

— জন ওয়াট

Answer 8

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

আমি সত্যিই মনে করি যে কাস্টম ট্রানজেকশন ম্যানেজার তৈরি করতে আপনি যে অতিরিক্ত হুপের মাধ্যমে ঝাঁপিয়ে পড়বেন সেগুলি মূল্যহীন নয়, যখন আপনি কেবল এটি করার জন্য ডাটাবেসটি ব্যবহার করতে পারেন।

Answer 9

সর্বপ্রথম অর্থ স্থানান্তর হ'ল এমন কিছু নয় যা আপনি একটি একক সংস্থান কলে করতে পারবেন না। আপনি যে ক্রিয়াটি করতে চান তা হ'ল অর্থ প্রেরণ। সুতরাং আপনি প্রেরকের অ্যাকাউন্টে একটি অর্থ স্থানান্তর সংস্থান যোগ করুন।

POST: accounts/alice, new Transfer {target:"BOB", abmount:100, currency:"CHF"}.

সম্পন্ন. আপনার জানার দরকার নেই যে এটি লেনদেন যা অবশ্যই পারমাণবিক etc. এ থেকে বি তে টাকা পাঠান

---

তবে বিরল ক্ষেত্রে এখানে একটি সাধারণ সমাধান:

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

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

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

---

আসল সমাধান:

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

HTTP কুকিজ সম্পর্কে উইকিপিডিয়ায় কি লেখা আছে তা মনে রাখবেন:

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

সুতরাং মূলত যদি আপনাকে রাজ্যে যেতে হয় তবে একটি কুকি ব্যবহার করুন। এটি একেবারে একই কারণে ডিজাইন করা হয়েছে, এটি HTTP এবং তাই এটি ডিজাইনের মাধ্যমে REST এর সাথে সামঞ্জস্যপূর্ণ :) :)

---

আরও ভাল সমাধান:

যদি আপনি একাধিক অনুরোধ জড়িত একটি ক্লায়েন্ট একটি ওয়ার্কফ্লো সঞ্চালন সম্পর্কে কথা বলতে আপনি সাধারণত প্রোটোকল সম্পর্কে কথা বলতে। প্রোটোকল প্রতিটি ফর্ম আপনি বি করতে পারার আগে পদক্ষেপ এ সঞ্চালনের মতো প্রতিটি সম্ভাব্য পদক্ষেপের পূর্ব শর্তগুলির একটি সেট নিয়ে আসে B.

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

এজেন্ট রূপক ব্যবহার করে আপনি এমন একটি সংস্থান সরবরাহ করতে পারেন যা আপনার জন্য প্রয়োজনীয় সমস্ত পদক্ষেপগুলি সম্পাদন করতে পারে এবং তার তালিকায় এটি যে কার্যকরী কার্য / নির্দেশনাটি কাজ করে তা সংরক্ষণ করতে পারে (যাতে আমরা এজেন্ট বা কোনও 'এজেন্সিতে পোস্ট ব্যবহার করতে পারি)।

একটি জটিল উদাহরণ:

বাড়ি কেনা:

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

এই পদক্ষেপগুলি সম্পূর্ণ হতে বেশ কয়েক দিন সময় নিতে পারে, কিছু সমান্তরালভাবে করা যেতে পারে etc.

এটি করার জন্য, আপনি কেবল এজেন্টকে টাস্ক হাউজ কিনবেন যেমন:

POST: agency.com/ { task: "buy house", target:"link:toHouse", credibilities:"IamMe"}.

সম্পন্ন. এজেন্সি আপনাকে এমন একটি রেফারেন্স প্রেরণ করে যা আপনি এই কাজের স্থিতি দেখতে এবং ট্র্যাক করতে ব্যবহার করতে পারেন এবং বাকিটি এজেন্সিটির এজেন্টরা স্বয়ংক্রিয়ভাবে সম্পন্ন করে।

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

Answer 10

আপনাকে অবশ্যই REST এ সার্ভার সাইড লেনদেন ব্যবহার করা উচিত নয়।

বিশ্রামের মধ্যে অন্যতম বাধা:

আড়ম্বরহীন

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

একমাত্র RESTful উপায় হ'ল লেনদেন পুনরায় লগ তৈরি করা এবং এটি ক্লায়েন্টের রাজ্যে রাখা। অনুরোধের সাথে ক্লায়েন্ট পুনরায় লগ প্রেরণ করে এবং সার্ভারটি লেনদেনটি পুনরায় করায় এবং

1. লেনদেনটি পিছনে ফিরিয়ে দেয় তবে নতুন লেনদেন পুনরায় লগ সরবরাহ করে (আরও এক ধাপ এগিয়ে)
2. বা অবশেষে লেনদেন সম্পূর্ণ করুন।

তবে সম্ভবত এটি একটি সার্ভার সেশন ভিত্তিক প্রযুক্তি ব্যবহার করা সহজ যা সার্ভারের পাশের লেনদেনগুলিকে সমর্থন করে।

Comments

উক্তিটি উইকিপিডিয়া REST এন্ট্রি থেকে। এটিই আসল উত্স নাকি উইকিপিডিয়া কোথাও থেকে পেয়েছে? ক্লায়েন্টের প্রসঙ্গ কী এবং সার্ভারের প্রসঙ্গে কী বলতে হবে?

— bbsimonbb

Answer 11

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

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

আরও জটিল পরিস্থিতিতে যেমন একাধিক এয়ারলাইনসের টিকিট বুকিং বা মাইক্রো আর্কিটেকচার সম্পর্কে জানেন না।

RESTful পরিষেবাদিতে লেনদেনের পারমাণবিকতা নিয়ে কাজ করার অভিজ্ঞতার সাথে সম্পর্কিত, আমি এই বিষয়ে একটি কাগজ পেয়েছি ।

Answer 12

সাধারণ ক্ষেত্রে (বিতরণযোগ্য সংস্থান ব্যতীত) আপনি লেনদেনটিকে একটি উত্স হিসাবে বিবেচনা করতে পারেন, যেখানে এটি তৈরির কাজটি শেষ লক্ষ্য অর্জন করে।

সুতরাং, মধ্যে স্থানান্তর করতে <url-base>/account/aএবং <url-base>/account/b, আপনি নিম্নলিখিত পোস্ট করতে <url-base>/transfer।

<স্থানান্তর>
    <Url টি-বেস> <থেকে> / অ্যাকাউন্ট / একটি <থেকে />
    <করার> <url টি-বেস> / অ্যাকাউন্ট / খ </ থেকে>
    <পরিমাণ> 50 </ পরিমাণ>
</ স্থানান্তর>

এটি একটি নতুন স্থানান্তর সংস্থান তৈরি করবে এবং স্থানান্তরটির নতুন ইউআরএল ফিরিয়ে দেবে - উদাহরণস্বরূপ <url-base>/transfer/256।

সফল পোস্টের মুহুর্তে, তারপরে, 'রিয়েল' লেনদেনটি সার্ভারে পরিচালিত হয় এবং পরিমাণটি একাউন্ট থেকে সরানো হয় এবং অন্যটিতে যুক্ত হয়।

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

Comments

যদি আপনি "সমস্ত ক্রিয়াকলাপকে এমন পদ্ধতিতে বাক্যবিন্যাস করতে পারেন না যেগুলি বিতরণকৃত লেনদেনের প্রয়োজন হয় না", তবে আপনার সত্যিকার অর্থে দুটি দফার অঙ্গীকারের প্রয়োজন। আরআরএসটি- তে দ্বি-পর্যায়ের প্রতিশ্রুতি বাস্তবায়নের জন্য আমি যে সেরা ধারণাটি খুঁজে পেতে পারি তা হ'ল রেস্ট.ব্লুওক্সেন.ন. /cgi-bin/wiki.pl?TwoPhaseCommit , যা গুরুত্বপূর্ণভাবে ইউআরএল নেমস্পেসকে বিশৃঙ্খলা করে না এবং একটি দুটি পর্বের প্রতিশ্রুতিকে স্তরযুক্ত করার অনুমতি দেয় which পরিষ্কার REST শব্দার্থবিজ্ঞান।

— ফসমাল

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

— জন ওয়াট

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

— ফসমাল

Answer 13

আমার ধারণা আপনি URL টি / টি সংস্থানটিতে TAN অন্তর্ভুক্ত করতে পারেন:

1. আইডি পাওয়ার জন্য পুট / লেনদেন (যেমন "1")
2. [পুট, জিইটি, পোস্ট, যাই হোক না কেন] / ১ / অ্যাকাউন্ট / বব
3. [পুট, জিইটি, পোস্ট, যাই হোক না কেন] / ১ / অ্যাকাউন্ট / বিল
4. আইডি 1 দিয়ে মুছে ফেলুন / লেনদেন করুন

শুধু একটি ধারণা।

Comments

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

— গিলি

ঠিক আছে, / 1 / অ্যাকাউন্ট / বব এবং / অ্যাকাউন্ট / বব কেবল দুটি পৃথক সংস্থান। :) এবং আরই: রাষ্ট্রবিহীন, এটি সূচিত করে যে সংস্থান সর্বদা উপলব্ধ থাকে এবং পূর্ববর্তী অনুরোধের উপর নির্ভর করে না। যেহেতু আপনি লেনদেনের জন্য বলেছেন, হ্যাঁ এটি তেমন নয়। কিন্তু আবার, আপনি লেনদেন চেয়েছিলেন।

— পর্যন্ত

যদি কোনও ক্লায়েন্টকে ইউআরআই একত্রিত করতে হয় তবে আপনার এপিআইটি বিশ্রামের নয়।

— এহেলকে

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

— ম্যাথিয়াস হ্রিনিসাকাক

একটি উপায় বা

— অন্যথায়