REST URI सम्मेलन - इसे बनाते समय संसाधन का एकवचन या बहुवचन नाम

529

मैं REST में नया हूँ और मैंने देखा है कि कुछ RESTful सेवाओं में वे अपडेट / पाने / हटाने और बनाने के लिए विभिन्न संसाधन URI का उपयोग करते हैं। जैसे कि

  • बनाएँ - का उपयोग करते हुए / संसाधनों POST विधि (बहुवचन का पालन) कुछ का उपयोग कर स्थानों पर साथ / संसाधन (एकवचन)
  • अद्यतन - PUT विधि के साथ / संसाधन / 123 का उपयोग करना
  • प्राप्त करें - GET विधि के साथ / संसाधन / 123 का उपयोग करना

मैं इस URI नामकरण सम्मेलन के बारे में थोड़ा भ्रमित हूं। संसाधन निर्माण के लिए हमें बहुवचन या एकवचन का क्या उपयोग करना चाहिए? यह तय करते समय क्या मापदंड होना चाहिए?

rest  resources  naming-conventions  uri 
— JPReddy
स्रोत
9
इस विषय के बाद, मैंने एक लेख में प्रसिद्ध REST एपीआई के कुछ उदाहरण एकत्र किए हैं: inmensosofa.blogspot.com/2011/10/… ।
— jjmontes
3
निष्कर्ष मैं नीचे सभी जवाब पढ़ने के बाद तक पहुँच: हमेशा उपयोग विलक्षण क्योंकि (क) यह सुसंगत है, (ख) यह सीधे विलक्षण वर्ग और तालिका नाम, (ग) कुछ बहुवचन संज्ञाएं अंग्रेजी में अनियमित (अप्रत्याशित) कर रहे हैं करने के लिए नक्शे
— विल शेपर्ड
इस जवाब को एकवचन तालिका नामकरण सम्मेलनों के लिंक के लिए देखें , और एक अन्य लेख है जिसमें इस सटीक मुद्दे का उल्लेख है बाकी एपीआई डेवलपर की दुविधा - धन्यवाद @Sorter
— विल शेपर्ड

जवाबों:

280

उपयोग करने /resourcesका आधार यह है कि यह "सभी" संसाधनों का प्रतिनिधित्व कर रहा है। यदि आप एक करते हैं GET /resources, तो आप संभवतः पूरे संग्रह को वापस कर देंगे। पोस्ट करने से /resources, आप संग्रह में जोड़ रहे हैं।

हालाँकि, व्यक्तिगत संसाधन / संसाधन पर उपलब्ध हैं। यदि आप एक करते हैं GET /resource, तो आप त्रुटि की संभावना करेंगे, क्योंकि यह अनुरोध कोई मतलब नहीं है, जबकि /resource/123सही अर्थ बनाता है।

/resourceइसके बजाय का उपयोग करना /resourcesसमान है कि आप ऐसा कैसे करेंगे यदि आप एक फाइल सिस्टम और फाइलों के संग्रह के साथ काम कर रहे हैं, और /resourceइसमें व्यक्तिगत 123, 456फाइलों के साथ "निर्देशिका" है।

किसी भी तरह से सही या गलत नहीं है, जो आपको सबसे अच्छा लगता है उसके साथ जाएं।

— विल हार्टुंग
स्रोत
55
बहुत बढ़िया जवाब! लेकिन विंडोज में "डिफ़ॉल्ट" निर्देशिकाओं में बहुवचन नाम हैं। जैसे "प्रोग्राम फाइल्स", "यूजर्स", "डॉक्यूमेंट्स", "वीडियो" आदि। इसके अलावा, मैंने कई बार वेबसाइट यूआरएल में बहुवचन नामों का सामना किया है।
— दिमित्री गॉन्चर
50
डिफैक्टो कन्वेंशन बहुत ज्यादा लोगों और एपीआई बाहर ले हर समय यह बहुवचन रख रहा है। Ids
— पॉजिटिव
205
"न तो रास्ता सही है या गलत, आपको जो सबसे अच्छा लगता है, उसके साथ चलें।" आह प्रसिद्ध पंक्ति जिसे मैं अक्सर सुनता हूं और लोगों से सुनकर बीमार हो जाता हूं। कन्वेंशन के मामले और समुदाय के बीच रचनात्मक रूप से बहस की जानी चाहिए, जहां बेहतर समाधान और अच्छी प्रथाओं के बारे में बताया गया है। जब आप यूआरआई में संसाधन नामों के लिए बहुवचन और एकवचन दोनों का उपयोग कर रहे हैं, तो यह आपके कोड और एपीआई को जटिल करता है क्योंकि उपयोगकर्ता और एपीआई के पीछे के कोड को एकल बनाम बहुवचन में अंतर करने के लिए मार्गों और तर्क के लिए खाते में है, जबकि यदि आप सिर्फ छड़ी करते हैं बहुवचन के साथ हर समय आपको कोई समस्या नहीं है।
— PositiveGuy
30
@TomaszPluskiewicz आप पूरी तरह से सही हैं कि ग्राहकों को परवाह नहीं है। सॉफ्टवेयर डेवलपर्स के रूप में हमें ध्यान देना चाहिए - और इसके लिए मैं डब्ल्यूटीएफ की टिप्पणी से सहमत हूं कि सम्मेलन के बारे में रचनात्मक बहस मूल्यवान है।
— ट्रैविस डी
12
तो क्या कोई सिर्फ एक शब्द का जवाब दे सकता है और इसे स्वीकार कर सकता है इसलिए मुझे यह सब (फिर से) पढ़ना नहीं है।
— बेन जॉर्ज
623

