রিস্ট ইউআরআই কনভেনশন - এটি তৈরি করার সময় সংস্থানটির একক বা বহুবচন নাম

Question

আমি রেস্টে নতুন এবং আমি পর্যবেক্ষণ করেছি যে কয়েকটি রেস্ট্রুল সার্ভিসে তারা আপডেট / প্রাপ্ত / মোছা এবং তৈরি করতে বিভিন্ন সংস্থান ইউআরআই ব্যবহার করে। যেমন

• / উত্স (একবচন) কিছু জায়গায় POST পদ্ধতি (বহুবচন পর্যবেক্ষণ) দিয়ে / ব্যবহার করে সংস্থান তৈরি করুন
• আপডেট - PUT পদ্ধতিতে / সংস্থান / 123 ব্যবহার করে
• পান - জিইটি পদ্ধতিতে / সংস্থান / 123 ব্যবহার করুন

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

Comments

এই বিষয় অনুসরণ করে, আমি একটি নিবন্ধে বিখ্যাত REST এপিআইয়ের কয়েকটি উদাহরণ সংগ্রহ করেছি: inmensosofa.blogspot.com/2011/10/… ।

— jjmontes

নীচের সমস্ত উত্তর পড়ার পরে আমি এই উপসংহারে পৌঁছেছি: সর্বদা একক ব্যবহার করুন কারণ (ক) এটি ধারাবাহিক, (খ) এটি একক শ্রেণীর এবং টেবিলের নামগুলিতে সরাসরি মানচিত্র করে, (গ) কিছু বহুবচন বিশেষ্যটি ইংরেজিতে অনিয়মিত (অনির্দেশ্য)

— উইল শেপার্ড

একক টেবিলের নামকরণের সম্মেলনের লিঙ্কের জন্য এই উত্তরটি দেখুন , এবং আরও একটি নিবন্ধ রয়েছে যা এই সঠিক সমস্যার উল্লেখ করে বিশ্রাম এপিএল বিকাশকারীদের দ্বিধাদান

— উইল শেপার্ড

Answer 1

ব্যবহারের ভিত্তিটি /resourcesহ'ল এটি "সমস্ত" সংস্থানকে উপস্থাপন করছে। আপনি যদি এটি করেন তবে আপনি GET /resourcesসম্ভবত পুরো সংগ্রহটি ফিরে আসবেন। পোস্ট করে /resources, আপনি সংগ্রহে যোগ করছেন।

তবে স্বতন্ত্র সংস্থানগুলি / সংস্থানগুলিতে উপলব্ধ। আপনি যদি এটি করেন তবে আপনি GET /resourceসম্ভবত ত্রুটি করবেন, কারণ এই অনুরোধটি কোনও অর্থ দেয় না, যেখানে /resource/123নিখুঁত ধারণা তৈরি করে।

এর /resourceপরিবর্তে ব্যবহার /resourcesকরা আপনি কীভাবে এটির অনুরূপ, যদি আপনি কাজ করেন, বলুন, একটি ফাইল সিস্টেম এবং ফাইলগুলির সংকলন এবং এটির মধ্যে /resourceপৃথক 123, ডিরেক্টরিগুলির সাথে "ডিরেক্টরি" হয় 456।

কোনওভাবেই সঠিক বা ভুল নয়, আপনি যা পছন্দ করেন তা নিয়ে যান।

Comments

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

— দিমিত্রি গনচর

ডিফাক্টো কনভেনশন বেশিরভাগ লোক এবং এপিআই এর বাইরে নেওয়া এটিকে সর্বদা বহুবচন রেখে চলেছে। আইডিগুলি একটি সংস্থান কার / আইডি নির্দিষ্ট করে

— পজিটিভগুই

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

— PositiveGuy

@ টমাসজপ্লাসকিউইজ আপনি সম্পূর্ণরূপে ঠিক বলেছেন যে ক্লায়েন্টদের যত্ন নেই। সফ্টওয়্যার বিকাশকারী হিসাবে আমাদের যত্ন নেওয়া উচিত - এবং এর জন্য আমি ডব্লিউটিএফ এর মন্তব্যে একমত যে সম্মেলন সম্পর্কে গঠনমূলক বিতর্ক মূল্যবান।

— ট্র্যাভিস ডি

সুতরাং কেউ কি কেবল একটি শব্দের উত্তর দিতে পারে এবং তা গ্রহণ করতে পারে তাই আমাকে এই সমস্তটি (আবার) পড়তে হবে না।

— বেন জর্জ

Answer 2

আমার পক্ষে এমন একটি স্কিমা থাকা ভাল যা আপনি সরাসরি কোডে মানচিত্র করতে পারেন (স্বয়ংক্রিয়ভাবে সহজ), মূলত কারণ কোডটি উভয় প্রান্তে হতে চলেছে।

GET  /orders          <---> orders 
POST /orders          <---> orders.push(data)
GET  /orders/1        <---> orders[1]
PUT  /orders/1        <---> orders[1] = data
GET  /orders/1/lines  <---> orders[1].lines
POST /orders/1/lines  <---> orders[1].lines.push(data) 

Comments

এর অসুবিধা বা স্বাচ্ছন্দ্য হেটোসকে সম্মান না করার কারণে। এটি বহুবচন বা একবচন বা অন্য কিছু কিনা তা বিবেচনা করা উচিত নয়। আপনার সার্ভার থেকে প্রেরিত uri কে সম্মান করা উচিত এবং ক্লায়েন্টের উপর আপনার uri "বিল্ড আপ" করা উচিত নয়। তারপরে আপনার কোডের জন্য আপনাকে 0 ম্যাপিং করতে হবে।

— রিচার্ড

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

এটি আমার মতে আরও ভাল উত্তর। বাদে আমি সবসময় বহুবচনের পরিবর্তে একক ব্যবহার করতে পছন্দ করি। User.getList (), User.getById, User.delete ইত্যাদি

— পূর্ব সন্ন্যাস

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

— ডেলোস

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

— আন্দ্রে সি। অ্যান্ডারসন

Answer 3

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

Comments

