एक आराम संग्रह में पेजिंग

134

मुझे JSON दस्तावेज़ों के संग्रह ( CouchDB या Persevere ) के लिए एक सीधा REST इंटरफ़ेस को उजागर करने में दिलचस्पी है । समस्या यह है कि GETअगर संग्रह बड़ा है तो संग्रह रूट पर संचालन को कैसे संभालना है।

एक उदाहरण के रूप में, मैं दिखा रहा हूँ कि मैं StackOverflow की Questionsतालिका को उजागर कर रहा हूँ, जहाँ प्रत्येक पंक्ति एक दस्तावेज़ के रूप में उजागर होती है (यह नहीं कि आवश्यक रूप से ऐसी कोई तालिका हो, 'दस्तावेजों' के एक बड़े संग्रह का एक ठोस उदाहरण)। संग्रह पर उपलब्ध कराया जाएगा /db/questionsसामान्य CRUD एपीआई के साथ GET /db/questions/XXX, PUT /db/questions/XXX, POST /db/questionsनाटक में है। संपूर्ण संग्रह को प्राप्त करने का मानक तरीका है, GET /db/questionsलेकिन यदि वह प्रत्येक पंक्ति को JSON ऑब्जेक्ट के रूप में डंप करता है, तो आपको सर्वर के हिस्से पर एक बहुत बड़ा डाउनलोड और बहुत सारा काम मिलेगा।

समाधान, निश्चित रूप से, पेजिंग है। Dojo ने इस समस्या को अपने JsonRestStore में Rangeकस्टम रेंज यूनिट के साथ हेडर का उपयोग करने के एक चतुर RFC2616-संगत विस्तार के माध्यम से हल किया है items। नतीजा यह है 206 Partial Contentकि केवल अनुरोधित सीमा देता है। क्वेरी पैरामीटर पर इस दृष्टिकोण का लाभ यह है कि यह क्वेरी स्ट्रिंग को छोड़ देता है ... क्वेरीज़ (उदाहरण के लिए GET /db/questions/?score>200या किसी चीज़, और हाँ जो एन्कोडेड होगी %3E)।

यह दृष्टिकोण मेरे इच्छित व्यवहार को पूरी तरह से कवर करता है। समस्या यह है कि RFC 2616 निर्दिष्ट करता है कि 206 प्रतिक्रिया (जोर मेरा) पर:

अनुरोध एक रेंज हेडर फ़ील्ड (शामिल होना आवश्यक है अनुभाग 14.35 ) वांछित सीमा का संकेत है, और एक तो रेंज हेडर फ़ील्ड (शामिल हो सकता है अनुभाग 14.27 अनुरोध सशर्त बनाने के लिए)।

यह हेडर के मानक उपयोग के संदर्भ में समझ में आता है, लेकिन एक समस्या है क्योंकि मैं चाहूंगा कि 206 प्रतिसाद होना भोले-भाले ग्राहकों / यादृच्छिक लोगों को संभालने के लिए डिफ़ॉल्ट होना चाहिए।

मैं एक समाधान की तलाश में RFC पर विस्तार से जा चुका हूं, लेकिन अपने समाधान से नाखुश हूं और एसओ की समस्या पर दिलचस्पी लेता हूं।

मेरे द्वारा लिए गए विचार:

हेडर के 200साथ लौटें Content-Range! - मुझे नहीं लगता कि यह गलत है, लेकिन मैं पसंद करूंगा कि यदि एक अधिक स्पष्ट संकेतक है कि प्रतिक्रिया केवल आंशिक सामग्री है।
रिटर्न400 Range Required - आवश्यक हेडर के लिए एक विशेष 400 प्रतिक्रिया कोड नहीं है, इसलिए डिफ़ॉल्ट त्रुटि का उपयोग करना और हाथ से पढ़ना है। यह वेब ब्राउज़र (या रेसी जैसे कुछ अन्य क्लाइंट) के माध्यम से अन्वेषण को और अधिक कठिन बना देता है।
एक क्वेरी पैरामीटर का उपयोग करें - मानक दृष्टिकोण, लेकिन मैं क्वेरीज़ को ला पर्सिविए की अनुमति देने की उम्मीद कर रहा हूं और यह क्वेरी नेमस्पेस में कटौती करता है।
अभी लौटो 206! - मुझे लगता है कि ज्यादातर ग्राहक बाहर नहीं होंगे, लेकिन मैं RFC में MUST के खिलाफ नहीं जाऊंगा
कल्पना बढ़ाओ! रिटर्न266 Partial Content - बिल्कुल 206 की तरह व्यवहार करता है, लेकिन एक अनुरोध के जवाब में है जिसमें Rangeहेडर नहीं होना चाहिए । मुझे लगता है कि 266 इतना अधिक है कि मुझे टक्कर के मुद्दों में नहीं चलना चाहिए और यह मेरे लिए समझ में आता है, लेकिन मैं इस बारे में स्पष्ट नहीं हूं कि यह वर्जित माना जाता है या नहीं।