मेरे लिए एक स्कीमा बेहतर है जिसे आप सीधे कोड (स्वचालित करने के लिए आसान) पर मैप कर सकते हैं, मुख्यतः क्योंकि कोड वही है जो दोनों सिरों पर होने वाला है। 

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)
— JLA
स्रोत
22
इसकी कठिनाई या आसानी HATEOS का सम्मान नहीं करने के कारण है। इससे कोई फर्क नहीं पड़ता कि यह बहुवचन या एकवचन है या कुछ और। आपको सर्वर से भेजे गए uri का सम्मान करना चाहिए और क्लाइंट पर आपके uri का "निर्माण" नहीं करना चाहिए। फिर आपको अपने कोड के लिए 0 मैपिंग करनी होगी।
— रिचर्ड
7
@richard क्लाइंट को अभी भी मैपिंग करनी है। HATEOS में उन्हें एक ऐसे नाम से मैप करना होगा जो URI कंस्ट्रक्शन से रिलेशनशिप (rel) को दर्शाता है। Rel, मेथड (क्रिया) और Content-Type फिर संसाधन मीडिया बनाते हैं। यह एक अच्छे यूआरआई डिजाइन की आवश्यकता को रोकता नहीं है। भले ही क्लाइंट को rel नाम के लिए वरीयता दी जा सकती है, एपीआई के डेवलपर्स को अभी भी URI निर्माण के लिए एक अच्छे मानव-पठनीय मानक की आवश्यकता है।
4
मेरी राय में यह बेहतर जवाब है। सिवाय इसके कि मैंने हमेशा बहुवचन के बजाय एकवचन का उपयोग करना पसंद किया है। User.getList (), User.getById, User.delete इत्यादि
— पूर्वी भिक्षु
3
मुझे सादगी पसंद है। मानचित्रण को दस्तावेज़ों और परीक्षणों को मार्गों पर बनाने में लाभ होता है जो अविश्वसनीय रूप से लिखना आसान होता है।
— डेलोस
5
मुझे यह अर्थपूर्ण लग रहा है। हालाँकि, हम एक डेटाबेस-पहली दुकान हैं, जिसका अर्थ है कि हम अपने डेटाबेस स्कीमा से कोड और एपीआई इकाइयाँ उत्पन्न करते हैं। और डेटाबेस मानक विलक्षण तालिका नामों की वकालत करते हैं, इसलिए हम उस के साथ जा रहे हैं, लेकिन अभी भी इस उत्तर के रूप में एक ही तर्क के तहत।
— एंड्रे सी। एंडरसन
274

मैं ऐसा करने में बात नहीं देखता और मुझे लगता है कि यह सबसे अच्छा यूआरआई डिजाइन नहीं है। RESTful सेवा के उपयोगकर्ता के रूप में मुझे सूची संसाधन से वही नाम होने की कोई उम्मीद नहीं है, चाहे मैं सूची में या विशिष्ट संसाधन तक पहुँच प्राप्त करूं। आपको समान पहचानकर्ताओं का उपयोग करना चाहिए चाहे आप सूची संसाधन या किसी विशिष्ट संसाधन का उपयोग करना चाहते हों।

— जान दीन्हार्ड
स्रोत
69
जहां तक ​​मेरा सवाल है यह सबसे अच्छा जवाब है। मैं सराहना करता हूं कि एपीआई डिजाइनर "संसाधन # 123" प्राप्त करने की भाषाई शुद्धता को पसंद करते हैं, लेकिन यह एपीआई की क्लाइंट के साथ-साथ मदद दस्तावेज लिखने के दौरान अतिरिक्त कोडिंग परेशानी है। (GET / api / people बनाम GET / api / person / 123? Euuuchh।) .... इसके बारे में सोचने के बजाय "संसाधन # 123 प्राप्त करें", इसे अपने सिर में वाक्यांश की तरह "संसाधनों के संग्रह से प्राप्त करें" मैच # 123 "।
— वारेन रमक
5
बहुवचन / एकवचन संसाधनों का भेद भाषाई शुद्धता के बारे में नहीं है, बल्कि पैमाने के बारे में है। / कर्मचारी / 12, आईडी '12' के साथ कर्मचारियों के संसाधन के सबसेट के रूप में मुझे पढ़ता है (इसका मतलब कुछ भी हो सकता है, उदाहरण के लिए हाल ही में निकाल दिए गए कर्मचारियों पर खोज क्वेरी)। यदि आप आईडी '12' के साथ कर्मचारी के रूप में ऊपर पढ़ते हैं, तो आप सबसेट का प्रतिनिधित्व कैसे करेंगे? एकमात्र विकल्प यूआरआई के अधिक जटिल अयस्क को संग्रहित करना है जिसमें वस्तुओं को स्वयं वस्तुओं से अलग किया जाता है (अर्थात एकवचन बनाम बहुवचन)।
— एरिक
9
हाल ही में निकाल दिए गए कर्मचारियों (या किसी भी सबसेट) पर एक खोज क्वेरी का प्रतिनिधित्व करने के लिए चुनना / कर्मचारी / 12 मुझे लगता है कि बुरा डिजाइन होगा। यदि आप किसी भी प्रकार के सबसेट का प्रतिनिधित्व करना चाहते हैं, तो मैं उन्हें अपने आप में संसाधनों (उचित नामों के साथ) के रूप में पेश करने का सुझाव देता हूं।
— Jan Deinhard
3
इससे ग्राहकों के लिए समझ का कोई लेना देना नहीं है। यह अलग-अलग यूआरएल के साथ अलग-अलग चीजों को संबोधित करने के बारे में है। और बिना संघर्ष के सभी HTTP तरीकों का जवाब देने में सक्षम है। आपके पास एक संसाधन हो सकता है जो वस्तुओं का एक संग्रह है, और एक संसाधन जो एक आइटम का प्रतिनिधित्व करता है। सभी के लिए मुझे लगता है कि संग्रह संसाधन example.org/166316e2-e1and उस संग्रह example.org/20d68348-ccc-001c4200de में एक विशेष आइटम हो सकता है । क्लाइंट को URL का निर्माण नहीं करना चाहिए (जो स्पष्ट रूप से स्केल नहीं करता है, यह RESTful नहीं है और यही लिंक संबंध प्रकार के लिए है)।
— एरिक
4
यदि आपको नहीं लगता कि मनमाने ढंग से यूआरएल सुंदर हैं, तो एक बहुवचन नाम के साथ एक संग्रह संसाधन और एक विलक्षण नाम के साथ एक व्यक्तिगत आइटम की पहचान करने के लिए स्वतंत्र महसूस करें। यदि आपको अंग्रेजी URL पसंद नहीं है और आपकी प्राकृतिक भाषा उस तरीके का समर्थन नहीं करती है, जो आपकी पसंदीदा भाषा में इसे परिभाषित करने के लिए कुछ और का उपयोग करता है, तो मुझे लगता है कि सभी भाषाएं आपको किसी भी तरह अलग करने में सक्षम बनाती हैं / /-संग्रह-की- bla / 2321 'बनाम' bla / 61 'लिखित रूप में। और उन दो अलग-अलग संसाधनों में से प्रत्येक GET / PUT / DELETE / POST / PATCH और अन्य को भेजते समय पूरी तरह से अलग परिणामों का प्रतिनिधित्व करता है।
— एरिक
77

