एपीआई

Question

के लिए यूआरएल डिज़ाइन मैं अपने बैकएंड के लिए एक निजी एपिस पर काम कर रहा हूं।
मेरे पास ऐसे संग्रह हैं जिनमें संघ हैं।
प्रत्येक संग्रह से अनुरोध किया जा सकता है, पेजिनेटेड, आप एसोसिएशन के लिए भी पूछ सकते हैं और इस संगठन को पेजिनेट कर सकते हैं।

हम जो यूआरएल डिजाइन का उपयोग करने के बारे में सुनिश्चित नहीं हैं ... हम बारे में सोच रहे:

• /users.json?per_page=10 & संघ = भागों, ऑडिशन & parts_per_page = 5 & auditions_per_page = 5

• /users.json?per_page=10 & संघ [] = भागों & संघ [] = ऑडिशन & parts_per_page = 5 & auditions_per_page = 10

• /users.json?per_page=10 & संघ [ऑडिशन] = सच & संघ [भागों] [per_page] = 5

आप क्या सोचते हैं? आप किसको चुनौती देंगे? क्यूं कर ? क्या यह वैध यूआरएल योजनाओं की तरह नहीं दिख रहा है?

धन्यवाद!

Answer 1

मेरा उत्तर: /users.json। HTTP को बड़े अनाज हाइपर्मियाडिया हस्तांतरण के लिए अनुकूलित किया गया है; कैशिंग इसका एक बड़ा हिस्सा है, और ऊपर दी गई यूआरआई योजनाओं में से कोई भी बहुत कैश-अनुकूल नहीं है।

स्क्विड, उदाहरण के लिए, एक लोकप्रिय HTTP कैश है जो डिफ़ॉल्ट रूप से किसी भी यूआरएल को कैश नहीं करेगा जिसमें क्वेरीस्ट्रिंग है। इसके अलावा, कई क्लाइंट और यहां तक ​​कि सर्वर और मध्यस्थ एक अपरिभाषित क्रम में क्वेरी स्ट्रिंग पैरामीटर उत्पन्न करते हैं और उपभोग करते हैं; वह है, "? ए = 3 & बी = 5" मनमाने ढंग से फिर से लिखा जा सकता है "? बी = 5 & ए = 3"। हालांकि, HTTP कैशिंग के लिए, ऑर्डर मायने रखता है, और दो पेज अलग-अलग कैश किए जाएंगे, भले ही उनके पास एक ही सामग्री हो। जैसे ही आप पैरामीटर जोड़ते हैं, यह समस्या तेजी से बढ़ जाती है।

आप का विरोध दो द्वारा अपने संसाधनों (और उनके अभ्यावेदन) कैशिंग का लाभ लेने के लिए डिजाइन चाहिए लेकिन पूरक तकनीक:

1. बड़ा, एकीकृत अभ्यावेदन में खंडित और आंशिक अभ्यावेदन कम्बाइन, और
2. अलग बड़े , कैश सीमाओं के साथ छोटे प्रतिनिधित्वों में एकीकृत प्रतिनिधित्व (जो लेनदेन सीमाएं होती हैं), लेकिन हाइपरलिंक्स से संबंधित हैं।

आपके मामले में, चरण 1 क्लाइंट के लिए किसी भी विकल्प को कॉन्फ़िगर करने के लिए किसी भी विकल्प के बिना संगठनों और भागों को "उपयोगकर्ताओं" प्रतिनिधित्व में जोड़ता है, जो कि कितने और कितने हैं। इससे आपको सभी क्वेरीस्ट्रिंग विकल्पों के कारण प्रतिक्रियाओं के संयोजक विस्फोट के साथ अपने (और उनके) कैश को अधिभारित किए बिना एकल प्रतिक्रिया प्रतिनिधित्व को आक्रामक रूप से कैश करने की अनुमति मिल जाएगी।

चरण 2 का अर्थ है /users.json अलग "उपयोगकर्ता" इकाइयों में से प्रत्येक को "एसोसिएशन" संसाधन और "भागों" संसाधन के साथ अलग करना। तो /users/{id} और /users/{id}/associations और /users/{id}/parts। "/ उपयोगकर्ता" संसाधन तब व्यक्तिगत "/ उपयोगकर्ता/{आईडी}" संसाधनों के लिए हाइपरलिंक्स की एक सरणी देता है, और प्रत्येक "/ उपयोगकर्ता/{आईडी} 'प्रतिनिधित्व में इसके एसोसिएशन और हिस्सों में हाइपरलिंक्स होते हैं (वह हिस्सा अधिक लचीला है- - यह आपके एप्लिकेशन को सीधे उपयोगकर्ता संसाधन में एसोसिएशन और भागों को एम्बेड करने के लिए बेहतर हो सकता है)। इससे आपको अपने पूरे डेटाबेस को कैश किए बिना प्रत्येक "मांग में" संसाधन के लिए प्रतिक्रिया को आक्रामक रूप से कैश करने की अनुमति मिल जाएगी।

फिर आपका उपयोगकर्ता चिल्लाएंगे "लेकिन यह नेटवर्क यातायात के 10 गुना है!" जिस पर आप शांतिपूर्वक जवाब देते हैं, "नहीं, यह नेटवर्क ट्रैफिक 1/10 वां है, क्योंकि 10 में से 9 बार अनुरोधित संसाधन पहले से ही आपके क्लाइंट-साइड (ब्राउज़र) में बैठे हैं कैश (और जब वे नहीं होते हैं, यह सर्वर के कम्प्यूटेशनल संसाधनों में 1/10 वां है क्योंकि वे सर्वर-साइड कैश में बैठे हैं, और जब वे वहां नहीं हैं, तो हम बुद्धिमानी से बचते हैं एच सर्वर पर एक स्मार्ट कैश)। "

बेशक, यदि /users संसाधन कुछ मिलियन नए आगंतुक हर दिन हिट करते हैं, तो आपका अनुकूलन पथ अलग हो सकता है। लेकिन यह आपके उदाहरण यूआरआई योजनाओं के आधार पर ऐसा प्रतीत नहीं होता है।

Answer 2

restful-url टैग के तहत बहुत उपयोगी पोस्ट हैं।

कुछ उपयोगी पोस्ट:

Do REST API URLs have to look like this?

Best practices on using URIs as parameter value in REST calls.

How to create REST URL's without verbs?

Answer 3

मैं 1 एक के लिए जाना होगा। मैं यूआरएल पर [] नोटेशन देखना पसंद नहीं करता, आईएमएचओ क्लाइंट के उपयोग और समझ दोनों के लिए कठिन बनाता है। सुझावों के रूप में कुछ बदलाव।

1) संघ के रूप में, एक सरणी हो रहा है संघों के लिए परिवर्तन (बहुवचन, अगर मैं सही हूँ और यह एक सरणी)

2) आपको एक डिफ़ॉल्ट per_page और एक वैकल्पिक एक डाल करने के लिए कोशिश कर सकते हैं, यहां तक ​​कि समेकित, per_page_parts_audits जैसे कुछ per_page_parts और per_page_auditions दोनों का उपयोग करने के बजाय। यदि आपका एपीआई सार्वजनिक होने के लिए डिज़ाइन किया गया था, तो मैं ऐसा नहीं करूँगा, क्योंकि इसका उपयोग करना आसान हो जाता है लेकिन समझने में मुश्किल होती है, लेकिन जैसा कि आपने पोस्ट किया है, यह एक निजी है .. प्रतिकृति से बचने के लिए एक अच्छा तरीका होना चाहिए।