ক্লায়েন্টের পাশে HATEOAS এর সাথে কী লাভ?

Question

যেহেতু আমি বর্তমানে বুঝতে পেরেছি মূলত হেটোঅ্যাস হ'ল প্রতিটি কিছুর প্রতিক্রিয়া লিঙ্কগুলির সাথে একত্রে পরবর্তী পাঠানো সম্পর্কিত তথ্য প্রেরণ করা। একটি সাধারণ উদাহরণ সহজেই ইন্টারনেটে পাওয়া যায়: একটি অ্যাকাউন্ট সংস্থান সহ একটি ব্যাংকিং সিস্টেম। উদাহরণটি কোনও অ্যাকাউন্ট রিসোর্সে জিইটি অনুরোধের পরে এই প্রতিক্রিয়াটি দেখায়

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

ডেটার সাথে একসাথে লিঙ্কগুলি রয়েছে যা পরবর্তী কী করা যায় তা বলে। ভারসাম্য যদি নেতিবাচক হয় আমাদের কাছে

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

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

তবে মুল বক্তব্যটি হ'ল আমরা যখন জাভাস্ক্রিপ্ট সহ এসপিএ বা একটি অ্যান্ড্রয়েড অ্যাপ্লিকেশন বা অন্যান্য অনেক কিছুর মতো একটি ক্লায়েন্ট তৈরি করি তখন আমি দেখতে পাচ্ছি না যে কীভাবে হেটোয়াস প্রাসঙ্গিক হচ্ছে। আমি যা বলতে চাইছি তা হ'ল: আমি যখন জাভাস্ক্রিপ্টে এসপিএ কোড করছি, কোডটি লেখার জন্য অবশ্যই API এ কী করা যেতে পারে তা অবশ্যই আমার জানা উচিত।

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

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

সুতরাং, ক্লায়েন্টদের জন্য কীভাবে হাইটোয়াস গুরুত্বপূর্ণ? কেন আমরা যেভাবেই HATEOAS নিয়ে বিরক্ত হই?

Comments

আপনি ঠিকই বলেছেন, তবে বিষয়টি মূল বিষয় নয়। HATEOAS আপনাকে ক্লায়েন্টের পৃষ্ঠায় থাকা লিঙ্কগুলির জন্য ইউআরআই তৈরি করা থেকে বিরত রাখে।

— জেমস ম্যাকলিউড

Answer 1

আমরা যে অ্যাপটিটি তৈরি করছি সেটি কেবল লিঙ্কগুলিতে নজর দেবে না এবং তারপরে নিজেই সঠিক ইউআই রেন্ডার করবে এবং ডান এজাক্স কল করবে

বস্তুত, এই হল ঠিক কি HATEOAS হবে UI 'তে দেব। যা সম্ভব তা নয় , তবে কখন সম্ভব। HAL এর মতো একটি আনুষ্ঠানিক HATEOAS , যেমন প্রশ্নটি বলেছে, লিঙ্কগুলি দেয় যা কী সম্ভব তা নির্দেশ করে। কিন্তু যখন সেই লিঙ্কগুলি প্রদর্শিত হয় তখন অ্যাপ্লিকেশনের অবস্থার উপর নির্ভর করে। সুতরাং, লিঙ্কগুলি সময়ের সাথে সংস্থানগুলিতে পরিবর্তিত হতে পারে (ইতিমধ্যে সম্পাদিত ক্রিয়াগুলির উপর ভিত্তি করে)।

এটি আমাদের এমন একটি ইউআই তৈরি করতে দেয় যাতে সম্ভাব্য সমস্ত রাজ্য রয়েছে তবে কখন সেই রাজ্যগুলি সক্রিয় হবে তা নিয়ে উদ্বিগ্ন হন না । উদাহরণস্বরূপ, ফর্মটি rel="deposit"রেন্ডার করা ঠিক হয় যখন কানের উপস্থিতি সরাসরি ইউআইকে বলতে পারে make deposit। যা তারপরে ব্যবহারকারীটিকে একটি মান প্রবেশ করতে এবং লিঙ্কটি ব্যবহার করে জমা দেওয়ার অনুমতি দেয়।

Comments

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

— ব্যবহারকারী 1620696

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

— ডেভিন ট্রিওন

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

— Cormac Mulhall

@Nik কটাক্ষপাত করা করতো HAL কিভাবে লিঙ্ক প্রতিক্রিয়া প্রদান করা হয় একটি উদাহরণ জন্য।

— ডেভিন ট্রায়ন

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

— ডেভিন ট্রায়ন

Answer 2

যেহেতু আমি বর্তমানে বুঝতে পেরেছি মূলত হেটোঅ্যাস হ'ল প্রতিটি কিছুর প্রতিক্রিয়া লিঙ্কগুলির সাথে একত্রে পরবর্তী পাঠানো সম্পর্কিত তথ্য প্রেরণ করা