बहुवचन

  • सरल - सभी मूत्र एक ही उपसर्ग के साथ शुरू होते हैं
  • तार्किक - 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?

— एरिक नूडसन
स्रोत
10
एकवचन : मामले में, जब आपके सिस्टम का हिस्सा केवल एक ऑब्जेक्ट (0-1, मौजूद है या नहीं) जैसे उपयोगकर्ता / 1 / अवतार आप इस एकल वस्तु (जैसे अवतार) के लेबल के लिए एकवचन रूप का उपयोग कर सकते हैं - अधिक विस्तृत उदाहरण यहाँ: stackoverflow .com / एक / 38296217/860099 । BTW - बहुत अच्छा जवाब :)
— कामिल Kiełczewski
क्लास और टेबल के नाम की मैपिंग के बारे में क्या, जो एकवचन होना चाहिए? ( अन्य उत्तर देखें )
— Sheppard
@WillSheppard - वर्ग के नाम एकवचन रूप में सबसे अच्छे हैं और तालिका के नाम बहुवचन रूप में सबसे अच्छे हैं। उदाहरण के Orderलिए एक वर्ग के लिए एक अच्छा नाम है जो एक आदेश का संदर्भ देने वाली वस्तुओं के विलक्षण उदाहरणों से संबंधित है। OrderListएक वर्ग के लिए एक नाम है जो कई Orderउदाहरणों से संबंधित है। Orders Tableकई आदेशों की एक डेटाबेस तालिका के लिए एक अच्छा नाम है।
— एरिक नूड्सटन
मैं GET / ऑर्डर करना चाहता हूं, लेकिन मैं केवल 1 /
— jim smith
@ jim-smith फिर आप GET / उपयोगकर्ताओं / 1 वाले उपयोगकर्ताओं के संग्रह से अनुरोध / 1 क्यों नहीं करते?
— रोहमर
49

विलक्षण

सुविधा की चीजों में अनियमित बहुवचन नाम हो सकते हैं। कभी-कभी उनके पास एक नहीं होता है। लेकिन सिंगुलर नाम हमेशा से रहे हैं।

जैसे CustomerAddresses पर CustomerAddress

इस संबंधित संसाधन पर विचार करें।

इससे /order/12/orderdetail/12अधिक पठनीय और तार्किक है /orders/12/orderdetails/4।

डेटाबेस टेबल्स

एक संसाधन एक डेटाबेस तालिका की तरह एक इकाई का प्रतिनिधित्व करता है। इसका एक तार्किक एकवचन नाम होना चाहिए। यहाँ तालिका नामों पर जवाब दिया गया है।

क्लास मैपिंग

कक्षाएं हमेशा विलक्षण होती हैं। ORM उपकरण वर्ग नाम के समान नामों वाली तालिकाएँ बनाते हैं। जैसे-जैसे अधिक से अधिक उपकरणों का उपयोग किया जा रहा है, एकवचन नाम एक मानक बनता जा रहा है।

A REST API डेवलपर की दुविधा के बारे में और पढ़ें

— श्रेणीबद्ध करनेवाला
स्रोत
39
विलक्षण नाम हमेशा वहाँ होते हैं /clothe/12/trouser/34 :)
— गर्ट अर्नोल्ड
18
@GertArnold शब्द clotheएक क्रिया है। बाकी एपीआई आमतौर पर संज्ञाओं से चिपके रहते हैं जब संसाधनों के बारे में बात करते हैं और क्रियाओं का वर्णन करते समय क्रियाओं का उपयोग करते हैं। एकवचन रूप है clout, लेकिन पुरातन है और संभवतः अधिक उपयुक्त रूप से प्रतिस्थापित किया जाएगा garment।
— स्टीव बुज़ोनस
@SteveBuzonas और पतलून और धूप का चश्मा के लिए?
— कोरे तुगे
32

जबकि सबसे प्रचलित प्रथा Restful apis है जहाँ बहुवचन का उपयोग किया जाता है उदा /api/resources/123, वहाँ एक विशेष मामला है जहाँ मुझे बहुवचन नामों की तुलना में एक विलक्षण नाम का उपयोग अधिक उपयुक्त / अभिव्यंजक लगता है। यह एक-से-एक रिश्तों का मामला है। विशेष रूप से यदि लक्ष्य आइटम एक मान ऑब्जेक्ट (डोमेन-संचालित-डिज़ाइन प्रतिमान में) है।

आइए मान लें कि हर संसाधन में एक-से-एक है, accessLogजिसे मूल्य ऑब्जेक्ट के रूप में मॉडल किया जा सकता है, न कि एक इकाई इसलिए कोई आईडी नहीं। इसे व्यक्त किया जा सकता है /api/resources/123/accessLog। सामान्य क्रियाएं (POST, PUT, DELETE, GET) उचित रूप से इरादे को व्यक्त करेंगी और इस तथ्य को भी बताएंगी कि संबंध वास्तव में एक-से-एक है।

— redzedi
स्रोत
4
अच्छा प्रयास। लेकिन यह "accessLogEntries" के रूप में बेहतर होगा। :-)
— टॉम रसेल
8
@TomRussell क्यों? इसके निहितार्थ महत्वपूर्ण हैं। मैं समझता हूं कि जब आप एक पहचानकर्ता द्वारा एक संसाधन तक पहुंच बना रहे हैं, तब भी आप बहुवचन का उपयोग क्यों करेंगे, लेकिन कई-से-एक या एक-से-एक के लिए यह काफी भ्रामक है। एक एपीआई पर विचार करें जो एक मल्टी-लोकेशन कंपनी के लिए स्टाफ सदस्यों का प्रबंधन करता है। प्रत्येक स्टाफ सदस्य एक स्थान पर काम करता है। GET /users/123/locationउस स्थान को लाना चाहिए जो उपयोगकर्ता काम करता है। क्या GET /users/123/locationsवास्तव में एक उपभोक्ता के रूप में भ्रामक नहीं है ?
— कैरी केंडल
1
@CarrieKendall मैं आपकी बात देखता हूं। चूंकि accessLogएक इकाई के बजाय एक विशेषता, या मूल्य के रूप में तैयार किया गया है, इसलिए इसे एकवचन होना चाहिए। यदि आपको ओवर-इंजीनियरिंग के लिए दिया जाता है, तो एक लॉग प्रविष्टि एक इकाई होगी और आपके पास होगी /api/accessLogEntries?resource=123।
— टॉम रसेल
सहमत, हालांकि, मुझे लगता है कि यह सभी चीजों के बहुवचन को तोड़ने का सम्मेलन करता है। यह एक मुश्किल है। मेरे लिए, यह एक एपीआई की तुलना में महत्वपूर्ण है, सीधे-सीधे यानी प्रलेखन पहले से ही सीधे-आगे के कार्यान्वयन की प्रशंसा करना चाहिए।
— कैरी केंडल
मैं एक सिस्टम या डेटाबेस व्यक्ति की तुलना में एक प्रोग्रामर से अधिक हूं इसलिए मैं एक एपीआई को पसंद करता हूं जो सम्मेलन का पालन करने के बजाय एक कहानी बताता है। हालांकि स्वचालित प्रलेखन के निहितार्थ वास्तविक हैं।
— टॉम रसेल
26