আমি যতটা উদ্বিগ্ন এটিই সেরা উত্তর। আমি প্রশংসা করি যে এপিআই ডিজাইনাররা "রিসোর্স # 123" বলার ভাষাগত সঠিকতা পছন্দ করেন তবে এপিআইর ক্লায়েন্টদের লেখার পাশাপাশি সহায়তার ডকুমেন্টেশনগুলির অতিরিক্ত কোডিং ঝামেলা রয়েছে। (জিইটি / এপিআই / লোক বনাম জিইটি / এপিআই / ব্যক্তি / 123? ইউউউচ ....) .... এটি "রিসোর্স পান # 123" এর মতো চিন্তা না করে বরং আপনার মাথায় বাক্যটি "সম্পদ সংগ্রহ থেকে পান যে" মিল # 123 "।

— ওয়ারেন রুমাক

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

— এরিক

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

— জান দেইনহার্ড

ক্লায়েন্টদের বোধগম্যতার সাথে এর কোনও যোগসূত্র নেই। এটি বিভিন্ন ইউআরএল সহ বিভিন্ন জিনিসকে সম্বোধন করার বিষয়ে। এবং বিরোধে না পড়ে সমস্ত এইচটিটিপি পদ্ধতিতে সাড়া দিতে সক্ষম। আপনার কাছে এমন একটি সংস্থান থাকতে পারে যা আইটেমের সংগ্রহ এবং একটি সংস্থান যা কোনও আইটেমকেই উপস্থাপন করে। বয়ে গেছে আমার সংগ্রহের রিসোর্স হতে পারে example.org/166316e2-e1and যে সংগ্রহে একটি বিশেষ আইটেমটি example.org/20d68348-ccc-001c4200de । ক্লায়েন্টের ইউআরএলগুলি তৈরি করা উচিত নয় (এটি স্পষ্টভাবে স্কেল করে না, এটি বিশ্রামযোগ্য নয় এবং এটির জন্য লিঙ্কের সম্পর্ক সম্পর্কিত ধরণেরগুলি রয়েছে)।

— এরিক

আপনি যদি নির্বিচারে URL গুলোকে সুন্দর মনে না করেন তবে বহুগুণ নাম এবং একটি একক নাম সহ একটি স্বতন্ত্র আইটেম সহ সংগ্রহের সংস্থান সনাক্ত করতে দ্বিধা বোধ করবেন। যদি আপনি ইংরাজী ইউআরএল পছন্দ করেন না এবং আপনার প্রাকৃতিক ভাষাটি সিঙ্গুলার / বহুবচন স্বরলিপিটির সেই পদ্ধতিটিকে সমর্থন করে না তবে এটি আপনার পছন্দের ভাষায় এটি সংজ্ঞায়িত করতে অন্য কিছু ব্যবহার করে আমি মনে করি যে সমস্ত ভাষাগুলি আপনাকে কিছুটা আলাদা করতে সক্ষম করে দেয় / / সংগ্রহ-অফ- bla / 2321 'বনাম' bla / 61 'লিখিতভাবে। GET / PUT / DELETE / POST / PATCH এবং অন্যদের প্রেরণ করার সময় এবং এই দুটি পৃথক সংস্থানগুলির প্রতিটি সম্পূর্ণ ভিন্ন ফলাফলের প্রতিনিধিত্ব করে।

— এরিক

Answer 4

বহুবচন

• সরল - সমস্ত url একই উপসর্গ দিয়ে শুরু হয়
• লজিকাল - orders/আদেশের একটি সূচক তালিকা পায়।
• স্ট্যান্ডার্ড - সরকারী এবং বেসরকারী এপিআইয়ের সিংহভাগ সংখ্যার পরে সর্বাধিক বিস্তৃত স্ট্যান্ডার্ড ।

উদাহরণ স্বরূপ:

GET /resources - রিসোর্স আইটেমগুলির একটি তালিকা প্রদান করে

POST /resources - এক বা একাধিক রিসোর্স আইটেম তৈরি করে

PUT /resources - এক বা একাধিক সংস্থানীয় আইটেম আপডেট করে

PATCH /resources - এক বা একাধিক সংস্থানীয় আইটেম আংশিকভাবে আপডেট হয়

DELETE /resources - সমস্ত উত্স আইটেম মুছে ফেলা

এবং একক সংস্থান আইটেমের জন্য:

GET /resources/:id- :idপ্যারামিটারের ভিত্তিতে একটি নির্দিষ্ট সংস্থান আইটেম প্রদান করে

POST /resources/:id - নির্দিষ্ট আইডি সহ একটি সংস্থান আইটেম তৈরি করে (বৈধকরণ প্রয়োজন)

PUT /resources/:id - একটি নির্দিষ্ট সংস্থান আইটেম আপডেট

PATCH /resources/:id - একটি নির্দিষ্ট সংস্থান আইটেম আংশিকভাবে আপডেট

DELETE /resources/:id - একটি নির্দিষ্ট সংস্থান আইটেম মুছে ফেলা হয়

এককালের সমর্থকদের কাছে এটিকে এভাবে ভাবুন: আপনি কি কাউকে তার কাছে জিজ্ঞাসা করে একটি orderজিনিস, বা জিনিসের একটি তালিকা আশা করবেন? আপনি কেন টাইপ করার সময় কেন কোনও পরিষেবা প্রত্যাশা করবেন /order?

Comments

একবচন : যদি আপনার সিস্টেমের অংশটি কেবল একটি অবজেক্ট (0-1, বিদ্যমান বা না থাকে) উদাহরণস্বরূপ ব্যবহারকারী / 1 / অবতার আপনি এই একক বস্তুর (যেমন অবতার) লেবেলের জন্য একক রূপ ব্যবহার করতে পারেন - আরও বিশদ উদাহরণ এখানে: স্ট্যাকওভারফ্লো .com / a / 38296217/860099 ।

— বিটিডাব্লু

ক্লাস এবং টেবিলের নামগুলির ম্যাপিং সম্পর্কে কী, যা একক হওয়া উচিত? ( অন্যান্য উত্তর দেখুন )

— উইল শেপার্ড

