ইচ্ছাকৃতভাবে REST স্ট্যান্ডার্ডগুলি ভেঙে এমন একটি স্থাপত্য শিফটকে কীভাবে বর্ণনা করবেন?


37

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

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

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


44
আপনার এপিআই কে সিআরইউডি কলগুলিতে "RESTful" বানানোর খাতিরে সংযুক্ত করা একটি দুর্বল বাণিজ্য is
রবার্ট হার্ভে

38
@ এসবেইনস্কভ পিডারসন: চিরকালের সেরা বন্ধু?
রবার্ট হার্ভে

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

7
@ আআআআআআআআআআআ, প্রায় কোনও পরিষেবা আরআরইএসটির সাথে মানা করার কারণটি হ'ল কেউই আরইএসটি কী তা নিয়ে সিদ্ধান্ত নিতে পারে না। আমি যে চুক্তির একমাত্র পয়েন্ট পেয়েছি তা হ'ল "প্রত্যেকে প্রত্যেকেই এটি ভুল করছে"।
চিহ্নিত করুন

16
- "ইচ্ছে করেই আরএসটি মান ভেঙে এমন একটি স্থাপত্য শিফটকে কীভাবে বর্ণনা করব?" - নিরস্ত করুন । ( একটি
পেশাগত

উত্তর:


49

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

Service oriented architecture

আপনি আপনার সিস্টেমটিকে নতুন করে ডিজাইনের প্রস্তাব দিচ্ছেন যাতে আপনার ব্যবসায়ের নিয়ম এবং আপনার ডেটা একই জায়গায় থাকে। এটি কার্যকরভাবে কোনও পরিষেবার সংজ্ঞা ; উপর Udi, Dahan এর আলাপ দেখতে ফাইন্ডিং পরিষেবা সীমানা

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

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


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

29

REST CRUD নয়। এই "পাল্টা" আরএসটি কী তা মৌলিকভাবে ত্রুটিপূর্ণ বোঝার উপর ভিত্তি করে। আমি আপনার পোস্টে এমন কিছু দেখিনি যা আপনার ইঙ্গিত দেয় যে আপনার পরিবর্তনটি আপনার এপিআইকে আরও কম বা আরামদায়ক করে তুলবে।


6
ওয়েল, না, এটি সিআরইউডি-তে কোনও নিখুঁত ম্যাপিং নয়, তবে এটি সিআরইউডি-র মতো হাঁটতে এবং কথা বলতে এবং গাইতে পারে, কমপক্ষে বেশিরভাগ লোক যেভাবে এটি ব্যাখ্যা করে।
রবার্ট হার্ভে

11
@ রবার্ট হার্ভে আমার মনে হয় যে এটিই (ভুল) বোঝা যা এখানে সমস্যা।
জিমি জেমস

4
@ জিমি জেমস: এটি একটি ব্যাপক ভুল বোঝাবুঝি। বেশিরভাগ লোকেরা এমনকি সুবিধাগুলি কী কী বা কীভাবে সেই সুবিধাগুলি তাদের জন্য প্রযোজ্য হবে তা বুঝতে না পারলে জিনিসগুলিকে "বিশৃঙ্খল" করার জন্য একটি শক্তিশালী ড্রাইভ রয়েছে।
রবার্ট হার্ভে

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

5
@ রবার্টহারভে মঞ্জুর, তবে যতক্ষণ না পর্যাপ্ত লোক রয়েছে যারা এই শব্দটির অপব্যবহারগুলি সংশোধন করতে ইচ্ছুক হবে ততক্ষণ তা ঘটবে না। আমি তোয়ালে ফেলে দিতে প্রস্তুত নই।
জিমি জেমস

24

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

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

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


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

10

অন্যান্য ভাল উত্তর যুক্ত করতে এখানে:

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

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

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

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


3
আরআরইএসটি ডাটাবেস রেকর্ড সম্পর্কে কিছুই বলে না, কতটা ছেড়ে দিন। আমি একটি আরইএসটি পরিষেবা তৈরি করতে পারি যা একটি জল ভালভকে নিয়ন্ত্রণ করে এবং একটি জল ভালভ, জল সরবরাহ এবং ট্যাঙ্ক স্তরের সংস্থানগুলিকে প্রকাশ করে। আপনি যুক্তি দিতে পারেন যে শারীরিক বস্তুগুলি সেগুলি একটি "ডাটাবেস" বুট যা কিছুটা প্রসারিত করে।
কলিন ইয়ং

@ কলিন ইউইং হ্যাঁ, পরিষ্কার করতে সাহায্য করার জন্য আপনাকে ধন্যবাদ।
জিমি জেমস

3

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

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

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

আসুন আপনার গ্রাহক অবজেক্টটি দেখুন।

সমস্যা:

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

সমাধান:

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

আপনার যদি জিইটি / গ্রাহক অবজেক্টগুলির একটি শেষ পয়েন্ট দরকার হয় তবে তা ঠিক। আপনি উভয় থাকতে পারে। কৌশলটি হ'ল এন্ডপয়েন্টগুলি তৈরি করা যা গ্রাহকদের প্রয়োজনের পরিবেশন করে।

সুবিধাদি:

  1. আপনি গ্যারান্টি দিচ্ছেন যে আপনার খারাপ অবস্থা শেষ হবে না
  2. এটি যদি ইউআই ডিভাসগুলিতে অনুরোধ, বৈধতা সম্পর্কিত উদ্বেগ ইত্যাদির ক্রম "জানতে" না হয় তবে এটি আসলে সহজ
  3. এটি কোনও নেটওয়ার্কের অনুরোধের বিলম্বকে হ্রাস করে কোনও এপিআই-এর চ্যাটি নয়
  4. পরিস্থিতিগুলি পরীক্ষা করা এবং ধারণাটি তৈরি করা সহজ (ইউআই থেকে প্রাপ্ত ডেটা টুকরো টুকরো টুকরো টুকরো টুকরো অনুরোধের মধ্যে ছড়িয়ে যায় না, যার মধ্যে কিছু ব্যর্থ হতে পারে)
  5. এটি ব্যবসায়িক যুক্তির আরও ভাল এনক্যাপসুলেশন করতে দেয়
  6. সাধারণত সুরক্ষা সহজ করে তোলে (কারণ ইউআই-তে ব্যবসায় এবং অর্কেস্ট্রেশন যুক্তি ব্যবহারকারীদের দ্বারা পরিবর্তন করা যেতে পারে)
  7. সম্ভবত যুক্তির সদৃশতা হ্রাস পাবে (আপনার একই জাতীয় ডেটাতে অ্যাক্সেস দেয় এমন 2+ এপিআই-এর চেয়ে বেশি আপনার কোনও API এর 2+ গ্রাহক থাকবেন)
  8. এখনও 100% রিস্টফুল

অসুবিধা:

  1. ব্যাকএন্ড ডেভের পক্ষে এটি সম্ভবত আরও কাজ (তবে এটি দীর্ঘকালীন নাও হতে পারে)

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

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

আরও অধ্যয়ন:

চিন্তাভাবনা থেকে প্রাপ্ত এই নিবন্ধটি আমাকে বাস্তবের উদাহরণ হিসাবে ব্যবহারিক জিনিস হিসাবে মডেলিংয়ের ক্রিয়া সম্পর্কে ধারণা পেতে সহায়তা করেছে: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

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


" কারণ তৈরি করা একটি ক্রিয়া এবং REST লঙ্ঘন করবে " - একেবারে সঠিক। অন্য কথায়, এটি তখন " আরপিসি ওভার আরএসসি" চালানোর 47.258.346 তম পন্থা হবে । যা এমন কিছু যা আমি কমপক্ষে "অপ্রাকৃত" হিসাবে চিহ্নিত করব, কারণ এটি RESTful পদ্ধতির অপব্যবহার করে এবং উপস্থাপন করে (তাদের ব্যবহারের ক্ষেত্রে রয়েছে, তবে আরপিসি সেগুলির মধ্যে একটি নয়) এবং অদক্ষ হতে থাকে।
জেনসজি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.