কেন একটি ছোট ফিক্সড ভোকাবুলারিটিকে RESTful পরিষেবাদির সুবিধা হিসাবে দেখা হয়?


13

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

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

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

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

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

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

প্রতিফলন

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


ব্যবহারকারীদের আপনার প্রশ্ন এবং উত্তরগুলি দ্রুত পার্স করতে সহায়তা করতে আপনি আপনার "আপডেটগুলি" পৃথক উত্তর হিসাবে যুক্ত করার বিষয়টি বিবেচনা করতে পারেন (বিশেষত "অন্য একটি আপডেট" বিভাগ)। এটি উত্সাহিত করা হয়েছে: blog.stackoverflow.com/2011/07/…
জোহান

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

উত্তর:


9

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

আরআরএসটির "ক্রিয়াপদগুলি" আপনার পদ্ধতিগুলি গিটার, সেটার (মুছে ফেলা; ডিলেটর; ধরণের সেটটার হিসাবে বিবেচনা করা যেতে পারে) এবং অন্যান্যতে শ্রেণিবদ্ধ করার মতো। এবং গেটর এবং সেটটার দিয়ে সবকিছু করার চেষ্টা করছি। এর কারণ:

  1. যোগাযোগ ব্যর্থতার পক্ষে সহজ শব্দার্থক, যেহেতু গেটার এবং সেটার উভয়ই আদর্শবান। দু'বার রিসোর্স পাওয়ার কোনও অতিরিক্ত প্রভাব নেই এবং এটি এর আগে থেকে যে মান রয়েছে তা সেট করে না।
  2. কিছু শব্দার্থবিজ্ঞানের সংজ্ঞা দেওয়া হচ্ছে যা সম্ভবত নির্দিষ্ট ইন্টারফেসটি বুঝতে পারে না এমন প্রক্সি ক্যাচিং দ্বারা ব্যবহার করা যেতে পারে। যাত্রীরা ক্যাশে হয় এবং সেটটাররা ক্যাশে অবৈধ করতে পরিচিত।

এইচটিটিপি প্রথম থেকেই নকশা করা হয়েছিল উভয় ক্যাশে এবং ত্রুটি-সহনশীলতা উভয়ের কথা মাথায় রেখে, সুতরাং এই দুটি পয়েন্ট এটি চারটি মূল পদ্ধতির দিকে নিয়ে যায়:

  • GETএকটি প্রাপ্তি হয়। এটি ধরে নেওয়া হয়েছে যে সার্ভারের স্থিতিটি পরিবর্তন না করা এবং সমাপ্তি এবং পুনরায়করণ নীতি নির্দিষ্ট করার সম্ভাবনা সহ প্রতিবার একই মানটি ফেরত দেওয়া নয়।
  • PUTএবং DELETEসেটার এবং মুছে ফেলা হয় (= নিল সাথে সেটার)। এগুলি সাধারণত সাধারণ ওয়েবের প্রসঙ্গে ব্যবহৃত হয় না, তবে বিশ্রামের জন্য তা উপলব্ধি করে।
  • POST একটি সাধারণ "আহবান" রান্নাঘর সিঙ্ক যার জন্য ক্যাশে কিছুই অনুমান করতে পারে না।

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

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


2

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

আপনি যদি চারটি আরইএসটি ক্রিয়াটি লক্ষ্য করেন তবে সেগুলি মুলত সিআরইউডি অপারেশনগুলিতে ম্যাপ করা যায়, মূলত আপনাকে আপনার সংস্থানগুলি দিয়ে যা খুশি তা করতে দেয়। এটাই -

পোস্ট - সংস্থান তৈরি করুন

GET - রিসোর্সটি পড়ুন

পুট - সংস্থানটি আপডেট করুন

মুছুন - সংস্থানটি মুছুন Delete

আপনার আর কি দরকার?


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

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

প্যাচিংয়ের সংস্থানগুলিও বেশ দুর্দান্ত।
ওয়াট বার্নেট

2

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

এবং অবশ্যই এটি প্রতিবিম্বিত করার জন্য একটি নির্দিষ্ট শব্দভাণ্ডারের জন্য রাউটিং / প্রক্সিংয়ের পক্ষে সহায়ক।


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

  • কারণ যখন ইতিমধ্যে সংজ্ঞায়িত করা হয় তখন পদ্ধতির নামগুলি সম্পর্কে মানদণ্ডের প্রয়োজন হয় না।

  • কারণ কোডের মূল লক্ষ্যটি এ জাতীয় অতিরিক্ত অনুবাদ ছাড়াই পঠনযোগ্য।

  • কারণ এটি 'কখন' শনাক্তকরণে উত্সাহ দেয় এবং এইডস দেয় যাতে অন্য শ্রেণি ভাঙা উচিত।

  • আপনি যখন কোডটি গ্রহণ করেন এটি যুক্তিসঙ্গত এবং আসলে কী এবং এটি কীভাবে এটি আরও দ্রুত করে তা বোঝা সম্ভব।

  • এটি একটি সাধারণ শব্দভাণ্ডার সরবরাহ করে এবং বিমূর্ততার স্তরটি সরবরাহ করে যাতে আপনি অন্যান্য বিবরণগুলিতে ফোকাস করতে পারেন এবং নিদর্শনগুলি দেখতে পারেন।

  • এটি প্রচলিত কোড হিসাবে সহজেই বাগগুলি সন্ধান করা সহজ করে তোলে এবং পদ্ধতিগুলি সহজেই পরীক্ষা করা যায়।

  • আপনি যখন একাধিক 'স্তর' এর সাথে কাজ করছেন যেমন ওয়েব ডেভলপমেন্টে কারওর মতো কাজ করে, কোন ডিফল্ট নামগুলি ডিবাগিংয়ের জন্য কোন ক্রিয়াকলাপগুলির সাথে খুব কার্যকর তা কী url গুলির সাথে মেলে তা জেনে।