@ উইলশেপার্ড - শ্রেণীর নামগুলি একক আকারে সেরা এবং টেবিলের নামগুলি বহুবচন আকারে সেরা। উদাহরণস্বরূপ Orderকোনও শ্রেণীর জন্য একটি ভাল নাম যা এক ক্রমের সাথে সম্পর্কিত পদগুলির একক উদাহরণগুলির সাথে কাজ করে। OrderListএমন এক শ্রেণীর নাম যা একাধিক Orderউদাহরণের সাথে কাজ করে । Orders Tableঅনেক অর্ডার একটি ডাটাবেস টেবিলের জন্য একটি ভাল নাম।

— এরিক নডসন

আমি জিইটি / অর্ডার করতে চাই তবে আমি কেবল

— 1/1

@ জিম-স্মিথ তাহলে আপনি জিইটি / ব্যবহারকারী / 1 এর সাথে ব্যবহারকারী সংগ্রহ থেকে / 1 টি অনুরোধ করবেন না কেন?

— রোহমার

Answer 5

একক

সুবিধা জিনিসের অনিয়মিত বহুবচন নাম থাকতে পারে। কখনও কখনও তাদের একটি নেই। তবে একক নাম সর্বদা থাকে।

উদাহরণস্বরূপ গ্রাহক অ্যাড্রেসগুলির উপরে গ্রাহক অ্যাড্রেস

এই সম্পর্কিত সম্পদ বিবেচনা করুন।

এটি এর /order/12/orderdetail/12চেয়ে বেশি পঠনযোগ্য এবং যৌক্তিক/orders/12/orderdetails/4 ।

ডাটাবেস সারণি

একটি সংস্থান ডেটাবেস টেবিলের মতো একটি সত্তাকে প্রতিনিধিত্ব করে। এটির একটি যৌক্তিক নাম থাকতে হবে have উত্তর এখানেটেবিলের নামের উপর ।

ক্লাস ম্যাপিং

ক্লাস সবসময় একবচন হয়। ওআরএম সরঞ্জামগুলি শ্রেণীর নামের মতো একই নামযুক্ত সারণী তৈরি করে। যত বেশি বেশি সরঞ্জাম ব্যবহৃত হচ্ছে, একক নামগুলি একটি মান হয়ে উঠছে।

একটি REST API বিকাশকারীদের দ্বিধাদান সম্পর্কে আরও পড়ুন

Comments

একক নাম সবসময় থাকে /clothe/12/trouser/34 :)

— গার্ট আর্নল্ড

@ জার্টআরনল্ড শব্দটি clotheএকটি ক্রিয়াপদ। বিশ্রামের এপিআইগুলি সাধারণত সংস্থানগুলিতে কথা বলে এবং ক্রিয়াগুলি বর্ণনা করার সময় ক্রিয়াগুলি ব্যবহার করে ou একবচন রূপটি cloutতবে প্রত্নতাত্ত্বিক এবং সম্ভবত এটি আরও উপযুক্তভাবে প্রতিস্থাপিত হবে garment।

— স্টিভ বুজনস

@ স্টিভ বুজনা এবং ট্রাউজার্স এবং সানগ্লাসের জন্য?

— Koray Tugay

Answer 6

যেখানে সর্বাধিক প্রচলিত অনুশীলনটি হচ্ছে RESTful apis যেখানে বহুবচনের ব্যবহার হয় যেমন /api/resources/123, সেখানে একটি বিশেষ ক্ষেত্রে আমি বহুবচনের নামের চেয়ে একক নাম ব্যবহার করাকে বেশি উপযুক্ত / ভাবপূর্ণ মনে করি। এটি একে অপরের সম্পর্কের ক্ষেত্রে। বিশেষত যদি লক্ষ্য আইটেমটি একটি মান অবজেক্ট হয় (ডোমেন-চালিত-নকশার দৃষ্টান্তে)।

আসুন আমরা ধরে নিই যে প্রতিটি সংস্থার একটি-এক-একটি রয়েছে accessLogযা মান অবজেক্ট হিসাবে মডেল করা যেতে পারে অর্থাৎ কোনও সত্তা নয় তাই কোনও আইডি নয়। এটি হিসাবে প্রকাশ করা যেতে পারে /api/resources/123/accessLog। সাধারণ ক্রিয়াকলাপগুলি (পোষ্ট, পুট, মুছে ফেলুন, জিইটি) যথাযথভাবে অভিপ্রায়টি প্রকাশ করবে এবং এই সত্য যে সম্পর্কটি সত্যই একে অপরের সাথে সম্পর্কযুক্ত।

Comments

ভাল চেষ্টা. তবে এটি "অ্যাক্সেসলোগেন্ট্রি" হিসাবে আরও ভাল হবে। :-)

— টম রাসেল

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

— ক্যারি কেন্ডল

পছন্দ করুন যেহেতু accessLogকোনও সত্তার পরিবর্তে কোনও গুণ বা মান হিসাবে মডেল করা হয় এটি একবচন হওয়া উচিত। যদি আপনাকে ওভার ইঞ্জিনিয়ারিংয়ে দেওয়া হয়, তবে লগ এন্ট্রি একটি সত্তা হবে এবং আপনি চাইবেন /api/accessLogEntries?resource=123।

— টম রাসেল

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

— ক্যারি কেন্ডল

আমি একটি সিস্টেম বা ডাটাবেস ব্যক্তির চেয়ে প্রোগ্রামার বেশি তাই আমি এমন একটি এপিআই পছন্দ করি যা কনভেনশন মেনে চলার চেয়ে গল্প বলে। স্বয়ংক্রিয় ডকুমেন্টেশনের জন্য প্রভাবগুলি আসল, যদিও।

— টম রাসেল

Answer 7

কেন ডাটাবেস টেবিলের নামগুলির প্রচলিত প্রবণতা অনুসরণ করবেন না, যেখানে একক রূপটি সাধারণত গৃহীত হয়? সেখানে গিয়েছি, করেছি - এর পুনরায় ব্যবহার করুন।

সারণী নামকরণ দ্বিধা: একক বনাম বহুবচন নাম

Comments

ডাই অটো হ'ল ডাই অটোসের চেয়ে ভাল। এছাড়াও, ইংরেজি বহুবচনীয় সম্মেলনগুলি সামঞ্জস্যপূর্ণ নয়।