मुझे लगता है कि यह एक बहुत ही आम समस्या है और मैं इसे वास्तव में इस तरह से देखना चाहता हूं ताकि मैं या कोई और पहिया को फिर से स्थापित न कर पाए।

जब संग्रह बड़ा होता है तो HTTP के माध्यम से पूर्ण संग्रह को उजागर करने का सबसे अच्छा तरीका क्या है?

— कार्ल गुर्टिन
स्रोत

21

वाह, यह एक प्रश्न का एक अच्छा उदाहरण है जहां कुछ गंभीर सोच पहले की गई है।

— हाइको रूप

एक संभावित वेब एप्लिकेशन में

— पेजिनेशन के

1

जहां तक रेंज हेडर का उपयोग करने में डोजो का दृष्टिकोण है, हालांकि एक्सेप्ट-रेंज्स विस्तार के लिए अनुमति देता है, सभी से मैं बता सकता हूं, रेंज के लिए ईबीएनएफ नहीं करता है: tools.ietf.org/html/rfc2616#section-14.35.2 । युक्ति इंगित करती है Range = "Range" ":" ranges-specifierकि उपकरण में बाद कहां है ।ietf.org/html/rfc2616#section-14.35.1 को केवल "बाइट-रेंज- स्पेसियर " के रूप में वर्णित किया गया है, जिसे "बाइट्स-यूनिट" से शुरू करना चाहिए जिसे स्ट्रिंग "बाइट्स" के रूप में परिभाषित किया गया है। "।

— ब्रेट ज़मीर

2

Content-Rangeहैडर शरीर पर लागू होता है (जब डाउनलोड प्रतिक्रिया के लिए जब बड़ी फ़ाइलों आदि को अपलोड करने के अनुरोध के साथ इस्तेमाल किया जा सकता है, या)। Rangeहैडर एक निश्चित सीमा अनुरोध करने के लिए प्रयोग किया जाता है। 206जब Rangeशीर्ष लेख को अनुरोध में शामिल किया गया हो, तो उसे जवाब देना चाहिए । यदि यह नहीं था, तो प्रतिक्रिया में अभी भी एक Content-Rangeहेडर शामिल हो सकता है , लेकिन प्रतिक्रिया कोड होना चाहिए 200। यह हेडर वास्तव में पेजिंग के लिए आदर्श लगता है।

— स्टिजन डे विट

लेकिन RFC 2616 का कहना है कि "HTTP / 1.1 कार्यान्वयन MAY अन्य इकाइयों का उपयोग करके निर्दिष्ट सीमाओं को अनदेखा करता है।" तो क्या पेजिंग के लिए रेंज हेडर का उपयोग करना एक अच्छा अभ्यास है? coz यह अंतर्संचालनीयता से समझौता कर सकता है।

— चेतन चूलवार

23

मेरी आंत की भावना यह है कि HTTP रेंज एक्सटेंशन आपके उपयोग के मामले के लिए डिज़ाइन नहीं किए गए हैं, और इस प्रकार आपको कोशिश नहीं करनी चाहिए। एक आंशिक प्रतिक्रिया का तात्पर्य है 206, और 206केवल तभी भेजा जाना चाहिए जब क्लाइंट ने इसके लिए कहा हो।

आप एक अलग दृष्टिकोण पर विचार करना चाह सकते हैं, जैसे एटम में एक का उपयोग (जहां डिजाइन द्वारा प्रतिनिधित्व आंशिक हो सकता है, और एक स्थिति 200, और संभावित पेजिंग लिंक के साथ वापस आ जाता है )। RFC 4287 और RFC 5005 देखें ।

— जूलियन रेज़्के
स्रोत

14

