एक वेब अनुप्रयोग में पृष्ठ पर अंक लगाना

Question

यह इस प्रश्न का एक अधिक सामान्य सुधार है (रेल विशिष्ट भागों के उन्मूलन के साथ)

मुझे यकीन नहीं है कि एक रैस्टफुल वेब एप्लिकेशन में संसाधन पर पृष्ठांकन कैसे लागू किया जाए। यह मानते हुए कि मेरे पास एक संसाधन है products, जो आपको लगता है कि निम्नलिखित में से कौन सा सबसे अच्छा तरीका है, और क्यों:

1. केवल क्वेरी स्ट्रिंग्स का उपयोग करना

जैसे। http://application/products?page=2&sort_by=date&sort_how=asc
यहां समस्या यह है कि मैं पूर्ण पृष्ठ कैशिंग का उपयोग नहीं कर सकता हूं और यह भी कि URL बहुत साफ और याद रखने में आसान नहीं है।

2. छँटाई के लिए संसाधनों और क्वेरी स्ट्रिंग के रूप में पृष्ठों का उपयोग करना

जैसे। http://application/products/page/2?sort_by=date&sort_how=asc
इस मामले में, जो समस्या है वह यह है कि http://application/products/pages/1यह एक अनूठा संसाधन नहीं है क्योंकि उपयोग करने से sort_by=priceपूरी तरह से अलग परिणाम मिल सकता है और मैं अभी भी पेज कैशिंग का उपयोग नहीं कर सकता हूं।

3. पृष्ठों को संसाधनों के रूप में और छाँटने के लिए URL सेगमेंट का उपयोग करना

जैसे। http://application/products/by-date/page/2
मुझे व्यक्तिगत रूप से इस पद्धति का उपयोग करने में कोई समस्या नहीं है, लेकिन किसी ने मुझे चेतावनी दी कि यह जाने का एक अच्छा तरीका नहीं है (उसने कोई कारण नहीं दिया, इसलिए यदि आप जानते हैं कि इसकी सिफारिश क्यों नहीं की जाती है, तो कृपया मुझे बताएं)

किसी भी सुझाव, राय, समालोचना स्वागत से अधिक है। धन्यवाद।

Comments

यह एक बड़ा सवाल है।

— Iain होल्डर

बोनस प्रश्न: लोग आमतौर पर पृष्ठ आकार कैसे निर्दिष्ट करते हैं?

— हाइको रुप

मैट्रिक्स मापदंडों के बारे में मत भूलना w3.org/DesignIssues/MatrixURIs.html

— CMCDragonkai

Answer 1

मुझे लगता है कि संस्करण 3 के साथ समस्या अधिक "देखने का मुद्दा" समस्या है - क्या आप पृष्ठ को संसाधन या पेज पर उत्पादों के रूप में देखते हैं।

यदि आप पृष्ठ को संसाधन के रूप में देखते हैं तो यह पूरी तरह से ठीक समाधान है, क्योंकि पृष्ठ 2 के लिए क्वेरी हमेशा पृष्ठ 2 का उत्पादन करेगी।

लेकिन यदि आप पृष्ठ पर उत्पादों को संसाधन के रूप में देखते हैं तो आपको समस्या है कि पृष्ठ 2 पर उत्पाद बदल सकते हैं (पुराने उत्पाद हटा दिए गए हैं, या जो भी हो), इस मामले में यूआरआई हमेशा एक ही संसाधन (ओं) को वापस नहीं कर रहा है।

उदाहरण के लिए, एक ग्राहक उत्पाद सूची पृष्ठ X का लिंक संग्रहीत करता है, अगली बार जब उत्पाद खोला जाता है तो प्रश्न में उत्पाद पृष्ठ X पर नहीं रह सकता है।

Comments

ठीक है, लेकिन अगर आप कुछ हटाते हैं तो उसी URI पर कुछ और नहीं होना चाहिए। यदि आप पृष्ठ X - पेज X के सभी उत्पादों को हटा देते हैं, तो भी वे मान्य हो सकते हैं, लेकिन अब पृष्ठ X + 1 से उत्पाद शामिल हैं। तो पेज X के लिए URI पेज X + 1 के लिए URI बन गया है यदि आप इसे "उत्पाद संसाधन दृश्य" में देखते हैं "।

— फिओन

> यदि आप पृष्ठ को संसाधन के रूप में देखते हैं, तो यह पूरी तरह से एक अच्छा समाधान है, क्योंकि पेज 2 के लिए क्वेरी पृष्ठ 2 को छोड़ देगी। क्या इसका कोई मतलब है? समान URL (पृष्ठ का उल्लेख करने वाला कोई भी URL) हमेशा पृष्ठ 2 का ही उत्पादन करेगा चाहे आप किसी भी संसाधन के रूप में हों।