— ফ্ল্যাওয়ারস্কেপ

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

— আরপ্যাডফ

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

— টড মেনিয়ার

এটি কেবল টেবিলের নাম নয়, এটি ওওর শ্রেণীর নামের সাথেও তুলনীয় (আমার ক্লাসটি গ্রাহক নন গ্রাহক হিসাবে পরিচিত হবে)।

— বাইটেডেভ

এই ক্ষেত্রে, শব্দার্থক কেবল "ইতিমধ্যে সংজ্ঞায়িত" প্রবণতাগুলি গ্রহণ করা খুব গুরুত্বপূর্ণ

— কাত্তানি সিমোন

Answer 8

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

Http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm দেখুন

বহু ধরণের অনিয়মিত বহুবচন রয়েছে তবে এগুলি সর্বাধিক সাধারণ:

বিশেষ্য বহুবচন উদাহরণ গঠন

Ends with -fe   Change f to v then Add -s   
    knife   knives 
    life   lives 
    wife   wives
Ends with -f    Change f to v then Add -es  
    half   halves 
    wolf   wolves
    loaf   loaves
Ends with -o    Add -es 
    potato   potatoes
    tomato   tomatoes
    volcano   volcanoes
Ends with -us   Change -us to -i    
    cactus   cacti
    nucleus   nuclei
    focus   foci
Ends with -is   Change -is to -es   
    analysis   analyses
    crisis   crises
    thesis   theses
Ends with -on   Change -on to -a    
    phenomenon   phenomena
    criterion   criteria
ALL KINDS   Change the vowel or Change the word or Add a different ending   
     man   men
     foot   feet
     child   children
     person   people
     tooth   teeth
     mouse   mice
 Unchanging Singular and plural are the same    
     sheep deer fish (sometimes)

Comments

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

— কিশোর বোয়ারেট

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

— damd