Dojo का उपयोग पूरी तरह से कल्पना के भीतर है। यदि सर्वर itemsरेंज यूनिट को नहीं समझता है , तो वह पूर्ण प्रतिक्रिया देता है। मैं एटम से परिचित हूं लेकिन यह रेस्ट पेजिंग का सामान्य समाधान नहीं है। यह किसी एकल मामले का समाधान नहीं है, सामान्य समाधान क्या होना चाहिए। सभी दस्तावेज़ / संग्रह एटम मॉडल में फिट नहीं होते हैं और जब तक आवश्यकता न हो, इसे लागू करने का कोई कारण नहीं है।

— कार्ल गुर्टिन

1

@ कार्लगर्टिन सहमत। बहुत बुरा यह स्वीकृत उत्तर है, क्योंकि ऐसा लगता है कि समुदाय के कई लोग वास्तव में गले लगा रहे हैं Rangeऔर Content-Rangeउद्देश्यों के लिए।

— स्टिजन डे विट

34

मैं वास्तव में आप में से कुछ लोगों से सहमत नहीं हूँ। मैं अपनी REST सेवा के लिए इस सुविधाएँ पर हफ्तों से काम कर रहा हूँ। मैंने जो किया वह वास्तव में सरल है। मेरा समाधान केवल इस बात से समझ में आता है कि REST लोग किस संग्रह को कहते हैं।

क्लाइंट मेस्ट में एक "रेंज" हेडर शामिल होता है जो यह इंगित करता है कि संग्रह के किस भाग को उसकी आवश्यकता है, या अन्यथा अनुरोधित संग्रह को एकल राउंड-ट्रिप में पुनर्प्राप्त करने के लिए बहुत बड़ा होने पर 413 आवश्यक ENOITY TOO LARGE त्रुटि को संभालने के लिए तैयार रहें।

सर्वर एक 206 पार्टिकल कॉन्टेंट रिस्पांस भेजता है, जिसमें कंटेंट-रेंज हैडर निर्दिष्ट करता है कि संसाधन का कौन सा हिस्सा भेजा गया है, और संग्रह के वर्तमान संस्करण की पहचान करने के लिए एक ईटैग हैडर। मैं आमतौर पर एक फेसबुक-जैसे ETag {last_modification_timestamp} - {resource_id} का उपयोग करता हूं, और मैं समझता हूं कि संग्रह का ETag सबसे हाल ही में संशोधित संसाधन है।

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

मैं पिछले-संशोधित / if-Unmodified- चूँकि कैश को ऑप्टिमाइज़ करने के लिए टेंडेम में ETag / If-Match का उपयोग करता हूँ। ब्राउज़रों और परदे के पीछे उनके कैशिंग एल्गोरिदम के लिए एक या दोनों पर भरोसा कर सकते हैं।

मुझे लगता है कि किसी URL को तब तक साफ होना चाहिए जब तक कि उसमें खोज / फ़िल्टर क्वेरी शामिल न हो। यदि आप इसके बारे में सोचते हैं, तो खोज संग्रह के आंशिक दृश्य से ज्यादा कुछ नहीं है। कारों / खोज के बजाय? Q = बीएमडब्ल्यू प्रकार के URL, हमें और कारें देखनी चाहिए? निर्माता = बीएमडब्ल्यू।

— मोहम्मद
स्रोत

क्या आपका मतलब 416 "रिक्वेस्टेड रेंज नॉट सैटिस्फायबल" या "413" रिक्वेस्ट एंटिटी टू वेरी लार्ज?

1

@ मोहम्मद मुझे लगता है कि आप का मतलब है If-Unmodified-Since, जो ई-टैग संस्करण If-Matchके बजाय मेल खाती है If-Modified-Since। उस ने कहा, आप अपने उपयोग के मामले के आधार पर इस बाधा को दूर करने पर भी विचार कर सकते हैं। मान लीजिए कि आपके पास एक संग्रह है जो केवल ऊपर से बढ़ता है (जैसे कुछ "नवीनतम पहले" शैली संग्रह), सबसे खराब जो तब हो सकता है यदि वह संग्रह अनुरोधों के बीच बदलता है, जो उपयोगकर्ता संग्रह के माध्यम से पृष्ठों को दो बार प्रविष्टियां देखता है। (जो अपने आप में भी एक उपयोगी जानकारी है: यह बताता है कि उपयोगकर्ता ने संग्रह बदल दिया है)