— टेम्पो डे

पेज को संसाधन के रूप में देखकर संभवतः एक नया पृष्ठ बनाने के लिए POST / foo / पृष्ठ का परिचय देना चाहिए, है ना?

— टेम्पो

आपका उत्तर सुचारू रूप से "सही समाधान 1 है" पर जाता है, लेकिन यह बताता नहीं है।

— टेम्पो

मेरे दिमाग में, पेज एक अस्थायी अवधारणा है, और अंतर्निहित डोमेन से संबंधित नहीं है। और इसलिए इसे एक संसाधन नहीं माना जाना चाहिए। मेरा मतलब है कि इस अर्थ में कि यह तरल है, कि संदर्भ के साथ पृष्ठ की अवधारणा बदल जाती है; आपके API का एक उपयोगकर्ता एक मोबाइल ऐप हो सकता है, जो प्रति पृष्ठ केवल 2 उत्पादों का उपभोग कर सकता है, जबकि दूसरा एक मशीन ऐप है जो संपूर्ण लानत सूची का उपभोग कर सकता है। संक्षेप में, पृष्ठ अंतर्निहित डोमेन इकाई (उत्पाद) का एक "प्रतिनिधित्व" है और इसे URL के एक भाग के रूप में शामिल नहीं किया जाना चाहिए; केवल एक क्वेरी पैरामीटर के रूप में।

— Kingz

Answer 2

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

Comments

+1: क्वेरी स्ट्रिंग्स प्रथम श्रेणी के संसाधन पहचानकर्ता नहीं हैं; वे संसाधन के आदेश देने और समूहीकरण के लिए सिर्फ स्पष्टीकरण देते हैं।

— एस.लॉट

@ S.Lott अनुरोध है संसाधन। जिसे आप "प्रथम श्रेणी के संसाधन" कहते हैं , उसके शोध प्रबंध के खंड 5.2.1.1 में क्षेत्ररक्षण द्वारा मूल्यों के रूप में परिभाषित किया गया है । इसके अलावा, एक ही खंड में, फील्डिंग एक संसाधन के उदाहरण के रूप में एक स्रोत कोड फ़ाइल का नवीनतम संशोधन देता है । यह एक संसाधन कैसे हो सकता है लेकिन नवीनतम 10 उत्पाद "उत्पाद संसाधन पर अनुरोध के गुण" हो सकते हैं? मैं समझता हूं कि आपका दृष्टिकोण अधिक व्यावहारिक है, लेकिन मुझे लगता है कि यह कम Restful है।

— edsioufi

ध्यान दें कि मेरी टिप्पणी का यह अर्थ नहीं है कि मैं URL पर क्वेरी स्ट्रिंग्स का उपयोग करने के विकल्प से असहमत हूं: दोनों व्यवहार्य समाधान हैं जब तक कि एपीआई हाइपरमीडिया-चालित है, जैसा कि @RichApodaca ने अपने उत्तर में उल्लेख किया है। मैं केवल इस ओर इशारा कर रहा हूं कि पृष्ठ को संसाधन के रूप में माना जाना चाहिए।

— edsioufi

Answer 3

HTTP में महान श्रेणी के हेडर हैं जो पेजिनेशन के लिए भी उपयुक्त है। आप भेज सकते हैं

Range: pages=1

केवल पहला पृष्ठ है जो आपको एक पेज बनाने के लिए बाध्य कर सकता है। शायद ग्राहक वस्तुओं की एक अलग श्रेणी चाहता है। रेंज हेडर भी एक आदेश घोषित करने के लिए काम करता है:

Range: products-by-date=2009_03_27-

सभी उत्पादों को उस तारीख से नया या प्राप्त करने के लिए

Range: products-by-date=0-2009_11_30

उस तिथि से पुराने सभी उत्पादों को प्राप्त करने के लिए। '0' शायद सबसे अच्छा समाधान नहीं है, लेकिन आरएफसी रेंज स्टार्ट के लिए कुछ करना चाहता है। वहाँ HTTP पार्सरों को तैनात किया जा सकता है जो इकाइयों को पार्स नहीं करेंगे = -range_end।