@ কিশোরবোরেটে, ইউআরআই হিসাবে বহুবচন ব্যবহার করা ত্রুটি-ঝুঁকির চেয়েও বেশি, এমনকি স্থানীয় ইংরেজী ভাষীদের পক্ষেও। যেমন জঘন্য ইঙ্গিত দেয়, সূচি / সূচক / সূচকগুলির মতো বহুবস্তু আরও সমস্যা প্রবর্তন করছে। এবং আছে অগণিত বিশেষ্য। বহুসংখ্যার সাথে অগণনীয় বিশেষ্যকে মেশানো অন্য সমস্যা। প্রোগ্রামারদের এগুলিতে বেশি সময় ব্যয় করা কেন আরও শক্ত করে তোলে? আমি প্রতিটি কিছুর জন্য একক ব্যবহার করার পরামর্শ দিই। যদি কোনও / {id is থাকে, তবে এপিআই'র একক রেকর্ডটি ফিরিয়ে দেওয়া উচিত। যদি এরপরে কোনও / {আইডি not না থাকে তবে এপিআই'র সংগ্রহটি ফিরিয়ে নেওয়া উচিত।

— ডামিং ফু

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

— কিশোর বোড়ান

Answer 9

এপিআই গ্রাহকের দৃষ্টিকোণ থেকে শেষ পয়েন্টগুলি ভবিষ্যদ্বাণী করা উচিত

মূলত ...

1. GET /resources সংস্থানগুলির একটি তালিকা ফেরত দেওয়া উচিত।
2. GET /resource 400 স্তরের স্থিতি কোডটি ফিরিয়ে দেওয়া উচিত।
3. GET /resources/id/{resourceId} একটি সংস্থান দিয়ে একটি সংস্থান ফেরত দেওয়া উচিত।
4. GET /resource/id/{resourceId} কোনও রিসোর্স অবজেক্ট ফিরিয়ে দেওয়া উচিত।
5. POST /resources ব্যাচের উচিত সম্পদ তৈরি করা।
6. POST /resource একটি উত্স তৈরি করা উচিত।
7. PUT /resource একটি উত্স অবজেক্ট আপডেট করা উচিত।
8. PATCH /resource শুধুমাত্র পরিবর্তিত বৈশিষ্ট্যগুলি পোস্ট করে একটি সংস্থান আপডেট করা উচিত।
9. PATCH /resources ব্যাচ আপডেট সংস্থানগুলি শুধুমাত্র পরিবর্তিত বৈশিষ্ট্যগুলি পোস্ট করা উচিত।
10. DELETE /resourcesসমস্ত সংস্থান মুছে ফেলা উচিত; খালি মজা করছে: ৪০০ স্ট্যাটাস কোড
11. DELETE /resource/id/{resourceId}

এই পদ্ধতির সর্বাধিক নমনীয় এবং বৈশিষ্ট্য সমৃদ্ধ, তবে বিকাশ সবচেয়ে বেশি সময়সাপেক্ষ। সুতরাং, আপনি যদি তাড়াহুড়োয় হন (যা সর্বদা সফ্টওয়্যার বিকাশের ক্ষেত্রে হয়) কেবল আপনার শেষ পয়েন্ট resourceবা বহুবচন ফর্মের নাম দিন resources। আমি একবচনীয় ফর্মটিকে পছন্দ করি কারণ এটি আপনাকে বহুবিধ রূপগুলি 'গুলি' এর মধ্যে শেষ না হওয়ায় প্রোগ্রামটিমেটিকভাবে আত্মবিশ্বাস ও মূল্যায়নের বিকল্প দেয়।

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

সিদ্ধান্ত নেওয়ার জন্য কিছু মানদণ্ড হতে পারে:

1. আমার সময় বাধা কি?
2. আমি আমার গ্রাহকদের কী অপারেশন করতে দেব?
3. অনুরোধ এবং ফলাফল পেডলোড দেখতে কেমন?
4. আমি কি আমার কোডটিতে প্রতিবিম্ব ব্যবহার করতে এবং ইউআরআই পার্স করতে সক্ষম হতে চাই?

তাই এটা আপনার উপর নির্ভর করে. আপনি যা কিছু করেন তা সামঞ্জস্যপূর্ণ হয়।

Comments

বহুবচন রূপের মতো মনে হয়েছে কারণ বিকাশকারীরা মনে করে যে সমস্ত সংস্থান অন্তর্নিহিতভাবে কিছু সংগ্রহের অংশ। যাইহোক, "গৃহীত কনভেনশন" মনে হয় যে এটি POST /usersএকটি একক ব্যবহারকারীর তৈরি করা উচিত, এটি সংগ্রহে যোগ করা উচিত adding আমি একমত নই POST /usersব্যবহারকারীর একটি তালিকা তৈরি করা উচিত (এমনকি এটি 1 টির তালিকা হলেও), যেখানে POST /userঠিক একজন ব্যবহারকারী তৈরি করা উচিত। বহুবচন এবং একবাক্য সংস্থান উভয়ই সম-অস্তিত্ব থাকতে পারে না এমন কোনও কারণ আমি দেখতে পাচ্ছি না। তারা বিভিন্ন আচরণের বর্ণনা দেয় এবং তাদের কারও কারও অবাক হওয়া উচিত নয়।

— ক্রাশ করুন

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

— টম রাসেল

@ টমরসেল সাধারণত সার্ভারটি আইডি তৈরি করে, তাই আপনি এখনও পোষ্টে আইডিটি জানতেন না।

— অ্যালেক্স

@ টমরসেল, যখন নতুন সংস্থান তৈরি করার সময় ক্লায়েন্টটি (এক ধরণের) আইডি নির্ধারণ করে, PUT /users/<id>পরিবর্তে এটি ব্যবহার করা বেশি সাধারণ POST। POSTএর অনুবাদ রয়েছে "এটি সংগ্রহের সাথে এটি যুক্ত করুন এবং তার অংশ হিসাবে আইডি নির্ধারণ করুন"। PUT"এই আইডি সহ এই সংস্থানটি আপডেট করুন (বা যুক্ত করুন)" এর ব্যাখ্যা রয়েছে। এই নীতির আরও দীর্ঘ ব্যাখ্যা করার জন্য রেস্টকুকবুক.com/HTTP%20Mithods/put-vs- পোষ্ট দেখুন ।

— জোহেম শুলেনক্লোপার

আমি বিশ্বাস করি না যে ট্যুইটার্স এপিআইয়ের তুলনাটি ন্যায্য কারণ তারা তাদের সমস্ত প্রান্তের জন্য বহুবচন ফর্মটি ব্যবহার করে। তারা একই উপাদানগুলির জন্য বহুবচন এবং একবচন মিশ্রিত করে না।

— অ্যান্ড্রু টি ফিনেল

Answer 10

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

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

Comments

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

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

Answer 11

আমি সরলতা এবং ধারাবাহিকতা উভয়ের জন্য একক ফর্ম ব্যবহার পছন্দ করি।

উদাহরণস্বরূপ, নিম্নলিখিত url বিবেচনা করুন:

/ গ্রাহক / 1

আমি গ্রাহককে গ্রাহক সংগ্রহ হিসাবে বিবেচনা করব, তবে সরলতার জন্য সংগ্রহের অংশটি সরানো হবে।

আরেকটি উদাহরণ:

/ সরঞ্জাম / 1

এই ক্ষেত্রে, সরঞ্জামগুলি সঠিক বহুবচন রূপ নয়। সুতরাং এটি সরঞ্জাম সংগ্রহ হিসাবে গণ্য করা এবং সরলতার জন্য সংগ্রহ সরিয়ে ফেলা এটি গ্রাহকের ক্ষেত্রে সামঞ্জস্য করে।

Comments

পোস্ট / গ্রাহকের মনে হচ্ছে এটি একমাত্র এবং একমাত্র গ্রাহককে প্রতিস্থাপন করবে। একক উত্সের নাম ব্যবহার করে এটি আমার সবচেয়ে বড় দুঃখ।

— অ্যান্ড্রু টি ফিনেল

@ অ্যান্ড্রু-টি-ফিনেল POST /customerখুব একটা কাজ করার কথা নয় - একক গ্রাহক প্রবেশ করান?

— ডনমুট্টি

এটি গ্রাহকগণের সংগ্রহে একটি একক গ্রাহককে প্রবেশ করায়। POST /customerআমার কাছে এমনভাবে পড়ছে যেন এটি theগ্রাহকের কাছে পোস্ট করা। গ্রাহকদের সংগ্রহ নয়। যাইহোক, আমি স্বীকার করব যে বহুবচনটি নয় বা বহুবচন একটি পছন্দ। যতক্ষণ না তারা উত্তরটির মতো মিশ্রিত হয় না। এটি অবিশ্বাস্যরকম বিভ্রান্তিকর হবে।

— অ্যান্ড্রু টি ফিনেল

"গ্রাহকের কাছে পোস্ট করা" এই ক্ষেত্রে কোনও অর্থ দেয় না। পোস্ট প্রতিস্থাপন করে না, এটি সন্নিবেশ করে। হতে পারে যদি এটি পোস্ট / গ্রাহক / 1 হ'ল আমি দ্বিধা দেখতে পেতাম, তবে এটি আরএসইটি দৃষ্টিকোণ থেকে খুব একটা বোঝায় না, কারণ আপনি কী সন্নিবেশ করছেন? এটা হবে / গ্রাহক / 1 / চালান অথবা / গ্রাহক / 1 / প্রাপ্তি ইত্যাদি

— damd

Answer 12

কোনও রুটের কোনও আইডি কোনও তালিকার সূচকের মতো দেখতে হবে এবং সেই অনুসারে নামকরণ করা উচিত।

numbers = [1, 2, 3]

numbers            GET /numbers
numbers[1]         GET /numbers/1
numbers.push(4)    POST /numbers
numbers[1] = 23    UPDATE /numbers/1

তবে কিছু সংস্থানগুলি তাদের রুটে আইডি ব্যবহার করে না কারণ সেখানে কেবলমাত্র একটি আছে, বা কোনও ব্যবহারকারীর একাধিকের অ্যাক্সেস নেই, তাই সেগুলি তালিকা নয়:

GET /dashboard
DELETE /session
POST /login
GET /users/{:id}/profile
UPDATE /users/{:id}/profile

Answer 13

নামকরণের কনভেনশনের মাধ্যমে, "কেবলমাত্র একটি বাছাই করুন এবং এটির সাথে লেগে থাকুন" বলাই সাধারণত নিরাপদ, যা বোঝা যায়।

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

এবং সেই প্রসঙ্গে, ভাষাগত নিয়মাবলী কেবল আপনাকে নীচের হিসাবে পেতে পারে:

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

এবং আমি এটি পছন্দ করি।
যদিও, অন্যদিকে - এটি আপনার ডিরেক্টরি, আপনি যদি এটি চান তবে এটির নাম দিতে পারেন "একটি-সংস্থান-বা একাধিক-সংস্থান"- এটি আসলে গুরুত্বপূর্ণ জিনিস নয়।

গুরুত্বপূর্ণটি হ'ল যদি আপনি "123" নামের একটি ফাইল "রিসোর্সএস" নামে একটি ডিরেক্টরিতে রাখেন (ফলস্বরূপ /resourceS/123) তবে আপনি এটির মাধ্যমে অ্যাক্সেসযোগ্য হওয়ার আশা করতে পারবেন না /resource/123।

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

দ্রষ্টব্য: প্রযুক্তিগতভাবে, আপনি "প্রতীকী লিঙ্কগুলি" তৈরি করতে পারেন, যাতে এটির /resources/123মাধ্যমেও অ্যাক্সেস করা যায় /resource/123, তবে পূর্ববর্তীটি এখনও বিদ্যমান রয়েছে!

Answer 14

কটাক্ষপাত আছে গুগল এর রিসোর্স নাম: এপিআই ডিজাইন গাইড নামকরণ সম্পদ আরেকটি নিতে জন্য।

সংক্ষেপে:

• সংগ্রহগুলি বহুবচন সহ নামকরণ করা হয়।
• পৃথক সংস্থানগুলির একটি স্ট্রিং সহ নামকরণ করা হয়েছে।

|--------------------------+---------------+-------------------+---------------+--------------|
| API Service Name         | Collection ID | Resource ID       | Collection ID | Resource ID  |
|--------------------------+---------------+-------------------+---------------+--------------|
| //mail.googleapis.com    | /users        | /[e-mail] | /settings     | /customFrom  |
| //storage.googleapis.com | /buckets      | /bucket-id        | /objects      | /object-id   |
|--------------------------+---------------+-------------------+---------------+--------------|

আপনি যদি এই বিষয়টি নিয়ে ভাবছেন তবে এটি পড়া সার্থক।

Answer 15

সমস্ত পদ্ধতির জন্য বহুবচন ব্যবহার কমপক্ষে একটি দিকের ক্ষেত্রে আরও ব্যবহারিক: আপনি যদি পোস্টম্যান (বা অনুরূপ সরঞ্জাম) ব্যবহার করে কোনও রিসোর্স এপিআই বিকাশ করছেন এবং পরীক্ষা করছেন, GET থেকে POST ইত্যাদিতে স্যুইচ করার সময় আপনার ইউআরআই সম্পাদনা করার দরকার নেই etc ।

Comments

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

— উইরন

Answer 16

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

আপনার সমস্ত সংস্থান যদি শীর্ষ স্তরের হয় তবে আপনি একক উপস্থাপনা দিয়ে দূরে সরে যেতে পারেন। অনুভূতি এড়ানো বড় জয়।

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

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

ধরুন আমাদের নীচের মডেল রয়েছে।

interface User {
    <string>id;
    <Friend[]>friends;
    <Manager>user;
}

interface Friend {
    <string>id;
    <User>user;
    ...<<friendship specific props>>
}

যদি আমার এমন কোনও সংস্থান সরবরাহের প্রয়োজন হয় যা কোনও ক্লায়েন্টকে একটি নির্দিষ্ট ব্যবহারকারীর বিশেষ বন্ধুর পরিচালক পেতে দেয় তবে এটি দেখতে এরকম কিছু হতে পারে:

GET /users/{id}/friends/{friendId}/manager

নীচে আরও কয়েকটি উদাহরণ দেওয়া হল:

• GET /users - বিশ্বব্যাপী ব্যবহারকারী সংগ্রহের মধ্যে ব্যবহারকারী সংস্থান তালিকাভুক্ত করুন
• POST /users - বিশ্বব্যাপী ব্যবহারকারীদের সংগ্রহে একটি নতুন ব্যবহারকারী তৈরি করুন
• GET /users/{id} - বিশ্বব্যাপী ব্যবহারকারী সংগ্রহ থেকে একটি নির্দিষ্ট ব্যবহারকারী পুনরুদ্ধার করুন
• GET /users/{id}/manager - একটি নির্দিষ্ট ব্যবহারকারীর পরিচালক পান
• GET /users/{id}/friends - ব্যবহারকারীর বন্ধুদের তালিকা পান
• GET /users/{id}/friends/{friendId} - কোনও ব্যবহারকারীর একটি নির্দিষ্ট বন্ধু পান
• LINK /users/{id}/friends - এই ব্যবহারকারীর সাথে একটি বন্ধু সমিতি যুক্ত করুন
• UNLINK /users/{id}/friends - এই ব্যবহারকারী থেকে একটি বন্ধু সমিতি সরান

লক্ষ্য করুন যে কীভাবে প্রতিটি স্তরের কোনও পিতামাতার কাছে মানচিত্রের কাজ করা যেতে পারে। একই বস্তুর জন্য বিভিন্ন পিতামাতাকে ব্যবহার করা বিপরীত। কোনও উত্স পুনরুদ্ধারে GET /resource/123কোনও নতুন সংস্থান তৈরি করা উচিত হবে এমন ইঙ্গিত দেয় নাPOST /resources

Answer 17

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

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

GET  /resources     =     GET  /resource
GET  /resources/1   =     GET  /resource/1
POST /resources/1   =     POST /resource/1
...

আপনি ছবি পেতে। কেউ ভুল নয়, সর্বনিম্ন প্রচেষ্টা এবং ক্লায়েন্ট সর্বদা এটি সঠিকভাবে পাবেন।

Comments

আপনি যদি 302 টি পুনর্নির্দেশ করছেন এবং আপনার ক্যাশে দু'বার সবকিছু সংরক্ষণ করছে, আপনি নিজের ক্যাশেটি ভুল সেট আপ করেছেন। ক্যাশে 302 পুনর্নির্দেশগুলি সংরক্ষণ করার কথা নয়।

— উইনসেট

আপনি যদি ক্লায়েন্ট সর্বদা ব্যবহার করেন /resourcesএবং সর্বদা এতে পুনঃনির্দেশিত হন তবে /resourceআপনি এটি ভুল করেছেন। অন্য কেউ যদি আপনার এপিআই ব্যবহার করে তবে তারা সরাসরি সঠিক ইউআরএল ব্যবহার করতে পারে বা পুনঃনির্দেশিত হতে পারে (যা কাজ করে তবে ভুল) এবং আপনিই সেই লোকটি ভুল পথটি খোলেন।

— মার্টিনাস

আপনি কী "ভুল" বলতে চাইছেন তা দ্বারা নিশ্চিত নন - এটি অত্যন্ত বিষয়গত। এটি সত্যই ভুল নয় কারণ এটি কাজ করে।

— wynnset

এটি রক্ষণাবেক্ষণের ব্যয় এবং বোঝার ব্যয় এবং কোডের পরিমাণ বাড়ায়।

— শেপার্ড

Answer 18

আমি {id}URL হিসাবে উপ-সংস্থানগুলির সাথে ওভারল্যাপের অংশটি দেখতে পছন্দ করি নাidতাত্ত্বিকভাবে কিছু হতে পারে এবং অস্পষ্টতা থাকতে পারে বলে । এটি বিভিন্ন ধারণার (শনাক্তকারী এবং উপ-সংস্থান নাম) মিশ্রণ করছে।

একই সমস্যা প্রায়ই দেখা যায় enumধ্রুবক বা কাঠামো, যেখানে বিভিন্ন ধারণা উদাহরণস্বরূপ মিশ্র (হয় ফোল্ডারের, আপনি ফোল্ডার আছে Tigers, Lionsএবং Cheetahs, এবং তারপর আরো একটি ফোল্ডার নামকAnimals একই পর্যায়ে - এই কোন মানে হিসাবে একটি উপসেট করে তোলে অন্যান্য)।

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

সুতরাং শেষ পয়েন্টগুলি যে কোনও একক ব্যবহারকারীর সাথে ডিল করে:

GET  /user             -> Not allowed, 400
GET  /user/{id}        -> Returns user with given id
POST /user             -> Creates a new user
PUT  /user/{id}        -> Updates user with given id
DELETE /user/{id}      -> Deletes user with given id

তারপরে ব্যবহারকারীদের অনুসন্ধান করার জন্য পৃথক সংস্থান রয়েছে যা সাধারণত একটি তালিকা ফেরত দেয়:

GET /users             -> Lists all users, optionally filtered by way of parameters
GET /users/new?since=x -> Gets all users that are new since a specific time
GET /users/top?max=x   -> Gets top X active users

এবং এখানে একটি সাব-রিসোর্সের কয়েকটি উদাহরণ যা একটি নির্দিষ্ট ব্যবহারকারীর সাথে আচরণ করে:

GET /user/{id}/friends -> Returns a list of friends of given user

একটি বন্ধু তৈরি করুন (অনেকগুলি লিঙ্কে অনেকগুলি):

PUT /user/{id}/friend/{id}     -> Befriends two users
DELETE /user/{id}/friend/{id}  -> Unfriends two users
GET /user/{id}/friend/{id}     -> Gets status of friendship between two users

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

Answer 19

একক ব্যবহার করুন এবং উদাহরণস্বরূপ "বিজনেস ডিরেক্টরি" হিসাবে দেখা ইংরেজী কনভেনশনটির সুবিধা নিন।

প্রচুর জিনিস এইভাবে পড়ে: "বুক কেস", "ডগ প্যাক", "আর্ট গ্যালারী", "ফিল্ম ফেস্টিভ্যাল", "কার লট" ইত্যাদি

বাম থেকে ডানদিকে url পাথের সাথে এটি সুবিধামত মেলে। বামদিকে আইটেম টাইপ। ডানদিকে টাইপ করুন।

না GET /usersসত্যিই কি কখনো ব্যবহারকারীদের একটি সেট আনা? সাধারণত না. এটিতে একটি কী এবং সম্ভবত একটি ব্যবহারকারীর নামযুক্ত স্টাবগুলির সেট এনেছে। সুতরাং এটি আসলে /usersযাইহোক না। এটি ব্যবহারকারীদের একটি সূচক, বা "ব্যবহারকারী সূচক" যদি আপনি চান। এটাকে কেন ডাকবে না? এটি একটি /user/index। যেহেতু আমরা সেট টাইপ নামে থাকেন, আমরা ক্যোয়ারী পরামিতি যেমন অবলম্বন না একটি ব্যবহারকারী বিভিন্ন অনুমান দেখাচ্ছে একাধিক প্রকারের থাকতে পারে user/phone-listবা /user/mailing-list।

এবং ব্যবহারকারী 300 সম্পর্কে কি? এখনও আছে /user/300।

GET /user/index
GET /user/{id}

POST /user
PUT /user/{id}

DELETE /user/{id}

সমাপ্তিতে, এইচটিটিপি-র একক অনুরোধে কেবলমাত্র একবারে প্রতিক্রিয়া থাকতে পারে। একটি পথ সর্বদা একটি একক জিনিসের উল্লেখ করে।

Answer 20

আমার কাছে বহুসংখ্যক সংগ্রহটি হেরফের করা হয়েছে , অন্যদিকে সিঙ্গুলাররা সেই সংগ্রহে থাকা আইটেমটি ম্যানিপুলেট করে ।

সংগ্রহের পদ্ধতিগুলি জিইটি / পোস্ট / ডিলিটের অনুমতি দেয়

আইটেমটি জিইটি / পুট / ডিলিট পদ্ধতিগুলিকে অনুমতি দেয়

উদাহরণ স্বরূপ

পোস্টে / শিক্ষার্থীরা স্কুলে একটি নতুন শিক্ষার্থী যুক্ত করবে।

/ শিক্ষার্থীরা ডিলেট করুন বিদ্যালয়ের সমস্ত ছাত্রকে সরিয়ে দেবে।

/ ছাত্র / 123 অন ​​ডিলেট করুন স্কুল থেকে 123 ছাত্রকে সরিয়ে দেবে।

এটি গুরুত্বহীন মনে হতে পারে তবে কিছু প্রকৌশলী কখনও কখনও আইডিটি ভুলে যান। যদি রুটটি সর্বদা বহুবচন হয়ে থাকে এবং একটি মোছার কাজটি সম্পাদন করে তবে আপনি দুর্ঘটনাক্রমে আপনার ডেটা মুছতে পারেন। যদিও এককটিতে আইডি না পাওয়া 403 টি রুট পাওয়া যায়নি ফিরে আসবে।

উদাহরণটি আরও প্রসারিত করতে যদি API টি একাধিক স্কুল উন্মুক্ত করার কথা ছিল, তবে এর মতো কিছু something

/ স্কুল / এবিসি / শিক্ষার্থীরা ডিলেট করুন বিদ্যালয়ের সমস্ত ছাত্রকে সরিয়ে দেবে abc।

কখনও কখনও সঠিক শব্দ নির্বাচন করা নিজের পক্ষে একটি চ্যালেঞ্জ, তবে আমি সংগ্রহটির বহুত্ব বজায় রাখতে পছন্দ করি। যেমন cart_itemsবা cart/itemsসঠিক মনে হয়। বিলোপ মোছার বিপরীতে cart, কার্টটি এটি নিজেই মুছে দেয় এবং কার্টের আইটেমগুলিতে নয়;)।