डेटाबेस तालिका नामों की प्रचलित प्रवृत्ति का पालन क्यों नहीं किया जाता है, जहां एक विलक्षण रूप आमतौर पर स्वीकार किया जाता है? वहाँ किया गया था, कि - पुन: उपयोग करते हैं।

तालिका नामकरण दुविधा: एकवचन बनाम बहुवचन नाम

— स्लावोमिर
स्रोत
8
दास ऑटो, डाय ऑटो से बेहतर है। इसके अलावा, अंग्रेजी बहुवचन सम्मेलनों के अनुरूप नहीं हैं।
— फ्लेवर्सस्केप
7
संसाधन नाम स्थान शब्दार्थ का विषय है, कार्यान्वयन का नहीं। इसलिए, डीबी तालिकाओं की उपमा का उपयोग करना, बहुत भाग्यशाली नहीं है। डीबी-एस के साथ काम करते समय आप केवल तालिकाओं में हेरफेर कर रहे हैं, हालांकि निश्चित रूप से आप सामग्री (पंक्तियों) को प्रभावित कर सकते हैं, लेकिन आरईएसटी में सीधे एकल संसाधन में हेरफेर करने के लिए कोई बाधा नहीं है ।
— arpadf
3
मुझे लगता है कि यह एक अच्छा सादृश्य है, लेकिन यह तय करने की तुलना में अधिक महत्वपूर्ण है कि चाहे जो भी हो, एकवचन या बहुवचन में जाना चाहिए। आप उपयोगकर्ताओं में सम्मिलित नहीं होंगे और फिर उपयोगकर्ता से चयन करेंगे। वही नियम REST संसाधनों पर लागू होना चाहिए - जो आप कर रहे हैं, उसके आधार पर उनका नाम न बदलें।
— टोड मेनियर
3
इसकी न केवल तालिका के नाम, इसके ओओ में वर्ग नामों की तुलना (मेरी कक्षा को ग्राहक नहीं ग्राहक कहा जाएगा)।
— बट्टेव
इस मामले में, शब्दार्थ केवल "पहले से परिभाषित" प्रवृत्तियों को स्वीकार करने के लिए बहुत महत्वपूर्ण है
— कातानी सिमोन
19

मुझे यह देखकर आश्चर्य होता है कि इतने सारे लोग बहुवचन संज्ञा बैंडवागन पर कूदेंगे। बहुवचन रूपांतरणों के लिए एकवचन को लागू करते समय, क्या आप अनियमित बहुवचन संज्ञाओं का ध्यान रख रहे हैं? क्या आपको दर्द होता है?

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)
— स्टीफन एरिकसन
स्रोत
5
मैं यहाँ चिंता नहीं समझता। हम प्रोग्राम से बहुवचन में एकवचन को बदलने के लिए नहीं हैं। उपरोक्त बहुवचन रूपों में से अधिकांश अच्छी तरह से ज्ञात हैं, और एक चिंता नहीं होनी चाहिए। यदि किसी के पास अंग्रेजी का खराब ज्ञान है, तो वह आपके चर के किसी भी हिस्से को गलत तरीके से लिखने वाला है। इसके अलावा, अपने तर्क से, क्या आप स्रोत कोड में संग्रह को संदर्भित करने के लिए एकवचन रूपों का उपयोग करने की भी सलाह देते हैं?
— किशोर बोर
1
अंग्रेजी शब्द हैं जो उस बिंदु के अनियमित हैं जहां यह अक्सर एंग्लोस्फियर के भीतर भी एक समस्या है और वे आमतौर पर इंडेक्स / इंडेक्स / इंडेक्स, वर्टिक्स / वर्टेक्स / वर्टिस, मैट्रिक्स / मैट्रिक्स / मैट्रेस, त्रिज्या / त्रिज्या / जैसे शब्दों का उपयोग करते हैं। radii, आदि मुझे REST पथ को बहुवचन बनाने में कोई समस्या नहीं दिखती है, क्योंकि यदि वे सभी लगातार विलक्षण हैं, तो यह सभी के लिए अधिक स्पष्ट है।
— डैम
@kishorborate, URI के रूप में बहुवचन का उपयोग करना अधिक मूल-प्रवण है, यहां तक ​​कि देशी अंग्रेजी बोलने वालों के लिए भी। जैसा कि डैम इंगित करता है, इंडेक्स / इंडेक्स / इंडेक्स जैसे प्लुरल अधिक समस्याएं पेश कर रहे हैं। और बेशुमार संज्ञाएं हैं। बहुवचन के साथ बेशुमार संज्ञाओं को मिलाना दूसरी समस्या है। प्रोग्रामर्स के लिए इन पर अधिक समय बिताना कठिन क्यों है? मैं हर चीज के लिए एकवचन का उपयोग करने का सुझाव देता हूं। यदि कोई / {आईडी} है, तो एपीआई को एक भी रिकॉर्ड वापस करना चाहिए। यदि कोई / {id} नहीं है जो निम्न प्रकार है, तो एपीआई को संग्रह वापस करना चाहिए।
— Daming फू
3
@DamingFu एकवचन संसाधन हमेशा आईडी से जुड़ा नहीं हो सकता है। जैसे। / user / {id} / nickName इसे देखकर, यह स्पष्ट नहीं है कि क्या यह उपनाम या एकल उपनाम का सूची लौटाएगा? इसलिए, बहुवचन रूपों का उपयोग करते समय API अधिक सहज होते हैं। हां, कुछ शब्दों में अनियमित बहुवचन रूप होंगे। किसी के लिए, जो बहुवचन रूप पढ़ रहा है, कोई मुद्दा नहीं है। यह केवल API हस्ताक्षर लिखते समय ही जारी होता है। लेकिन ऐसे शब्दों की आवृत्ति अधिक नहीं है, साथ ही, किसी भी शब्द के बहुवचन रूप को खोजने में समय नहीं लगता है। यह व्यापार बंद है जिसे हमें एपीआई को अधिक सहज बनाने के लिए स्वीकार करना चाहिए।
— किशोर बोर
15

