अन्य एपीआई डिजाइन - विभिन्न मापदंडों लेकिन समान यूआरएल पैटर्न के साथ आरईएसटी के माध्यम से एक संसाधन प्राप्त करना

Question 1

मेरे पास REST url डिज़ाइन से संबंधित एक प्रश्न है। मुझे यहां कुछ प्रासंगिक पोस्ट मिलीं: एक ही संसाधन के अलग-अलग रिप्रेजेंटेटिव रिप्रेजेंटेशन और यहां: विभिन्न फील्ड्स द्वारा GET रिसोर्स के लिए Restful url लेकिन बेस्ट प्रैक्टिस क्या और क्यों हैं, इस पर प्रतिक्रियाएं बिल्कुल स्पष्ट नहीं हैं। यहाँ एक उदाहरण है।

मेरे पास "उपयोगकर्ता" संसाधन का प्रतिनिधित्व करने के लिए अन्य यूआरएल हैं। मैं एक आईडी या एक ईमेल पते के साथ एक उपयोगकर्ता प्राप्त कर सकता हूं लेकिन URL प्रतिनिधित्व दोनों के लिए समान रहता है। बहुत सारे ब्लॉग और किताबों से गुजरते हुए मैंने देखा कि लोग कई अलग-अलग तरीकों से ऐसा करते रहे हैं। उदाहरण के लिए

इस अभ्यास को एक पुस्तक में पढ़ें और कहीं-कहीं स्टैकओवरफ़्लो पर (मैं फिर से लिंक नहीं खोज सकता)

GET /users/id={id}
GET /users/email={email}

इस अभ्यास को बहुत सारे ब्लॉग पर पढ़ें

GET /users/{id}
GET /users/email/{email}

सामान्य रूप से url द्वारा दर्शाए गए संसाधनों के परिणामों को फ़िल्टर करने के लिए क्वेरी पैराम्स का उपयोग किया जाता है, लेकिन मैंने इस अभ्यास को भी देखा है

GET /users?id={id}
GET /users?email={email}

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

सभी मदद की सराहना की!

Question 2

मेरे अनुभव में, GET /users/{id} GET /users/email/{email}सबसे आम दृष्टिकोण है। यदि कोई उपयोगकर्ता प्रदत्त idया के साथ मौजूद नहीं है, तो मैं 404 नहीं मिलने के तरीकों की भी उम्मीद करूंगा email। मुझे देखकर आश्चर्य नहीं होगा GET /users/id/{id}, या तो (हालांकि मेरी राय में, यह बेमानी है)।

अन्य दृष्टिकोणों पर टिप्पणियाँ

GET /users/id={id} GET /users/email={email}
- मुझे नहीं लगता कि मैंने इसे देखा है, और अगर मैंने इसे देखा, तो यह बहुत भ्रामक होगा। यह लगभग ऐसा है जैसे यह पथ मापदंडों के साथ क्वेरी मापदंडों की नकल करने की कोशिश कर रहा है।
GET /users?id={id} GET /users?email={email}
- मुझे लगता है कि जब आपने फ़िल्टरिंग के लिए क्वेरी पैरामीटर का उपयोग किया था, तो आपने सिर पर कील ठोक दी थी।
- यह कभी के साथ इस संसाधन कॉल करने के लिए फ़ायदेमंद होगा दोनों एक idऔर एक email(जैसे GET /users?id={id}&email={email})? यदि नहीं, तो मैं इस तरह एकल संसाधन विधि का उपयोग नहीं करूंगा।
- मैं फ़िल्टरिंग के लिए वैकल्पिक क्वेरी मापदंडों के साथ उपयोगकर्ताओं की सूची को पुनर्प्राप्त करने के लिए इस विधि की अपेक्षा करूंगा , लेकिन मैं मापदंडों के बीच होने की उम्मीद नहीं करूंगा id, emailया किसी विशिष्ट पहचानकर्ता के साथ। उदाहरण के लिए: GET /users?status=BANNEDप्रतिबंधित उपयोगकर्ताओं की सूची वापस कर सकते हैं।

_{की जाँच करें इस जवाब एक संबंधित सवाल से।}

Question 3

इस व्यावहारिक रूप से देखते हुए, आपको उपयोगकर्ताओं का एक संग्रह मिला है:

/users   # this returns many

प्रत्येक उपयोगकर्ता के पास एक समर्पित संसाधन स्थान है:

/users/{id}    # this returns one

आपको उपयोगकर्ताओं की खोज करने के कई तरीके भी मिले हैं:

/users?email={email}
/users?name=*bob*

चूंकि ये सभी / उपयोगकर्ताओं के लिए क्वेरी पैरामीटर हैं, इसलिए उन्हें सभी सूची वापस करनी चाहिए .. भले ही यह 1 की सूची हो।