Comments

এটিকে কি / কার্ট এবং / কার্ট / আইটেম (গুলি) হিসাবে ভাগ করা উচিত? তারপরে আপনি পুরো কার্টটি (যেমন একটি মুছা সহ) বা স্বতন্ত্র আইটেমগুলিকে সম্বোধন করতে পারেন?

— রব গ্রান্ট

@ রবার্টগ্রান্ট কি এটি "/ কার্টস / আইটেম / 123" হবে না? (উদাহরণস্বরূপ, "কার্ট" এবং "কার্টস" না কেন নিয়মটি সর্বদা 'বহুবচনের'?)

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

আমি যুক্তি দিয়েছি যে যদি প্রোডাকশন কোডটি চেক করা হয় তবে এটি প্রত্যেকের কার্ট আইটেমের নাম মুছে ফেলাতে সক্ষম হয় নামকরণ কনভেনশন থেকে বড় সমস্যা। তারা সম্ভবত একটি আইডি 'র' মনে রাখবেন সম্ভবত খুব কম।

— অ্যান্ড্রু টি ফিনেল

কেউ কি কখনও এমন একটি এন্ডপয়েন্ট তৈরি করতে পারেন যা কেবল একটি সম্পূর্ণ সংগ্রহ মুছে দেয়? আমার কাছে অত্যন্ত বিপজ্জনক বলে মনে হচ্ছে, এবং সম্ভবত REST কেন ব্যাচ মোছা সমর্থন করে না। (আপনাকে কোনও বস্তুর মধ্যে অ্যারেটি लपेटতে হবে)। পুরো সংগ্রহটি মুছতে যদি আমার একেবারে