यदि हेडर एक स्वीकार्य (स्वीकार्य) विकल्प नहीं है, तो मैं पहले समाधान (सभी क्वेरी स्ट्रिंग में) पृष्ठों से निपटने का एक तरीका है। लेकिन कृपया, क्वेरी स्ट्रिंग्स (सॉर्ट (मान = मान) जोड़े वर्णमाला क्रम में) को सामान्य करें। यह हल करता है "? = A = 1 & b = x" और "? B = x & a = 1" भेदभाव की समस्या।

Comments

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

— मार्कस

और रेंज हेडर केवल बाइट रेंज के लिए है। [HTTP हेडर स्पेक] ( w3.org/Protocols/rfc2616/rfc2616-sec14.html ), धारा 14.35 देखें।

— क्रिस वेस्टिन

@ChrisWestin w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.12 HTTP / 1.1 श्रेणी (खंड 14.35) और सामग्री-रेंज (खंड 14.16) शीर्षक फ़ील्ड में श्रेणी इकाइयों का उपयोग करता है। range-unit = bytes-unit | other-range-unit हो सकता है कि आप The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.इसका उल्लेख कर रहे हों, यह आपके कथन के समान नहीं है।

— 18

@ मर्कस मैं उपयोग के मामले की कल्पना नहीं कर सकता, जब आप बाकी एपीआई संसाधन साझा कर रहे हैं :)

— जकूबकेजल्लिक

@JakubKnejzlik साझा करना कोई समस्या नहीं है, लेकिन पेजिंग के लिए HTTP हेडर का उपयोग पेजिंग के लिए HATEOAS लिंक का उपयोग करने से रोकता है।

— xarx

Answer 4

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

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

आपके क्लाइंट द्वारा प्रदान किया जाने वाला एक प्रकार का लिंक एक पेजिनेशन लिंक है।

इन सबका सुखद दुष्परिणाम यह है कि भले ही आप अपने दिमाग को पैजेशन यूआरआई ढांचे के बारे में बदल लें और अगले हफ्ते कुछ अलग तरीके से लागू करें, आपके ग्राहक बिना किसी संशोधन के काम करना जारी रख सकते हैं।

Comments

REST वेब सेवाओं में लिंक की तरह हाइपरमीडिया का उपयोग करने पर अच्छा अनुस्मारक।

— पॉल डी। ईडन

Answer 5

मैंने हमेशा विकल्प की शैली का उपयोग किया है 1. कैशिंग एक चिंता का विषय नहीं है क्योंकि मेरे मामले में डेटा अक्सर बदलता रहता है। यदि आप पृष्ठ के आकार को कॉन्फ़िगर करने योग्य बनाते हैं तो फिर से डेटा को कैश नहीं किया जा सकता है।

मुझे याद रखने या अशुद्ध होने के लिए url कठिन नहीं लगता। मेरे लिए यह क्वेरी मापदंडों का एक अच्छा उपयोग है। संसाधन स्पष्ट रूप से उत्पादों की एक सूची है और क्वेरी params सिर्फ यह बता रहे हैं कि आप किस प्रकार प्रदर्शित सूची को चाहते हैं - क्रमबद्ध और कौन सा पृष्ठ।

Comments

+1 मुझे लगता है कि आप सही हैं और मैं क्वेरी पैरामीटर (विकल्प 1) के साथ जाना होगा

— andi

"मुझे याद रखने के लिए URL मुश्किल नहीं है"। यह अवलोकन REST अनुप्रयोगों में बेकार है, क्योंकि आम तौर पर उनके पास केवल एक ही बुकमार्क होना चाहिए ... यदि कोई उपयोगकर्ता (या क्लाइंट ऐप) URL को "याद" करने की कोशिश करता है, तो यह एक अच्छा संकेत है कि एपीआई आराम नहीं है।

— edsioufi

Answer 6

अजीब बात है कि किसी ने यह नहीं बताया कि विकल्प 3 में एक विशिष्ट क्रम में पैरामीटर हैं। http // एप्लिकेशन / उत्पाद / तिथि / अवरोही / नाम / आरोही / पृष्ठ / 2 और http // एप्लिकेशन / उत्पाद / नाम / आरोही / दिनांक / अवरोही / पृष्ठ / 2

एक ही संसाधन की ओर इशारा कर रहे हैं, लेकिन पूरी तरह से अलग यूआरएल है।

मेरे लिए विकल्प 1 सबसे स्वीकार्य लगता है, क्योंकि यह स्पष्ट रूप से "मुझे क्या चाहिए" और "मैं कैसे चाहता हूं" को अलग करता है (यह उनके बीच प्रश्न चिह्न भी है)। पूर्ण URL का उपयोग करके पूर्ण-पृष्ठ कैशिंग लागू किया जा सकता है (सभी विकल्प वैसे भी एक ही समस्या से ग्रस्त होंगे)।