— यूजीन बेर्सेव्स्की

20

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

— user247702

@ मोहम्मद मुझे पता है कि यह एक पुराना सवाल है, लेकिन अगर संग्रह का ETag सबसे हाल ही में संशोधित संसाधन का ETag है, तो संग्रह में एक संसाधन को संशोधित करते समय IF- मैच हेडर के किस मूल्य का उपयोग किया जाना चाहिए? संग्रह के साथ लौटे ETag के मूल्य का उपयोग करना गलत है क्योंकि ग्राहक संसाधन को संशोधित करने में सक्षम होगा, यहां तक कि वह संसाधन की अंतिम स्थिति नहीं देखता है।

— मिकेल मार्राचे

8

मैं उपयोग करने के बारे में दृढ़ता से असहमत हूं 413। यह एक त्रुटि कोड है जिसका अर्थ है कि ग्राहक कुछ भेज रहा है जिसे सर्वर आकार के कारण स्वीकार करने से मना करता है। कोई और रास्ता नही! उपकरण देखें ।ietf.org/html/rfc7231#section-6.5.11 (ध्यान दें कि यह अनुरोध पेलोड कहता है । प्रतिक्रिया पेलोड नहीं )

— प्रकुमा

7

आप अभी भी वापस आ सकते हैं Accept-Rangesऔर Content-Rangesएक 200प्रतिक्रिया कोड के साथ। ये दो प्रतिक्रिया हेडर आपको एक ही जानकारी का अनुमान लगाने के लिए पर्याप्त जानकारी देते हैं कि एक 206प्रतिक्रिया कोड स्पष्ट रूप से प्रदान करता है।

मैं Rangeपृष्ठांकन के लिए उपयोग करूंगा , और यह बस 200एक सादे के लिए वापस आ जाएगा GET।

यह 100% RESTful महसूस करता है और किसी भी अधिक कठिन ब्राउज़ कर नहीं है।

संपादित करें: मैंने इस बारे में एक ब्लॉग पोस्ट लिखा है: http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html

— जॉन गिएत्जन
स्रोत

5

यदि प्रतिक्रियाओं का एक से अधिक पृष्ठ है, और आप एक बार में पूरे संग्रह की पेशकश नहीं करना चाहते हैं, तो क्या इसका मतलब है कि कई विकल्प हैं?

के अनुरोध पर /db/questions, 300 Multiple Choicesउन Linkशीर्ष लेखों के साथ लौटें जो निर्दिष्ट करते हैं कि प्रत्येक पृष्ठ के साथ-साथ JSON ऑब्जेक्ट या HTML पृष्ठ URL की सूची के साथ कैसे प्राप्त करें।

Link: <>; rel="http://paged.collection.example/relation/paged"
Link: <>; rel="http://paged.collection.example/relation/paged"
...

आपके पास Linkपरिणामों के प्रत्येक पृष्ठ के लिए एक हेडर होगा (खाली स्ट्रिंग का अर्थ है वर्तमान URL, और URL प्रत्येक पृष्ठ के लिए समान है, बस अलग-अलग श्रेणियों तक पहुँचा जा सकता है), और संबंध को आगामी Linkकल्पना के अनुसार एक कस्टम के रूप में परिभाषित किया गया है । यह संबंध आपके रिवाज 266, या आपके उल्लंघन का वर्णन करेगा 206। ये हेडर आपके मशीन-पठनीय संस्करण हैं, क्योंकि आपके सभी उदाहरणों को वैसे भी एक समझने वाले ग्राहक की आवश्यकता होती है।