— শেষের দিকের

Answer 21

কেমন:

/resource/(না /resource)

/resource/ এর অর্থ এটি একটি ফোল্ডারে "রিসোর্স" নামক কিছু রয়েছে, এটি একটি "রিসোস" ফোল্ডার।

এবং আমিও মনে করি ডাটাবেস সারণির নামকরণ কনভেনশন একই, উদাহরণস্বরূপ, 'ব্যবহারকারী' নামক একটি সারণী একটি "ব্যবহারকারী সারণী", এতে "ব্যবহারকারী" নামক কিছু রয়েছে।

Answer 22

আমি বহুবচন ( /resources) এবং একক ( উভয় ) ব্যবহার করতে পছন্দ করি/resource/{id} করি কারণ আমি মনে করি এটি সংস্থানগুলি এবং একক সংস্থান নিয়ে কাজ করার মধ্যে যুক্তিকে আরও স্পষ্টভাবে পৃথক করে।

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

GET /resources?Id=123

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

অন্যদিকে, একক রূপ ব্যবহার করার সময়:

GET /resource?Id=123

আইডি সঠিকভাবে নির্দিষ্ট করা হয়নি বলে সার্ভারটি সম্ভবত একটি ত্রুটি ফিরিয়ে দেবে, এবং ব্যবহারকারীকে বুঝতে হবে যে কিছু ভুল wrong