एपीआई उपभोक्ता के दृष्टिकोण से, समापन बिंदु अनुमानित होना चाहिए

आदर्श रूप में ...

  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सभी संसाधनों को हटाना चाहिए; बस मजाक कर रहे हैं: 400 स्थिति कोड
  11. DELETE /resource/id/{resourceId}

यह दृष्टिकोण सबसे अधिक लचीला और सुविधा संपन्न है, लेकिन विकसित होने में सबसे अधिक समय लगता है। इसलिए, यदि आप जल्दी में हैं (जो कि सॉफ़्टवेयर डेवलपमेंट के मामले में हमेशा होता है) तो बस अपने समापन बिंदु resourceया बहुवचन रूप को नाम दें resources। मैं एकवचन रूप को पसंद करता हूं क्योंकि यह आपको 's' में सभी बहुवचन रूपों के समाप्त होने के बाद से प्रोग्राम को आत्मनिरीक्षण और मूल्यांकन करने का विकल्प देता है।

सभी ने कहा है कि, जिस भी कारण से सबसे अधिक इस्तेमाल किया जाने वाला अभ्यास डेवलपर ने चुना है, वह बहुवचन रूप का उपयोग करना है। यह अंततः वह मार्ग है जिसे मैंने चुना है और यदि आप लोकप्रिय एपिस जैसे githubऔर को देखते हैं twitter, तो यह वही है जो वे करते हैं।

निर्णय लेने के कुछ मापदंड हो सकते हैं:

  1. मेरे समय की कमी क्या हैं?
  2. मैं अपने उपभोक्ताओं को क्या ऑपरेशन करने की अनुमति दूंगा?
  3. अनुरोध और परिणाम पेलोड कैसा दिखता है?
  4. क्या मैं अपने कोड में प्रतिबिंब का उपयोग करने और URI को पार्स करने में सक्षम होना चाहता हूं?

ये आप पर निर्भर है। आप जो भी करें सुसंगत।

— cosbor11
स्रोत
1
ऐसा लगता है कि बहुवचन रूप को चुना गया है क्योंकि डेवलपर्स को लगता है कि सभी संसाधन स्वाभाविक रूप से कुछ संग्रह का हिस्सा हैं। हालांकि, "स्वीकार किए गए सम्मेलन" से संकेत मिलता है कि POST /usersइसे संग्रह में जोड़ते हुए एक एकल उपयोगकर्ता बनाना चाहिए। मैं असहमत हूं। POST /usersउपयोगकर्ताओं की एक सूची बनानी चाहिए (भले ही वह 1 की सूची हो), जहां POST /userठीक एक उपयोगकर्ता बनाना चाहिए। मुझे कोई कारण नहीं है कि दोनों बहुवचन और एकवचन संसाधन समापन बिंदु मौजूद नहीं हो सकते। वे अलग-अलग व्यवहारों का वर्णन करते हैं, और उनके कार्य को आश्चर्यचकित नहीं करना चाहिए।
— क्रश
क्या मार्ग में संसाधन आईडी निर्दिष्ट करने के लिए एक सम्मेलन नहीं है? यदि हां, तो यह व्यापक रूप से उपेक्षित प्रतीत होता है। उदाहरण के लिए, POST users/<id>एक नया उपयोगकर्ता बनाएगा।
— टॉम रसेल
1
@TomRussell आमतौर पर सर्वर आईडी बनाता है, इसलिए आप आईडी को अभी तक नहीं जान पाएंगे।
— एलेक्स
3
@TomRussell, जब ग्राहक एक नया संसाधन बनाते समय (एक प्रकार की) आईडी निर्धारित करता है, तो PUT /users/<id>इसके बजाय इसका उपयोग करना अधिक आम है POST। POSTव्याख्या को "इस संग्रह में जोड़ें, और आईडी को उसी के हिस्से के रूप में निर्धारित करें"। PUTव्याख्या "इस आईडी के साथ इस संसाधन को अपडेट (या जोड़ें) करें।" इस सिद्धांत की लंबी व्याख्या के लिए restcookbook.com/HTTP%20Methods/put-vs-post देखें ।
— जोकेम शुल्लेनोपॉपर
मुझे विश्वास नहीं है कि ट्विटर्स एपीआई की तुलना उचित है क्योंकि वे अपने सभी समापन बिंदुओं के लिए बहुवचन रूप का उपयोग करते हैं। वे एक ही तत्वों के लिए बहुवचन और एकवचन का मिश्रण नहीं करते हैं।
— एंड्रयू टी फिनेल
7

मेरे दो सेंट: विधियाँ जो अपना समय बहुवचन से बदलकर एकवचन या वाइसवर्स में बिताती हैं, वे सीपीयू चक्रों की बर्बादी हैं। मैं पुराना स्कूल हो सकता हूं, लेकिन मेरे समय में जैसे चीजें समान थीं। मैं लोगों से संबंधित तरीकों को कैसे देखूं? कोई भी नियमित एक्सपेक्टेशन व्यक्ति और लोगों को अवांछनीय दुष्प्रभावों के बिना कवर नहीं करेगा।

इंग्लिश प्लुरल बहुत मनमाना हो सकता है और वे कोड को अनावश्यक रूप से एनकाउंटर करते हैं। एक नामकरण सम्मेलन के लिए छड़ी। कंप्यूटर भाषाओं को गणितीय स्पष्टता के बारे में माना जाता था, प्राकृतिक भाषा की नकल करने के बारे में नहीं।

— Guichito
स्रोत
2
यह पता कोड है जो "ऑटो जनरेट / मैंगल" एंडपॉइंट्स की कोशिश करता है (कई रायित पुस्तकालय हैं जो बहुलता / विलक्षणता और मानचित्र का प्रयास करते हैं); हालाँकि, यह सही शब्द चुनने की तुलना में स्पष्ट रूप से चुने गए समापन बिंदु नामों पर लागू होता है (इसकी परवाह किए बिना कि यह कैसे बहुवचन है)।
— user2864740
6