मैंने यहाँ व्यावहारिक रेस्टफुल एपीआई डिज़ाइन पर एक ब्लॉग पोस्ट लिखी है जो इस बारे में, अन्य चीजों के बारे में, यहाँ पर बात करती है: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Question 4

उपयोगकर्ता संसाधनों के बारे में

पथ पर /usersआपको हमेशा लौटाए गए उपयोगकर्ता संसाधनों का संग्रह मिलेगा।

रास्ते में /users/[user_id]आप कई चीजें होने की उम्मीद कर सकते हैं:

आपको अपने पहचानकर्ता [user_id] या के साथ उपयोगकर्ता संसाधन का प्रतिनिधित्व करने वाला एक सिंगलटन संसाधन प्राप्त करना चाहिए
यदि कोई उपयोगकर्ता आईडी [user_id] मौजूद है या नहीं तो 404 प्रतिसाद नहीं मिला है
निषिद्ध 401 यदि आपको अनुरोधित उपयोगकर्ता संसाधन तक पहुंचने की अनुमति नहीं है।

प्रत्येक सिंगलटन अपने पथ और पहचानकर्ता द्वारा विशिष्ट रूप से पहचाना जाता है और आप संसाधन खोजने के लिए इनका उपयोग करते हैं। सिंगलटन के लिए कई रास्तों का उपयोग करना संभव नहीं है।

आप /usersक्वेरी पैरामीटर ( GETपैरामीटर) के साथ पथ को क्वेरी कर सकते हैं । यह अनुरोधित मानदंडों को पूरा करने वाले उपयोगकर्ताओं के साथ एक संग्रह लौटाएगा। संग्रह जो लौटाया जाता है, उसमें उपयोगकर्ता संसाधन शामिल होने चाहिए, सभी प्रतिक्रिया में उनके संसाधन पथ की पहचान करते हैं।

पैरामीटर संग्रह के संसाधनों में मौजूद कोई भी क्षेत्र हो सकता है; firstName, lastName,id

ईमेल के बारे में

ईमेल या तो एक संसाधन या उपयोगकर्ता संसाधन की एक संपत्ति / क्षेत्र हो सकता है।

- उपयोगकर्ता की संपत्ति के रूप में ईमेल करें:

यदि फ़ील्ड उपयोगकर्ता की एक संपत्ति है तो उपयोगकर्ता की प्रतिक्रिया कुछ इस तरह दिखाई देगी:

{ 
  id: 1,
  firstName: 'John'
  lastName: 'Doe'
  email: 'john.doe@example.com'
  ...
}

इसका मतलब है कि ईमेल के लिए कोई विशेष समापन बिंदु नहीं है, लेकिन अब आप निम्नलिखित अनुरोध भेजकर एक उपयोगकर्ता को इसके ईमेल से पा सकते हैं /users?email=john.doe@example.com:। कौन से (ईमेल उपयोगकर्ताओं के लिए अद्वितीय हैं) ईमेल से मेल खाने वाले एक उपयोगकर्ता आइटम के साथ एक संग्रह लौटाएगा।

- संसाधन के रूप में ईमेल करें:

लेकिन अगर उपयोगकर्ताओं के ईमेल भी संसाधन हैं। तब आप एक एपीआई बना सकते हैं, /users/[user_id]/emailsजिसमें आईडी के साथ उपयोगकर्ता के लिए ईमेल पतों का संग्रह होता है user_id। /users/[user_id]/emails/[email_id]user_id और ['email_id'] के साथ उपयोगकर्ता का ईमेल लौटाता है। एक पहचानकर्ता के रूप में आप जो भी उपयोग करते हैं, वह आपके ऊपर है, लेकिन मैं एक पूर्णांक से चिपक जाता हूं। DELETEजिस पथ को आप हटाना चाहते हैं, उस ईमेल को पहचानने का अनुरोध करके आप उपयोगकर्ता से एक ईमेल हटा सकते हैं। उदाहरण के लिए तो DELETEपर /users/[user_id]/emails/[email_id]EMAIL_ID कि user_id के साथ उपयोगकर्ता के स्वामित्व में है के साथ ईमेल को नष्ट करेगा। सबसे अधिक संभावना केवल यह है कि उपयोगकर्ता इस डिलीट ऑपरेशन को करने की अनुमति देता है। अन्य उपयोगकर्ताओं को 401 की प्रतिक्रिया मिलेगी।

यदि उपयोगकर्ता के पास केवल एक ईमेल पता हो सकता है, तो आप /users/[user_id]/email इस रिटर्न को सिंगलटन संसाधन से चिपका सकते हैं । उपयोगकर्ता PUTउस यूआरएल पर ईमेल पते को टिंग करके अपना ईमेल पता अपडेट कर सकता है ।