HATEOAS কেবলমাত্র লিঙ্কগুলির চেয়ে অনেক বেশি। এটি অ্যাপ্লিকেশন স্টেটের ইঞ্জিন হিসাবে "হাইপার মিডিয়া"।

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

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

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

এটি "ব্যবহারকারী" অন্য একটি কম্পিউটার প্রোগ্রাম হলেও তা ধরে রাখে। হাইপার মিডিয়া নিজেই নেভিগেশনের প্রসঙ্গ নির্ধারণ করা উচিত।

Comments

এর অর্থ কি এই নয় যে আপনার ব্রাউজার হিসাবে জটিল (এবং বাগ প্রবণ) হিসাবে একটি ক্লায়েন্ট তৈরি করতে হবে? নমনীয়তা প্রায়শই জটিলতার সাথে ব্যয় হিসাবে আসে ...

— আন্দ্রেস এফ।

@AndresF। এর অর্থ এই নয় যে আপনার অবশ্যই এটি করা উচিত বা করা উচিত নয়, এটি যদি আপনি চান বা প্রয়োজন হয় তবে এটি কেবল গতিশীলভাবে করার বিকল্প দেয়।

— পিটারিস

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

— করম্যাক মুলহাল

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

— করম্যাক মুলহাল

@ নিক তাই এমন পরিস্থিতিতে আপনার কাছে এমন একটি সার্ভার রয়েছে যা মূল বিষয়বস্তুর ধরণটি (ব্যক্তি ভি 1 বলুন) এবং নতুন সামগ্রীর ধরণ (ব্যক্তি ভি 2) বোঝে। ক্লায়েন্ট কেবল ব্যক্তি ভি 1 বোঝে। ক্লায়েন্ট সার্ভারকে HTTP- র মধ্যে গ্রহণযোগ্য শিরোনামের মাধ্যমে কী কী ধরণের সামগ্রী বোঝে তা জানায়। বিষয়বস্তু আলোচনার সাহায্যে সার্ভার নির্ধারণ করে যে এটি ক্লায়েন্টকে কী সমর্থন করবে তা প্রেরণ করবে কি না, সেই ক্ষেত্রে এটি বিষয়বস্তু ব্যক্তির ভি 1 ব্যবহার করে সংস্থানটি ফিরিয়ে দেবে। এখন আপনি কেবল এই পুরানো সামগ্রী প্রকারটি সমর্থন করা বন্ধ করতে এবং ক্লায়েন্টকে 406 ত্রুটি পাঠাতে পারেন। আপনি যতটা পারেন তত চেষ্টা এবং সমর্থন করা ভাল।

— করম্যাক মুলহাল

Answer 3

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

ডায়নামিক লেআউটটি ব্যবহার করা বেশ সহজ বিটিডব্লিউ হতে পারে:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

এটি আপনাকে আপনার ক্লায়েন্ট কোডে যেমন সংরক্ষণ করে:

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

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

Comments

কিছুটা শক্তিশালী উদাহরণ হিসাবে, ক্লায়েন্টকে প্রতিটি অ্যাকাউন্টে সীমাটি কী তা বলা উচিত না করে, ব্যাংক তাদের অ্যাকাউন্টগুলিতে ভেরিয়েবল ওভারড্রাফ্ট সীমা সরবরাহ করতে পারে।

— বার্ট ভ্যান ইনজেন শেহেনো

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

— লুক ফ্রাঙ্কেন

তবে সাধারণত গ্রাহককে জানতে হবে কেন এটি প্রত্যাহার করতে পারে না, তাই আমাদের এখনও ক্লায়েন্টের সাথে পৃথক ক্ষেত্রে একটি ENUM বা স্ট্রিং প্রেরণ করতে হবে reason। এবং যদি আমাদের এখনও এটির প্রয়োজন canWithdrawহয় তবে ক্রিয়াটির লিঙ্কের পরিবর্তে কেন তাকে অন্য বুলিয়ান ক্ষেত্রটি প্রেরণ করবেন না ? আর একটি সুবিধা হ'ল ক্লায়েন্টের স্পর্শ না করে কোনও ক্রিয়াকলাপের URL পরিবর্তন করার ক্ষমতা। তবে .. ইউআরএল পরিবর্তন করার কী কারণ? বেশিরভাগ ক্ষেত্রে এটি অর্থগত বা পরামিতিগুলিতে বা অনুরোধ / প্রতিক্রিয়া আকৃতি ইত্যাদিতেও কিছু পরিবর্তন হয় So সুতরাং আমাদের যাইহোক ক্লায়েন্টটি পরিবর্তন করা দরকার। সুতরাং, আমি এখনও এটি পাই না - হেটোয়াসের মূল বিষয় কী।

— রুসলান স্টেলমাচেঙ্কো