मैं सादगी और स्थिरता दोनों के लिए एकवचन रूप का उपयोग करना पसंद करता हूं।

उदाहरण के लिए, निम्नलिखित यूआरएल पर विचार करना:

/ ग्राहक / 1

मैं ग्राहक को ग्राहक संग्रह के रूप में मानूंगा, लेकिन सादगी के लिए, संग्रह का हिस्सा हटा दिया जाता है।

एक और उदाहरण:

/ उपकरण / 1

इस मामले में, उपकरण सही बहुवचन रूप नहीं है। इसलिए इसे उपकरण संग्रह के रूप में मानना ​​और सरलता के लिए संग्रह को हटाना ग्राहक के मामले के अनुरूप है।

— ivxivx
स्रोत
2
POST / ग्राहक को लगता है कि वह केवल और केवल ग्राहक को बदलने जा रहा है। विलक्षण संसाधन नामों का उपयोग करने के साथ यह मेरा सबसे बड़ा दु: ख है।
— एंड्रयू टी फिनेल
2
@ andrew-t-finnell POST /customerबहुत काम नहीं करना चाहिए - एक एकल ग्राहक डालें?
— डोनमुट्टी
यह एकल ग्राहक को ग्राहकों के संग्रह में सम्मिलित करता है। POST /customerमुझे लगता है जैसे कि यह theग्राहक के लिए POST'ing है । ग्राहकों का संग्रह नहीं। हालाँकि, मैं मानता हूँ कि बहुवचन या बहुवचन एक पसंद है। जब तक वे दूसरे उत्तर की तरह मिश्रित नहीं होते। यह अविश्वसनीय रूप से भ्रामक होगा।
— एंड्रयू टी फिनेल
"ग्राहक के लिए पोस्टिंग" इस मामले में कोई मतलब नहीं है। POST प्रतिस्थापित नहीं करता है, यह सम्मिलित करता है। हो सकता है कि अगर यह POST / ग्राहक / 1 होता तो मैं दुविधा को देख सकता था, लेकिन यहां तक ​​कि REST के नजरिए से बहुत मतलब नहीं है, क्योंकि आप क्या सम्मिलित कर रहे हैं? यह होगा / ग्राहक / 1 / चालान या / ग्राहक / 1 / रसीद, आदि
— damd
5

मार्ग में एक आईडी को एक सूची के सूचकांक के समान देखा जाना चाहिए, और नामकरण तदनुसार आगे बढ़ना चाहिए।

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
— TiggerToo
स्रोत
4

नामकरण सम्मेलनों के साथ, यह आमतौर पर "बस एक लेने और उससे चिपकना" कहना सुरक्षित है, जो समझ में आता है।

हालाँकि, बहुत से लोगों को REST समझाने के बाद, फ़ाइल सिस्टम पर पथ के रूप में समापन बिंदुओं का प्रतिनिधित्व करना इसे करने का सबसे स्पष्ट तरीका है।
यह स्टेटलेस है (फाइलें या तो मौजूद हैं या मौजूद नहीं हैं), पदानुक्रमित, सरल और परिचित - आप पहले से ही जानते हैं कि स्थैतिक फ़ाइलों का उपयोग कैसे किया जाए, चाहे स्थानीय रूप से या http के माध्यम से।

और उस संदर्भ में, भाषाई नियम आपको केवल निम्नलिखित के रूप में प्राप्त कर सकते हैं:

एक निर्देशिका में कई फाइलें और / या उप-निर्देशिकाएं हो सकती हैं, और इसलिए इसका नाम बहुवचन रूप में होना चाहिए।

और मुझे वह पसंद है।
हालाँकि, दूसरी ओर - यह आपकी निर्देशिका है, आप इसे "a-resource-or-multiple-resource" नाम दे सकते हैं यदि आप यही चाहते हैं। यह वास्तव में महत्वपूर्ण बात नहीं है।

यह महत्वपूर्ण है कि यदि आप "संसाधन" (जिसके परिणामस्वरूप /resourceS/123) नामक एक निर्देशिका के तहत "123" नामक एक फ़ाइल डालते हैं , तो आप इसके माध्यम से सुलभ होने की उम्मीद नहीं कर सकते /resource/123।

इसे जितना हो सके उससे अधिक स्मार्ट बनाने की कोशिश न करें - आपके द्वारा वर्तमान में उपयोग किए जा रहे संसाधनों की गिनती के आधार पर बहुवचन से बदलकर सिंग्लूर हो सकता है, लेकिन यह कुछ के लिए सौंदर्य की दृष्टि से मनभावन हो सकता है, लेकिन यह प्रभावी नहीं है और इसमें कोई मतलब नहीं है पदानुक्रमित प्रणाली।

नोट: तकनीकी रूप से, आप "प्रतीकात्मक लिंक" बना सकते हैं, ताकि इसके /resources/123माध्यम से भी पहुँचा जा सके /resource/123, लेकिन पूर्व में अभी भी मौजूद है!

— Narf
स्रोत
3

Google के API डिज़ाइन मार्गदर्शिका पर एक नज़र डालें : संसाधन नामकरण संसाधनों के लिए एक और नाम लेते हैं।

संक्षेप में:

  • संग्रह का नाम बहुवचन के साथ रखा गया है।
  • व्यक्तिगत संसाधनों को एक स्ट्रिंग के साथ नाम दिया गया है। 
|--------------------------+---------------+-------------------+---------------+--------------|
| API Service Name         | Collection ID | Resource ID       | Collection ID | Resource ID  |
|--------------------------+---------------+-------------------+---------------+--------------|
| //mail.googleapis.com    | /users        | /name@example.com | /settings     | /customFrom  |
| //storage.googleapis.com | /buckets      | /bucket-id        | /objects      | /object-id   |
|--------------------------+---------------+-------------------+---------------+--------------|

यदि आप इस विषय के बारे में सोच रहे हैं तो यह पढ़ने योग्य है।

— शैनन मैथ्यू
स्रोत
2

सभी तरीकों के लिए बहुवचन का उपयोग करना कम से कम एक पहलू में अधिक व्यावहारिक है: यदि आप पोस्टमैन (या समान उपकरण) का उपयोग करके एक संसाधन एपीआई का विकास और परीक्षण कर रहे हैं, तो आपको GET से PUT से POST आदि पर स्विच करते समय URI को संपादित करने की आवश्यकता नहीं है। ।