Parameters-in-URL दृष्टिकोण के साथ एकमात्र लाभ स्वच्छ URL है। हालांकि आपको मापदंडों को एनकोड करने के लिए किसी तरह से आना होगा और दोषरहित रूप से उन्हें डीकोड करना होगा। बेशक आप यूआरएलेंकोड / डीकोड के साथ जा सकते हैं, लेकिन यह फिर से उर को बदसूरत बना देगा :)

Comments

वे दो अलग-अलग क्रम हैं। उतरते हुए पहली तरह, और केवल आरोही नाम से संबंध तोड़ता है; आरोही नाम से दूसरा प्रकार, और केवल अवरोही क्रम से संबंध विच्छेद करता है।

— इमरान राशिद

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

— क्रिश्चियन गोश

Answer 7

मैं क्वेरी पैरामीटर ऑफसेट और सीमा का उपयोग करना पसंद करूंगा।

ऑफसेट : संग्रह में आइटम के सूचकांक के लिए।

सीमा : मदों की गिनती के लिए।

क्लाइंट केवल ऑफ़सेट को निम्नानुसार अपडेट करता रह सकता है

offset = offset + limit

अगले पेज के लिए

पथ को संसाधन पहचानकर्ता माना जाता है। और एक पृष्ठ संसाधन नहीं है बल्कि संसाधन संग्रह का सबसेट है। चूंकि पृष्ठांकन आम तौर पर एक GET अनुरोध है, क्वेरी पैरामीटर हेडर के बजाय पेजिनेशन के लिए सबसे उपयुक्त हैं।

संदर्भ: https://metamug.com/article/rest-ap-developers-dilemma.html#Requesting-the-xtxt-page

Answer 8

इस साइट पर आई सर्वोत्तम प्रथाओं की तलाश:

http://www.restapitutorial.com

संसाधन पृष्ठ में एक .pdf डाउनलोड करने के लिए एक लिंक है जिसमें लेखक द्वारा सुझाई गई पूरी रीस्ट सर्वोत्तम अभ्यास शामिल हैं। जिसमें अन्य बातों के अलावा पृष्ठांकन के बारे में एक खंड है।

लेखक एक रेंज हेडर का उपयोग करके और क्वेरी-स्ट्रिंग मापदंडों का उपयोग करके दोनों को समर्थन जोड़ने का सुझाव देता है।

निवेदन

HTTP शीर्ष लेख उदाहरण:

Range: items=0-24

क्वेरी-स्ट्रिंग पैरामीटर उदाहरण:

GET http://api.example.com/resources?offset=0&limit=25

जहां ऑफ़सेट शुरुआत आइटम नंबर है और सीमा आइटम की अधिकतम संख्या है।

प्रतिक्रिया

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

HTTP शीर्ष लेख उदाहरण:

Content-Range: items 0-24/66