Comments

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

— অ্যান্ড্রু টি ফিনেল

এটা স্পষ্টতই একটি ভুল ছিল। আমি এখন আমার উত্তর আপডেট করেছি। এটি লক্ষ্য করার জন্য ধন্যবাদ।

— pberggreen

আবার ডাউনভোট হওয়ার পরে আমি কী লিখেছিলাম তা আমি দেখেছিলাম এবং বুঝতে পারি যে মূল পোস্টটি সঠিক ছিল was আমার বক্তব্যটি হ'ল ব্যবহারকারী যদি ভুল কাজ করে তবে বহুবচন + একবাক্য ব্যবহার করা আসলে একটি বহুবচন ব্যবহার করে আরও ভাল ত্রুটির বার্তা দেয়।

— pberggreen

আমি এখনও মনে করি এটি হাতের মুঠোয় বিষয়টি বিভ্রান্ত করছে। বহুবচন ব্যবহারের ধারণাটি এটি একটি সংগ্রহ। এবং শেষে নম্বরটি সংগ্রহের একটি সূচক। আপনি নিজে থেকে / সংস্থান যদি হয়? বহুবচন এবং একক উভয়কে একসাথে ব্যবহার করা বেশ বিভ্রান্তিকর। বলার / সংস্থান / 123 বলেছেন: আমার রিসোর্স 123 সংস্থান বালতিতে পান।

— অ্যান্ড্রু টি ফিনেল