— पाउलो मर्सन
स्रोत
1
यह मेरे लिए एक तर्क नहीं है क्योंकि पोस्टमैन संग्रह प्रदान करता है, इसलिए आप सभी संसाधनों को विभिन्न संग्रह वस्तुओं के रूप में सहेज सकते हैं और उन्हें व्यक्तिगत रूप से परीक्षण कर सकते हैं। आप सभी संग्रह से संसाधन का चयन कर रहे हैं, आपको हर समय मापदंडों / विधियों / आदि को संपादित करने की आवश्यकता नहीं है।
— विरोन
1

दोनों प्रतिनिधित्व उपयोगी हैं। मैंने काफी समय से सुविधा के लिए एकवचन का उपयोग किया था, विभक्ति मुश्किल हो सकती है। कड़ाई से विलक्षण REST एपीआई विकसित करने में मेरा अनुभव, समापन बिंदु का उपभोग करने वाले डेवलपर्स में निश्चितता की कमी है कि परिणाम का आकार क्या हो सकता है। अब मैं उस शब्द का उपयोग करना पसंद करता हूं जो प्रतिक्रिया के आकार का सबसे अच्छा वर्णन करता है।

यदि आपके सभी संसाधन शीर्ष स्तर के हैं, तो आप विलक्षण अभ्यावेदन के साथ दूर हो सकते हैं। विभक्ति से बचना बड़ी जीत है।

यदि आप संबंधों पर प्रश्नों का प्रतिनिधित्व करने के लिए किसी भी प्रकार की गहरी लिंकिंग कर रहे हैं, तो आपके एपीआई के खिलाफ लिखने वाले डेवलपर्स एक सख्त सम्मेलन करके सहायता प्राप्त कर सकते हैं।

मेरा अधिवेशन यह है कि URI में गहराई का प्रत्येक स्तर मूल संसाधन के साथ सहभागिता का वर्णन कर रहा है, और पूर्ण URI को संक्षेप में वर्णन करना चाहिए कि क्या पुनर्प्राप्त किया जा रहा है।

मान लीजिए हमारे पास निम्नलिखित मॉडल है।

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

— स्टीव बुज़ोनस
स्रोत
1

मुझे पता है कि ज्यादातर लोग यह तय करने के बीच हैं कि क्या बहुवचन या एकवचन का उपयोग करना है। यहां जिस मुद्दे को संबोधित नहीं किया गया है, वह यह है कि ग्राहक को यह जानना होगा कि आप किसका उपयोग कर रहे हैं, और वे हमेशा गलती करने की संभावना रखते हैं। यहीं से मेरा सुझाव आता है।

कैसे दोनों के बारे में? और इसके द्वारा, मेरा मतलब है कि आपके पूरे एपीआई के लिए एकवचन का उपयोग करें और फिर बहुवचन रूप में किए गए आगे के अनुरोधों के लिए मार्ग बनाएं। उदाहरण के लिए:

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

आपको चित्र मिल जाएगा। कोई भी गलत, न्यूनतम प्रयास नहीं है, और ग्राहक हमेशा इसे सही पाएंगे।

— wynnset
स्रोत
1
यदि आप 302 रीडायरेक्ट कर रहे हैं और आपका कैश दो बार सब कुछ स्टोर कर रहा है, तो आपने अपना कैश गलत सेट किया है। कैश को 302 रीडायरेक्ट स्टोर करने की आवश्यकता नहीं है।
— 18'18
2
यदि आप क्लाइंट हमेशा उपयोग करते हैं /resourcesऔर हमेशा के लिए पुनर्निर्देशित होते हैं /resource, तो आपने इसे गलत किया है। यदि कोई व्यक्ति आपके एपीआई का उपयोग करता है, तो वे या तो सीधे सही URL का उपयोग कर सकते हैं या पुनर्निर्देशित हो सकते हैं (जो काम करता है लेकिन गलत है) और यह आप थे जिन्होंने गलत तरीके से खोला।
— मेआर्टिनस
"गलत" से आपका मतलब क्या है - यह बहुत व्यक्तिपरक नहीं है। यह वास्तव में गलत नहीं है क्योंकि यह काम करता है।
— १
इससे रखरखाव की लागत, और समझ की लागत, और आवश्यक कोड की मात्रा बढ़ जाती है।
— Sheppard
1

मुझे {id}उप-संसाधनों के साथ यूआरएल के हिस्से को ओवरलैप करते हुए देखना पसंद नहीं है , क्योंकि 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

कोई भी अस्पष्टता नहीं है, और संसाधन का बहुवचन या एकवचन नामकरण उपयोगकर्ता के लिए एक संकेत है कि वे क्या उम्मीद कर सकते हैं (सूची या वस्तु)। idS पर कोई प्रतिबंध नहीं है , सैद्धांतिक रूप से यह संभव है कि newउप-संसाधन नाम के साथ उपयोगकर्ता को ओवरलैप किए बिना आईडी के साथ संभव हो ।

— john16384
स्रोत
1

एकवचन का उपयोग करें और उदाहरण के लिए "व्यवसाय निर्देशिका" में देखे गए अंग्रेजी सम्मेलन का लाभ उठाएं।

बहुत सी चीजें इस तरह से पढ़ती हैं: "बुक केस", "डॉग पैक", "आर्ट गैलरी", "फिल्म फेस्टिवल", "कार लॉट", आदि।

यह आसानी से दाएं से बाएं 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}

समापन में, HTTP केवल एक अनुरोध के लिए एक ही प्रतिक्रिया हो सकती है। एक मार्ग हमेशा एक विलक्षण चीज़ का जिक्र करता है।

— सैमुअल डेनियलसन
स्रोत
-1

मेरे लिए plurals संग्रह में हेरफेर करते हैं , जबकि एकवचन उस संग्रह के अंदर आइटम में हेरफेर करते हैं ।

संग्रह GET / POST / DELETE विधियों की अनुमति देता है

आइटम GET / PUT / DELETE विधियों की अनुमति देता है

उदाहरण के लिए

POST on / छात्रों को स्कूल में एक नया छात्र जोड़ देगा।

DELETE ऑन / स्टूडेंट्स स्कूल के सभी छात्रों को हटा देगा।

DELETE on / student / 123 स्कूल से छात्र 123 को हटा देगा।