Content-Range: items 40-65/*

.Pdf में अधिक विशिष्ट मामलों के लिए कुछ अन्य सुझाव हैं।

Answer 9

मैं वर्तमान में अपने ASP.NET MVC एप्लिकेशन में इस तरह की एक योजना का उपयोग कर रहा हूं:

जैसे http://application/products/by-date/page/2

विशेष रूप से यह है: http://application/products/Date/Ascending/3

हालाँकि, मैं मार्ग में जानकारी को इस तरह से पेजिंग और छाँटने सहित वास्तव में खुश नहीं हूँ।

वस्तुओं की सूची (इस मामले में उत्पाद) परस्पर है। यानी अगली बार जब कोई व्यक्ति एक url पर लौटता है जिसमें पेजिंग और सॉर्टिंग पैरामीटर शामिल होते हैं, तो उन्हें मिलने वाले परिणाम बदल सकते हैं। तो http://application/products/Date/Ascending/3एक अद्वितीय यूआरएल के रूप में विचार जो उत्पादों के एक परिभाषित, अपरिवर्तनीय सेट की ओर इशारा करता है।

Comments

पहला मुद्दा, कई स्तंभों पर छंटनी के साथ, मेरी राय में सभी 3 तरीकों पर लागू होता है। तो यह वास्तव में उनमें से किसी के लिए एक समर्थक / चोर नहीं है। दूसरे मुद्दे के बारे में: क्या यह किसी भी संसाधन के लिए ख़ुशी नहीं दे सकता है ? एक उत्पाद, उदाहरण के लिए, संपादित / हटाया भी जा सकता है।

— andi

मुझे लगता है कि कई कॉलमों पर छंटनी वास्तव में सभी 3 विधियों के लिए एक 'con' है क्योंकि url अभी बड़ा और अधिक अप्राप्य हो जाता है - इसलिए एक कारण यह है कि मैं फॉर्म आधारित पेज / सॉर्ट पैरामीटर पर जाने पर विचार कर रहा हूं। दूसरे अंक के लिए, मुझे लगता है कि उत्पादों की एक क्षणिक सूची की तुलना में एक उत्पाद आईडी की तरह एक अद्वितीय निरंतर पहचानकर्ता के बीच एक मौलिक वैचारिक अंतर है। हटाए गए उत्पादों के लिए एक संदेश जैसे 'वह उत्पाद सिस्टम में मौजूद नहीं है' आपको उस उत्पाद के बारे में कुछ ठोस बताता है।

— स्टीव विलकॉक

मार्ग से सभी पेजिंग और सॉर्टिंग जानकारी निकालना अच्छा है। और इसे POST मापदंडों में धकेलना बुरा है। हैलो? सवाल REST के बारे में है। हम केवल REST में URL को छोटा करने के लिए POST का उपयोग नहीं कर रहे हैं। क्रिया समझ में आती है।

— टेम्पो

व्यक्तिगत रूप से, मैं किसी प्रश्न के लिए फ़ॉर्म पैरामीटर का उपयोग नहीं करूंगा क्योंकि इसके लिए लगभग POST या PUT HTTP विधि की आवश्यकता होगी (क्योंकि अब अनुरोध में एक निकाय है)। मुझे लगता है कि POST और PUT दोनों संसाधन को संशोधित करने के बाद से उपयोग करने के लिए अधिक उपयुक्त विधि की तरह लगते हैं। इसके कारण मैं URL पर अधिक क्वेरी पैरामीटर जोड़ने के साथ जाऊंगा जब कई कॉलमों को छाँटना होगा।

— पॉल डी। ईडन

Answer 10

मैं इस बात से सहमत हूँ कि "पेज" वास्तव में एक संसाधन नहीं है। दूसरी ओर, विकल्प 3 क्लीनर है, पढ़ने में आसान है, और उपयोगकर्ता द्वारा अधिक आसानी से अनुमान लगाया जा सकता है और यदि आवश्यक हो तो टाइप किया जा सकता है। मैं विकल्प 1 और 3 के बीच फटा हुआ हूं, लेकिन विकल्प 3 का उपयोग न करने का कोई कारण नहीं दिखता।

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

Comments

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

— जेआर गार्सिया

Answer 11

मैंने पहले समाधान 3 का उपयोग किया है (मैं django एप्लिकेशन का बहुत लिखता हूं)। और मुझे नहीं लगता कि इसमें कुछ गलत है। यह अन्य दो के रूप में बस के रूप में उदार है (अगर आपको कुछ बड़े पैमाने पर स्क्रैपिंग या पसंद करने की आवश्यकता है) और यह क्लीनर दिखता है। साथ ही, आपके उपयोगकर्ता urls का अनुमान लगा सकते हैं (यदि यह एक सार्वजनिक सामना करने वाला ऐप है), और लोगों को सीधे जाने में सक्षम होना पसंद है जहां वे चाहते हैं, और url- अनुमान लगाना सशक्त महसूस करता है।

Answer 12

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

http://application/products?page=2&sort=+field1-field2

जिसका अर्थ है - "मुझे पेज दे दो दूसरा पेज फ़ील्ड 1 द्वारा आरोही और फिर फील्ड 2 द्वारा उतरता है"। या अगर मुझे और भी लचीलेपन की आवश्यकता हो तो मैं उपयोग करता हूँ:

http://application/products?skip=20&limit=20&sort=+field1-field2

Answer 13

मैं अगले पृष्ठ रिकॉर्ड प्राप्त करने के लिए निम्नलिखित पैटर्न में उपयोग करता हूं। http: // आवेदन / उत्पादों lastRecordKey = & pageSize = 20 & प्रकार = एएससी

RecordKey एक तालिका का स्तंभ है जो DB में अनुक्रमिक मान रखता है। इसका उपयोग DB से एक समय में केवल एक पृष्ठ डेटा प्राप्त करने के लिए किया जाता है। PageSize का उपयोग यह निर्धारित करने के लिए किया जाता है कि कितने रिकॉर्ड लाने हैं। सॉर्ट का उपयोग आरोही या अवरोही क्रम में रिकॉर्ड को सॉर्ट करने के लिए किया जाता है।