কনভেনশন কেন বলে যে ডিবি টেবিলের নামগুলি একক হওয়া উচিত তবে RESTful সংস্থানগুলি বহুবচন হওয়া উচিত?

এটি একটি সুন্দর প্রতিষ্ঠিত কনভেনশন যে এসকিউএল-তে ডেটাবেস টেবিলের নামগুলি একবচন হওয়া উচিত। SELECT * FROM user;দেখুন এই প্রশ্নের ও আলোচনা ।

এটি একটি দুর্দান্ত প্রতিষ্ঠিত কনভেনশনও যে RESTful এপিআই সংস্থানগুলির নাম বহুবচন হওয়া উচিত। GET /users/123এবং POST /usersদেখুন এই এক ।

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

বহুবচনকরণের পার্থক্য কীভাবে ন্যায়সঙ্গত হতে পারে যখন ধারণাগতভাবে, আরএসটি এপিআই এবং এসকিউএল একই জিনিস করছে?

— smitelli
সূত্র

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

— এরিক কিং

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

— গ্র্যান্ডমাস্টারবি

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

— তুলসিন কর্ডোভা

@ user61852 এমন লোক রয়েছে যারা এটি কনভেনশন করে ব্যবহার করতে পারেন। তবে এটি কোনওভাবেই এই প্রশ্নে উপস্থাপিত হিসাবে একটি বিস্তৃতভাবে অনুসরণ করা শিল্প সম্মেলন নয়, বলুন, এটি উট কেস বা মার্কডাউন।

— গ্র্যান্ডমাস্টারবি

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

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

উত্তর:

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

সুতরাং এখানে আনপ্যাক করার বিষয়টি হ'ল ধারণাগত বোঝা যা কোনও এপিআই সরাসরি ডাটাবেসে মানচিত্র করে। আমরা এটিকে কমপক্ষে ২০০৯ সাল পর্যন্ত একটি এন্টি-প্যাটার্ন হিসাবে বর্ণনা করতে পারি ।

প্রধান কারণ এটি খারাপ? কোড "কীভাবে এই অপারেশনটি আমার ডেটাগুলিকে প্রভাবিত করে?" ক্লায়েন্ট কোড হয়ে যায় ।

এটিতে এপিআইতে বেশ কয়েকটি ভয়ঙ্কর প্রভাব রয়েছে। (সম্পূর্ণ তালিকা নয়)

এটি API এর সাথে সংহতকরণকে শক্ত করে তোলে

আমি এই জাতীয় কিছু হিসাবে নথিভুক্ত নতুন ব্যবহারকারী তৈরি করার পদক্ষেপগুলি কল্পনা করি:

POST /users { .. }
POST /usersettings { .. } কিছু ডিফল্ট মান সহ
POST /confirmemails { .. }

তবে আপনি কীভাবে পদক্ষেপ # 2 এর ব্যর্থতা পরিচালনা করবেন? আপনার API এর অন্যান্য ক্লায়েন্টদের কাছে এই একই হ্যান্ডলিং লজিকটি কপি-পাস্তা কতবার হয়েছে?

ক্লায়েন্ট থেকে একক ক্রিয়াকলাপ হিসাবে আরম্ভ করার সময় এই ডেটা অপারেশনগুলি প্রায়শই সার্ভারের দিকে ক্রমগুলি সহজ হয়। যেমন POST /newusersetup। ডিবিএগুলি এটি একটি সঞ্চিত প্রক্রিয়া হিসাবে স্বীকৃতি দিতে পারে তবে এপিআই অপারেশনটির প্রভাব কেবলমাত্র ডাটাবেসের বাইরেও থাকতে পারে।

এপিআই সুরক্ষিত হতাশার একটি কালো গর্ত হয়ে ওঠে

ধরা যাক আপনাকে দুটি ব্যবহারকারীর অ্যাকাউন্ট একত্রীকরণ করতে হবে।

GET /users/1
PUT /users/2 { .. }
DELETE /users/1

আপনি ব্যবহারকারীকে মোছার অনুমতি না দেওয়ার সাথে সাথে মার্জ বৈশিষ্ট্যটির অনুমতি দেওয়ার জন্য কোনও ব্যবহারকারীর অনুমতি সেটআপ করতে যাচ্ছেন? কোনও ব্যবহারকারীকে মুছে ফেলা কি এমনকি DELETE /users/1যখন /usersettingsউপস্থিত থাকে তখনও ন্যায্য প্রতিনিধিত্ব করে ?

এপিআই অপারেশনগুলিকে উচ্চতর- (ডাটাবেসের তুলনায়) -মানের অপারেশন হিসাবে দেখা উচিত যা সিস্টেমে একাধিক পরিবর্তন হতে পারে।

রক্ষণাবেক্ষণ শক্ত হয়ে যায়

... কারণ আপনার ক্লায়েন্টরা আপনার ডাটাবেস কাঠামোর উপর নির্ভর করে।

এই দৃশ্যের সাথে আমার অভিজ্ঞতার ভিত্তিতে:

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

আপনার ক্লায়েন্টদের কাছে সরাসরি আপনার ডাটাবেস কাঠামোটি উন্মোচন করবেন না ... বিশেষত ক্লায়েন্টগুলির উপরে আপনার উন্নয়ন নিয়ন্ত্রণ নেই। কেবল বৈধ ক্রিয়াকলাপগুলিতে ক্লায়েন্টকে সংকুচিত করতে একটি API ব্যবহার করুন।

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

— ক্যাসে স্পিকারম্যান
সূত্র

একটি পৃথক প্রশ্নের উত্তর। ওপি এপিআই এবং ডিবি সত্তাগুলির সরাসরি সংযুক্তি বোঝায় না, উভয় প্রসঙ্গে কেবল কিছু সত্তার উপস্থিতি।

— বাসিলিভস

আপনার যে প্রশ্নটি জিজ্ঞাসা করা হচ্ছে তার উত্তর নির্দ্বিধায় ফেলুন।

— Kasey Speakman

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

— আলুয়ান হাদাদ

এর মধ্যে অনেকগুলি কারণ রয়েছে যা আমি স্প্রিং ডেটা রেস্ট ব্যবহার বন্ধ করে দিয়েছি।

— সেবাস্তিয়ান ভ্যান ডেন ব্রুক

REST এপিআই এবং এসকিউএল "একই জিনিস করছেন না"

ওপি জিজ্ঞাসা করেছে:

বহুবচনকরণের পার্থক্য কীভাবে ন্যায়সঙ্গত হতে পারে যখন ধারণাগতভাবে, আরএসটি এপিআই এবং এসকিউএল একই জিনিস করছে?

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

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

— fearless_fool
সূত্র