यह महत्वहीन लग सकता है लेकिन कुछ इंजीनियर कभी-कभी आईडी भूल जाते हैं। यदि मार्ग हमेशा बहुवचन था और एक DELETE प्रदर्शन किया था, तो आप गलती से अपना डेटा मिटा सकते हैं। जबकि एकवचन पर आईडी गुम होने पर वापस नहीं मिला 404 मार्ग वापस आ जाएगा।

उदाहरण के लिए विस्तार करने के लिए अगर एपीआई को कई स्कूलों का पर्दाफाश करना था, तो कुछ ऐसा है

/ स्कूल / एबीसी / छात्रों पर DELETE स्कूल के सभी छात्रों को हटा देगा abc।

कभी-कभी सही शब्द चुनना अपने आप में एक चुनौती है, लेकिन मुझे संग्रह के लिए बहुलता बनाए रखना पसंद है। जैसे cart_itemsया cart/itemsठीक लगता है। इसके विपरीत हटाने में cart, कार्ट ऑब्जेक्ट को स्वयं हटा देता है और कार्ट के भीतर आइटम नहीं;)।

— ruralcoder
स्रोत
क्या यह विभाजित नहीं होना चाहिए / कार्ट और / कार्ट / आइटम (आइटम) वैसे भी? तब आप संपूर्ण कार्ट (जैसे एक डिलीट) या अलग-अलग आइटम को संबोधित कर सकते हैं?
— रोब ग्रांट
@RobertGrant "/ कार्ट / आइटम / 123" नहीं होगा? (उदा। "कार्ट" और "कार्ट" क्यों नहीं है, नियम 'हमेशा बहुवचन' है?)
— user2864740
1
मेरा तर्क है कि यदि उत्पादन कोड की जाँच की जाती है, तो सभी के कार्ट आइटम को हटाने में सक्षम है, नामकरण सम्मेलन की तुलना में बड़े मुद्दे हैं। संभावना है कि वे एक आईडी पर 's' याद रखते हैं, वह बहुत कम है।
— एंड्रयू टी फिनेल
क्या कोई कभी एक समापन बिंदु बना सकता है जो बस एक पूरे संग्रह को हटा देता है? मेरे लिए बेहद खतरनाक लगता है, और शायद यह भी कि क्यों वास्तव में बैच को हटाने का समर्थन नहीं करता है। (आपको सरणी को किसी ऑब्जेक्ट में लपेटना होगा)। अगर मुझे पूरी तरह से एक संग्रह को हटाने के लिए एक समापन बिंदु की आवश्यकता है, तो मुझे यकीन है कि यूआरआई बहुत अनूठा था, और निश्चित रूप से POST के समान नहीं है
— cnps
-1

कैसा रहेगा:

/resource/(नहीं /resource)

/resource/ इसका मतलब यह है कि एक फ़ोल्डर में "संसाधन" नामक कुछ है, यह एक "resouce" फ़ोल्डर है।

और मुझे यह भी लगता है कि डेटाबेस तालिकाओं का नामकरण सम्मेलन समान है, उदाहरण के लिए, 'उपयोगकर्ता' नामक एक तालिका "उपयोगकर्ता तालिका" है, इसमें "उपयोगकर्ता" नामक कुछ है।

— chrisyue
स्रोत
-2

मैं दोनों बहुवचन ( /resources) और एकवचन ( /resource/{id}) का उपयोग करना पसंद करता हूं क्योंकि मुझे लगता है कि यह संसाधनों के संग्रह पर काम करने और एकल संसाधन पर काम करने के बीच तर्क को अधिक स्पष्ट रूप से अलग करता है।

इसके एक महत्वपूर्ण दुष्परिणाम के रूप में, यह गलत तरीके से एपीआई का उपयोग करके किसी को रोकने में भी मदद कर सकता है। उदाहरण के लिए, उस मामले पर विचार करें जहां कोई उपयोगकर्ता गलत तरीके से इस तरह के पैरामीटर के रूप में आईडी को निर्दिष्ट करके संसाधन प्राप्त करने की कोशिश करता है:

GET /resources?Id=123

इस स्थिति में, जहां हम बहुवचन संस्करण का उपयोग करते हैं, सर्वर सबसे अधिक संभावना आईडी पैरामीटर की अनदेखी करेगा और सभी संसाधनों की सूची लौटाएगा। यदि उपयोगकर्ता सावधान नहीं है, तो वह सोचेगा कि कॉल सफल रहा और सूची में पहले संसाधन का उपयोग करें।

दूसरी ओर, एकवचन रूप का उपयोग करते समय: 

GET /resource?Id=123

सर्वर संभवतः एक त्रुटि लौटाएगा क्योंकि आईडी सही तरीके से निर्दिष्ट नहीं है, और उपयोगकर्ता को यह महसूस करना होगा कि कुछ गलत है।

— pberggreen
स्रोत
1
आप यहाँ मुहावरों को क्यों मिला रहे हैं? आप पहले पैराग्राफ में उचित यूआरआई नोटेशन का उपयोग करते हैं और फिर क्वेरी मापदंडों पर स्विच करते हैं? 123 की आईडी के साथ संसाधन प्राप्त करने के लिए क्वेरी मापदंडों का उपयोग करना यहाँ पूरी तरह से आधार है।
— एंड्रयू टी फिनेल
यह स्पष्ट रूप से एक गलती थी। मैंने अब अपना उत्तर अपडेट कर दिया है। इसे नोटिस करने के लिए धन्यवाद।
— परबग्रीन
फिर से डाउनवोट होने के बाद, मैंने जो कुछ लिखा उस पर ध्यान दिया और मुझे एहसास हुआ कि मूल पोस्ट सही थी। मेरा कहना बिल्कुल ठीक था कि यदि उपयोगकर्ता गलत काम करता है, तो वास्तव में बहुवचन + एकवचन का उपयोग करके एक बेहतर त्रुटि संदेश देगा जो केवल बहुवचन का उपयोग कर रहा है।
— पब्बरगिन
मुझे अभी भी लगता है कि यह मुद्दे को भ्रमित कर रहा है। बहुवचन का उपयोग करने का विचार यह है कि यह एक संग्रह है। और अंत में संख्या संग्रह में एक सूचकांक है। क्या होगा यदि आप स्वयं ही प्राप्त / संसाधन करें? एक साथ बहुवचन और एकवचन दोनों का उपयोग करना काफी भ्रामक है। कह / संसाधन / 123 कहते हैं: संसाधन बाल्टी में मेरे संसाधन 123 प्राप्त करें।
— एंड्रयू टी फिनेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.