সামগ্রিকভাবে আপনার 'সর্বদা' প্রয়োজন হয় না, তবে বেশিরভাগ মানকগুলির মতো এটি ব্যবহার করার চেষ্টা করার লক্ষ্যটি বুদ্ধিমান করে তোলে!


ক্রমে সম্বোধন করা 1) সুতরাং একজন প্রোগ্রামার কয়েকশো সংখ্যার সংস্থান না করে যদি প্রত্যাশা করে? আমরা যে লাইব্রেরি ব্যবহার করি সেগুলিতে আমরা ইতিমধ্যে পদ্ধতিগুলি অনুমান করি। 2) সুতরাং আমাদের কি পদ্ধতির নামের জন্য মানক প্রয়োজন তবে সংস্থানীয় নামগুলির জন্য নয়? আমি এই যুক্তি বুঝতে ব্যর্থ। 3) অনুবাদ দ্বারা আপনি কী বোঝেন তা নিশ্চিত নয়। আপনি যদি আমাকে কোনও উত্স বিদ্যমান বলে থাকেন তবে আমার এটি বুঝতে হবে। যদি আমি আপনাকে একটি পদ্ধতি বিদ্যমান বলি তবে আপনাকে এটি বুঝতে হবে। কেবলমাত্র আমি যা যত্ন করি তা হল আমার কোন ক্রিয়াকলাপের তার পার্শ্ব প্রতিক্রিয়া হবে 4) আপনি কি প্রসারিত করতে পারেন
ম্যাট এস্ক

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

ম্যাট আপনি কিছুটা বিতর্কিত বলে মনে করছেন তবে আমি এটি বলব যে 2) আমি বলিনি যে সংস্থার মানদণ্ডের প্রয়োজন হবে না 3) আপনাকে 'আপডেট' বা 'নতুন' বা তৈরির মতো কোনও পদ্ধতি বুঝতে হবে না কারণ আপনি ঠিক জানেন know যারা মান অনুযায়ী কি। তবে 'MsgToPrimary' সম্পর্কে কী তা কী করে? একটি চিত্র তৈরি করুন? একটি স্ট্যাটাস আপডেট করবেন? একটি ইমেইল পাঠাও? )) হ্যাঁ বেশিরভাগ এপিআই এর দ্বারা উপকৃত হতে পারে এবং অনেকেই পারেন। আমি ধারণার মানক মান এবং কনভেনশনগুলি সহায়ক বলে মনে করার চেষ্টা করব এবং আমি দেখতে পাচ্ছি যে আপনার আপডেটগুলি এটি প্রদর্শিত হচ্ছে।
মাইকেল ডুরান্ট

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

1

বিকল্পটি হ'ল ভয়ঙ্কর কিছু: ডাব্লুএসডিএল (ওরফে ওয়েব সার্ভিস সংজ্ঞা ভাষা), যা প্রোগ্রামিটিক্যালি (কিছুটা) নির্বিচারে এপিআইএস বর্ণনা করার একটি (আনাড়ি) উপায় (

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

একটি পডকাস্ট রয়েছে যাতে স্টেফান তিলকভ বিশ্রামের সুন্দরভাবে ব্যাখ্যা করে


1

হ্যাঁ একটি বিশ্রাম এপিআইয়ের ক্রিয়াগুলির একটি নির্দিষ্ট সেট রয়েছে তবে এটি সীমাবদ্ধ থাকতে হবে না (বা জেট, পোস্ট, পুট, ডিলেট অন্তর্ভুক্ত)। আমি জিইটি, পোষ্ট, পুট, ডিএলটিই কে ডিআরইএসটি এর ডিফল্ট বাস্তবায়ন হিসাবে দেখব যা সেখানকার সমস্ত সিস্টেমের 80% এর জন্য কাজ করে।

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

কিশোর সামাজিক নেটওয়ার্ক, পিকজো ডটকম (এটি শান্তিতে বিশ্রামে থাকতে পারে) একটি বর্ধিত REST এপিআই বৈশিষ্ট্যযুক্ত (উপরে বর্ণিত ক্রিয়াগুলি সহ) যা 7 টি ভিন্ন ভাষায় প্রয়োগ করা হয়েছিল!


0

সরল ভাল।

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

অবজেক্ট.ফু () সব ঠিক আছে তবে এটি কী করে? এটা কি ফিরছে? এটি কি বস্তুর অবস্থা বা এর কোনও নির্ভরতা পরিবর্তন করছে? আপনি কি এটিকে দু'বার কল করে একই ফলাফল পেতে পারেন বা এটি আপনাকে দুটি পৃথক মান দিতে চলেছে? যদি আপনারও অবজেক্ট.বার () থাকে তবে তাদের কি একটি নির্দিষ্ট ক্রমে ডাকা দরকার?

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

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