(यदि आप "रेंज" मार्ग से चिपके रहते हैं, तो मेरा मानना है कि आपका अपना 2xxरिटर्न कोड है, जैसा कि आपने इसे वर्णित किया है, यहां सबसे अच्छा व्यवहार होगा। आपसे अपेक्षा है कि आप अपने अनुप्रयोगों के लिए ऐसा करें और ऐसे ["HTTP स्थिति कोड" एक्स्टेंसिबल हैं। "], और आपके पास अच्छे कारण हैं।"

300 Multiple Choicesआप कहते हैं कि उपयोगकर्ता एजेंट को चुनने का एक तरीका भी प्रदान करना चाहिए। यदि आपका क्लाइंट समझ रहा है, तो उसे Linkहेडर का उपयोग करना चाहिए । यदि यह एक उपयोगकर्ता मैन्युअल रूप से ब्राउज़ कर रहा है, तो शायद एक विशेष "पृष्ठांकित" रूट संसाधन के लिंक वाला एक HTML पृष्ठ जो URL के आधार पर उस विशेष पृष्ठ को प्रदान करने से निपट सकता है? /humanpage/1/db/questionsया ऐसा कुछ छिपाना?

रिचर्ड लेवासेयर्स की पोस्ट पर टिप्पणियाँ मुझे एक अतिरिक्त विकल्प की याद दिलाती हैं: Acceptशीर्ष लेख (अनुभाग 14.1)। वापस जब oEmbed कल्पना सामने आई, तो मुझे आश्चर्य हुआ कि यह पूरी तरह से HTTP का उपयोग क्यों नहीं किया गया था, और उनका उपयोग करके एक विकल्प लिखा।

रखें 300 Multiple Choices, Linkएक प्रारंभिक अनुभवहीन HTTP के लिए हेडर और HTML पृष्ठ GETहै, लेकिन बजाय उपयोग पर्वतमाला, अपने नए पेजिंग संबंध के उपयोग को परिभाषित है Acceptहैडर। आपका बाद का HTTP अनुरोध इस तरह दिख सकता है:

GET /db/questions HTTP/1.1
Host: paged.collection.example
Accept: application/json;PagingSpec=1.0;page=1

Acceptशीर्ष लेख आपको लगता है कि प्रकार (अपने पृष्ठ संख्या) के लिए एक स्वीकार्य सामग्री प्रकार (आपके JSON वापसी), प्लस एक्स्टेंसिबल मानकों को परिभाषित करने की अनुमति देता है। मेरे oEmbed राइटअप से मेरे नोट्स पर रिफ़िंग करना (यहाँ इसे लिंक नहीं कर सकता, मैं इसे अपनी प्रोफ़ाइल में सूचीबद्ध करूँगा), आप बहुत स्पष्ट हो सकते हैं और यदि आप pageपैरामीटर को मापते हैं, तो आपको एक युक्ति / संबंध संस्करण उपलब्ध कराना होगा। भविष्य में।

— Vitorio
स्रोत

1

+1 लिंक हेडर, लेकिन मैं आम पहले, प्रचलित, अगले, अंतिम रिले, साथ ही RFC5005 के प्रचलित-संग्रह, अगले-संग्रह और वर्तमान की भी सिफारिश करूंगा।

— जोसेफ होल्स्टेन

> / डीबी / प्रश्नों के अनुरोध पर, लिंक हेडर के साथ 300 एकाधिक विकल्प लौटाएं जो निर्दिष्ट करते हैं कि प्रत्येक पृष्ठ पर कैसे जाएं [..] उस (और सबसे शुद्ध रीस्ट डिजाइन के साथ) समस्या यह है कि यह विलंबता के लिए मार रहा है। लक्ष्य नेटवर्क अनुरोधों को कम करना है। पहले अनुरोध में परिणाम प्राप्त होने चाहिए, न कि अधिक अनुरोधों के लिंक जो अंततः हमें आवश्यक डेटा देंगे।

— स्टिजन डे विट

4

संपादित करें:

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

मेरा यह भी मत है कि संसाधनों का एक उप-समूह इसका अपना संसाधन है (रिलेशनल बीजगणित के समान।), इसलिए यह URL में प्रतिनिधित्व के योग्य है।

इसलिए मूल रूप से, मैं हेडर का उपयोग करने के बारे में अपने मूल उत्तर (नीचे) को याद करता हूं।

मुझे लगता है कि आपने अपने स्वयं के प्रश्न का उत्तर दिया है, कम या ज्यादा - सामग्री सीमा के साथ 200 या 206 वापसी और वैकल्पिक रूप से एक क्वेरी पैरामीटर का उपयोग करें। मैं उपयोगकर्ता एजेंट और सामग्री प्रकार सूँघता हूँ और उन पर निर्भर करता है, एक क्वेरी पैरामीटर के लिए जाँच करें। अन्यथा, रेंज हेडर की आवश्यकता होती है।

आपके पास अनिवार्य रूप से परस्पर विरोधी लक्ष्य हैं - लोगों को अपने ब्राउज़र का पता लगाने के लिए उपयोग करें (जो आसानी से कस्टम हेडर की अनुमति नहीं देता है), या लोगों को एक विशेष क्लाइंट का उपयोग करने के लिए मजबूर करता है जो हेडर सेट कर सकता है (जो उन्हें पता लगाने नहीं देता है)।

आप उन्हें अनुरोध के आधार पर विशेष ग्राहक के साथ प्रदान कर सकते हैं - यदि यह एक सादे ब्राउज़र की तरह दिखता है, तो एक छोटा सा अजाक्स एप्लिकेशन भेजें जो पेज को प्रस्तुत करता है और आवश्यक हेडर सेट करता है।

बेशक, इस बात पर भी बहस चल रही है कि क्या इस तरह की चीज़ के लिए URL में सभी आवश्यक स्थिति होनी चाहिए। हेडर का उपयोग करके सीमा को निर्दिष्ट करना कुछ लोगों द्वारा "अन-रेस्टफुल" माना जा सकता है।

एक तरफ के रूप में, यह अच्छा होगा यदि सर्वर "कैन-स्पेसिफ़ाइड: हेडर 1, हेडर 2" हेडर के साथ प्रतिक्रिया दे सकते हैं, और वेब ब्राउज़र यूआई को प्रस्तुत करेंगे, ताकि उपयोगकर्ता यदि चाहें तो मूल्यों को भर सकें।

— रिचर्ड लेवासेउर
स्रोत

जवाब देने के लिए धन्यवाद। मैंने विषय के बारे में सोचा है, लेकिन एक दूसरी राय पाने की उम्मीद कर रहा था। हेडर तर्कों के लिए एक पॉइंटर होना चाहिए?

— कार्ल गर्टिन

यहाँ केवल वही है जिसे मैंने बुकमार्क किया है (टिप्पणियों में चर्चा देखें): barelyenough.org/blog/2008/05/versioning-rest-web-services एक अन्य साइट रूबी के उपयोग के आसपास घूमती है .json, .xml .whatever के निर्धारण में। अनुरोध का सामग्री प्रकार। कुछ उदाहरण: * भाषा - इसे URL में डालने का अर्थ है दूसरे देश के लिए लिंक भेजना गलत भाषा में इसे प्रस्तुत करेगा। * पेजिनेशन - इसे हेडर में रखने का मतलब है कि आप लोगों को उस चीज़ से नहीं जोड़ सकते जो आप देखते हैं

— रिचर्ड लेवसेनुर

* कंटेंट-टाइप: लैंग्वेज और पेजिनेशन प्रॉब्लम का कॉम्बिनेशन - अगर इसके यूआरएल में, क्या होगा अगर क्लाइंट उस कंटेंट टाइप (जैसे, .ajax और a .html एक्सटेंशन) को सपोर्ट नहीं करता है? इसके विपरीत, url में उस सामग्री-प्रकार के बिना, आप यह सुनिश्चित नहीं कर सकते कि एक ही प्रतिनिधित्व दिया गया है। "new ajax site! example.com/cool.ajax" बनाम "कूल आर्टिकल यहाँ: example.com/article.ajax#id.123"।

— रिचर्ड लेवासेउर

2

IMO, यह URL में जाता है या नहीं, इस पर निर्भर करता है कि यह क्या है। मेरा सामान्य नियम है, यदि यह एक ठोस संसाधन (विशिष्ट राज्य में संसाधन, संसाधनों का चयन, या असतत परिणाम) की पहचान करेगा, तो यह URL में जाता है। खोज क्वेश्चन, पेजेशन और रेस्टफुल ट्रांजेक्शन इसके अच्छे उदाहरण हैं। अगर इसकी कुछ चीज़ जो अमूर्त प्रतिनिधित्व को एक ठोस प्रतिनिधित्व में बदलने के लिए आवश्यक है, तो यह हेडर में जाती है। सैद्धांतिक जानकारी और सामग्री-प्रकार इसके अच्छे उदाहरण हैं।

— रिचर्ड लेवासेउर

मैं URL में क्वेरी स्ट्रिंग को संसाधन निर्दिष्ट करने के लिए विकल्प के रूप में सोचता हूं।

— wprl

3

आप एटम फीड प्रोटोकॉल जैसे किसी मॉडल का उपयोग करने पर विचार कर सकते हैं क्योंकि इसमें संग्रह का एक HTTP HTTP मॉडल है और उन्हें हेरफेर करने का तरीका है (जहां पागल का मतलब WebDAV है)।

नहीं है एटम प्रकाशन प्रोटोकॉल जो परिभाषित करता है संग्रह मॉडल और बाकी के संचालन के साथ साथ आप उपयोग कर सकते आरएफसी 5005 - फ़ीड पेजिंग और संग्रहण बड़ा संग्रह के माध्यम से पृष्ठ पर।

एटम XML से JSON सामग्री पर स्विच करने से विचार प्रभावित नहीं होना चाहिए।

— dajobe
स्रोत

3

मुझे लगता है कि यहां वास्तविक समस्या यह है कि कल्पना में कुछ भी नहीं है जो हमें बताता है कि 413 के साथ सामना करने पर स्वचालित रीडायरेक्ट कैसे करना है - अनुरोधित एंटिटी बहुत बड़ी।

मैं हाल ही में इसी समस्या से जूझ रहा था और मैंने Restful Web Services की किताब में प्रेरणा की तलाश की । व्यक्तिगत रूप से मुझे नहीं लगता कि हेडर की आवश्यकता के कारण 206 उपयुक्त है। मेरे विचारों ने मुझे 300 तक पहुंचा दिया, लेकिन मैंने सोचा कि यह अलग-अलग माइम-प्रकारों के लिए अधिक था, इसलिए मैंने देखा कि रिचर्डसन और रूबी ने पृष्ठ 377 के परिशिष्ट बी में इस विषय पर क्या कहा है। उनका सुझाव है कि सर्वर को पसंदीदा चुनना है। प्रतिनिधित्व करना और इसे 200 के साथ वापस भेजना, मूल रूप से इस धारणा को अनदेखा करना कि यह एक 300 होना चाहिए।

वह भी अगले संसाधनों के लिंक की धारणा के साथ, जो हमारे पास परमाणु से है। मेरे द्वारा लागू किए गए समाधान में "अगला" और "पिछले" कुंजियों को जोड़ने के लिए था, जो कि मैं वापस भेज रहा था और इसके साथ किया जा रहा था।

बाद में मैंने सोचना शुरू कर दिया कि शायद करने की बात 307 भेजती है - एक लिंक पर अस्थाई रीडायरेक्ट जो कुछ इस तरह होगा / db / questions / 1,25 - जो मूल URI को विहित संसाधन नाम के रूप में छोड़ देता है, लेकिन यह आपको मिल जाता है उचित रूप से अधीनस्थ संसाधन नाम दिया गया है। यह वह व्यवहार है जिसे मैं 413 में देखना चाहता हूं, लेकिन 307 एक अच्छा समझौता है। हालांकि कोड में वास्तव में यह कोशिश नहीं की है। सबसे बेहतर हाल ही में पूछे गए सवालों की वास्तविक आईडी वाले URL पर रीडायरेक्ट करने के लिए पुनर्निर्देशित करना और भी बेहतर होगा। उदाहरण के लिए यदि प्रत्येक प्रश्न में एक पूर्णांक आईडी है, और सिस्टम में 100 प्रश्न हैं और आप दस सबसे हाल ही में दिखाना चाहते हैं, तो / db / प्रश्नों के अनुरोध 307 / डी / डीबी / प्रश्न / 100,91 पर होना चाहिए।

यह एक बहुत अच्छा सवाल है, इसे पूछने के लिए धन्यवाद। आपने मेरे लिए पुष्टि की कि मैं इसके बारे में सोचने में दिन बिताने के लिए पागल नहीं हूं।

— stinkymatt
स्रोत

303 की तुलना में 303 इस संबंध में बेहतर होगा। 307 का तात्पर्य है कि मूल URL जल्द ही ग्राहक की उम्मीद के मुताबिक जवाब देना शुरू कर देगा।

— निकोलस शैंक्स

RFC 7231 HTTP स्थिति कोड 413 को पेलोड टू लार्ज के रूप में संदर्भित करता है और इस कोड को अनुरोध आकार और संभावित प्रतिक्रिया आकार के साथ संबंधित करता है।

— बीवर

1

आप Rangeशीर्षलेख का पता लगा सकते हैं , और डोजो की नकल कर सकते हैं यदि यह मौजूद है, और एटम की नकल करें यदि यह नहीं है। यह मुझे लगता है कि यह बड़े करीने से उपयोग के मामलों को विभाजित करता है। यदि आप अपने आवेदन से REST क्वेरी का जवाब दे रहे हैं, तो आप उम्मीद करते हैं कि यह एक Rangeशीर्ष लेख के साथ स्वरूपित किया जाएगा । यदि आप एक आकस्मिक ब्राउज़र का जवाब दे रहे हैं, तो यदि आप पेजिंग लिंक वापस करते हैं तो यह टूल को संग्रह का पता लगाने का एक आसान तरीका प्रदान करेगा।

— ग्रेग
स्रोत

1

रेंज हेडर के साथ बड़ी समस्याओं में से एक यह है कि बहुत सारे कॉर्पोरेट प्रॉक्सिस उन्हें फ़िल्टर करते हैं। मैं इसके बजाय एक क्वेरी पैरामीटर का उपयोग करने की सलाह दूंगा।

— user64141
स्रोत

1

Rfc723x के प्रकाशन के साथ , अपंजीकृत श्रेणी इकाइयां कल्पना में स्पष्ट सिफारिश के खिलाफ जाती हैं । Rfc7233 पर विचार करें (पदावनत rfc2616):

" नई रेंज इकाइयां IANA के साथ पंजीकृत होनी चाहिए " (एक HTTP रेंज यूनिट रजिस्ट्री के संदर्भ में )।

— सैम
स्रोत

0

मुझे लगता है कि ऐसा करने का सबसे अच्छा तरीका क्वेरी पैरामीटर के रूप में सीमा को शामिल करना है। उदाहरण के लिए, GET / db / questions /? date> mindate & date <maxdate । GET पर / db / सवाल / बिना किसी क्वेरी पैरामीटर के, स्थान के साथ 303 लौटें : / db / सवाल /? क्वेरी-पैरामीटर-से-प्राप्त-डिफ़ॉल्ट-पृष्ठ । फिर एक अलग URL प्रदान करें जिसके द्वारा संग्रह के बारे में आंकड़े प्राप्त करने के लिए आपके एपीआई का उपयोग किया जा रहा है (उदाहरण के लिए, यदि वह संपूर्ण संग्रह चाहता है तो उपयोग करने के लिए कौन से क्वेरी पैरामीटर हैं);

— डथन
स्रोत

0

हालांकि इस उद्देश्य के लिए रेंज हेडर का उपयोग करना संभव है, मुझे नहीं लगता कि यह इरादा था। ऐसा लगता है कि डेटा को सीमित करने के साथ-साथ परतदार कनेक्शनों को संभालने के लिए डिज़ाइन किया गया है (इसलिए क्लाइंट अनुरोध का हिस्सा अनुरोध कर सकता है अगर कुछ गायब था या आकार प्रक्रिया के लिए बहुत बड़ा था)। आप किसी ऐसी चीज़ में हैकिंग कर रहे हैं जो संभवतः संचार परत पर अन्य उद्देश्यों के लिए उपयोग की जाती है। पेजिंग को संभालने का "उचित" तरीका आपके द्वारा वापस लौटने के प्रकारों के साथ है। प्रश्न ऑब्जेक्ट वापस करने के बजाय, आपको इसके बजाय एक नया प्रकार लौटाया जाना चाहिए।

इसलिए यदि प्रश्न इस प्रकार हैं:

<questions> <question index=1></question> <question index=2></question> ... </questions>

नया प्रकार कुछ इस प्रकार हो सकता है:

<questionPage> <startIndex>50</startIndex> <returnedCount>10</returnedCount> <totalCount>1203</totalCount> <questions> <question index=50></question> <question index=51></question> .. </questions> <questionPage>

बेशक आप अपने मीडिया प्रकारों को नियंत्रित करते हैं, इसलिए आप अपने "पृष्ठों" को एक प्रारूप बना सकते हैं जो आपकी आवश्यकताओं के अनुरूप है। यदि आप कुछ सामान्य करते हैं, तो आपके पास सभी प्रकार के लिए पेजिंग को संभालने के लिए क्लाइंट पर एक ही पार्सर हो सकता है। मुझे लगता है कि HTTP विनिर्देशन की भावना में कुछ और के लिए रेंज पैरामीटर को ठगने के बजाय अधिक है।

— jeremyh
स्रोत