किसी वस्तु में वस्तुओं की कुल संख्या वापस करने के लिए सबसे अच्छा तरीका क्या है?

Question

मैं एक बड़ी सामाजिक नेटवर्किंग वेबसाइट के लिए REST API सेवा विकसित कर रहा हूं, जिसमें मैं शामिल हूं। अब तक यह बहुत अच्छा काम कर रहा है। मैं जारी कर सकते हैं GET, POST, PUTऔर DELETEवस्तु यूआरएल के लिए अनुरोध और अपने डेटा प्रभावित करते हैं। हालाँकि, यह डेटा पृष्ठांकित है (एक समय में 30 परिणामों तक सीमित)।

हालाँकि, मेरे एपीआई के माध्यम से, सदस्यों की कुल संख्या प्राप्त करने का सबसे अच्छा तरीका क्या होगा?

वर्तमान में, मैं निम्नलिखित की तरह एक URL संरचना के लिए अनुरोध जारी करता हूं:

• / एपीआई / सदस्य — सदस्यों की सूची का विवरण दें (एक बार में 30 जैसा कि ऊपर बताया गया है)
• उपयोग किए गए अनुरोध विधि के आधार पर / एपीआई / सदस्य / 1 -एक एकल सदस्य की पुष्टि करता है

मेरा सवाल यह है: मैं अपने आवेदन में सदस्यों की कुल संख्या प्राप्त करने के लिए एक समान URL संरचना का उपयोग कैसे करूंगा? जाहिर है कि केवल idफ़ील्ड (फेसबुक के ग्राफ एपीआई के समान) का अनुरोध करना और परिणामों की गिनती करना अप्रभावी होगा क्योंकि केवल 30 परिणामों का एक टुकड़ा दिया जाएगा।

Comments

संभावित अनुरोध द्वारा देखे गए रिटर्न की गिनती प्राप्त करना

— bzlm

Answer 1

जबकि / API / उपयोगकर्ताओं की प्रतिक्रिया पृष्ठांकित है और केवल 30 रिटर्न, रिकॉर्ड्स, आपको प्रतिक्रिया में रिकॉर्ड की कुल संख्या, और अन्य प्रासंगिक जानकारी, जैसे पृष्ठ आकार, पृष्ठ संख्या / ऑफसेट, आदि शामिल करने से रोकती है। ।

StackOverflow API उसी डिज़ाइन का एक अच्छा उदाहरण है। यहाँ उपयोगकर्ता विधि के लिए प्रलेखन है - https://api.stackexchange.com/docs/users

Comments

+1: निश्चित रूप से सबसे अधिक मूल्यवान बात यह है कि लाने के लिए सभी सीमाएँ लाई जा रही हैं।

— डोनल फेलो

@bzim आपको पता होगा कि लाने के लिए एक अगला पृष्ठ है क्योंकि rel = "next" के साथ एक लिंक है।

— डारेल मिलर

@ डॉनल "अगला" रिले IANA iana.org/assignments/link-relations/link-relations.txt

— डेरेल मिलर

@ विवाद - हाँ, यह पेलोड में किसी भी प्रकार के "अगले" झंडे के साथ किया जा सकता है। मुझे बस लगता है कि प्रतिक्रिया में संग्रह की वस्तुओं की कुल गिनती अपने आप से मूल्यवान है और "अगले" ध्वज के समान ही काम करती है।

— फ्रैंकी पेनोव

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

— Loenix

Answer 2

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

तत्वों की कुल संख्या के लिए मैं X-total-countहेडर का उपयोग करता हूं ।
अगले, पिछले पृष्ठ आदि के लिंक के लिए मैं http Linkहेडर का उपयोग करता हूं :
http://www.w3.org/wiki/LinkHeader

गितुब इसी तरह करता है: https://developer.github.com/v3/#pagination

मेरी राय में यह क्लीनर है क्योंकि इसका उपयोग तब भी किया जा सकता है जब आप ऐसी सामग्री लौटाते हैं जो हाइपरलिंक (यानी बायनेरिज़, चित्र) का समर्थन नहीं करती है।

Comments

RFC6648 स्ट्रिंग के साथ अनियंत्रित मापदंडों के नामों को उपसर्ग करने के सम्मेलन को चित्रित करता है X-।

— जदव

Answer 3

_{मैं इस और अन्य REST पेजिंग से संबंधित कुछ विस्तृत शोध हाल ही में कर रहा हूं और सोचा कि अपने कुछ निष्कर्षों को यहां जोड़ूं। मैं पेजिंग पर विचारों को शामिल करने के लिए प्रश्न को थोड़ा विस्तार कर रहा हूं और साथ ही वे अंतरंग रूप से संबंधित हैं।}

हेडर

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

कुल गिनती सहित, संबंधित जानकारी को वापस करने के लिए जंगली में उपयोग किए जाने वाले मानक (मानक और कस्टम) हेडर का एक गुच्छा है।

एक्स-कुल-गणना

X-Total-Count: 234

यह कुछ एपीआई में उपयोग किया जाता है जो मुझे जंगल में मिला। इस शीर्षलेख के लिए उदाहरण के लिए लूपबैक में समर्थन जोड़ने के लिए एनपीएम पैकेज भी हैं । कुछ लेख इस हेडर को भी सेट करने की सलाह देते हैं।

यह अक्सर Linkहेडर के साथ संयोजन में उपयोग किया जाता है , जो पेजिंग के लिए एक बहुत अच्छा समाधान है, लेकिन कुल गणना की जानकारी का अभाव है।

संपर्क

Link: </TheBook/chapter2>;
      rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
      </TheBook/chapter4>;
      rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

मुझे लगता है, इस विषय पर बहुत कुछ पढ़ने से, कि आम सहमति का उपयोग करने वाले ग्राहकों को पेजिंग लिंक प्रदान करने के लिए Linkहेडर का उपयोग करना है rel=next, rel=previousआदि इसके साथ समस्या यह है कि इसमें कुल कितने रिकॉर्ड हैं, इसकी जानकारी का अभाव है, जो है क्यों कई एपीआई X-Total-Countहैडर के साथ इसे जोड़ते हैं ।

वैकल्पिक रूप से, कुछ API और उदाहरण के लिए JsonApi मानक, Linkप्रारूप का उपयोग करते हैं , लेकिन हेडर के बजाय प्रतिक्रिया लिफाफे में जानकारी जोड़ते हैं। यह मेटाडेटा तक पहुंच को सरल करता है (और कुल डेटा को जोड़ने के लिए एक जगह बनाता है) वास्तविक डेटा तक पहुँचने की बढ़ती जटिलता की कीमत पर (एक लिफाफा जोड़कर)।

सामग्री रेंज

Content-Range: items 0-49/234

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

लिफ़ाफ़ा

हमारी पसंदीदा क्यू एंड ए वेबसाइट से एक सहित कई एपीआई, एक लिफाफे का उपयोग करते हैं , डेटा के चारों ओर एक आवरण जो डेटा के बारे में मेटा जानकारी जोड़ने के लिए उपयोग किया जाता है। इसके अलावा, OData और JsonApi मानकों दोनों एक प्रतिक्रिया लिफाफे का उपयोग करते हैं।

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

अलग समापन बिंदु

मुझे लगता है कि यह अन्य उत्तरों में पर्याप्त रूप से कवर किया गया है। मैंने इसकी बहुत जांच नहीं की क्योंकि मैं टिप्पणियों से सहमत हूं कि यह भ्रामक है क्योंकि अब आपके पास कई प्रकार के समापन बिंदु हैं। मुझे लगता है कि यह सबसे अच्छा है अगर हर समापन बिंदु एक (संसाधन) का संग्रह का प्रतिनिधित्व करता है।

आगे के विचार

हमें न केवल प्रतिक्रिया से संबंधित पेजिंग मेटा जानकारी को संप्रेषित करना है, बल्कि ग्राहक को विशिष्ट पृष्ठों / सीमाओं का अनुरोध करने की भी अनुमति है। एक सुसंगत समाधान के साथ समाप्त होने के लिए इस पहलू को देखना भी दिलचस्प है। यहाँ भी हम हेडर का उपयोग कर सकते हैं ( Rangeहेडर बहुत उपयुक्त लगता है), या अन्य तंत्र जैसे क्वेरी पैरामीटर। कुछ लोगों को अलग संसाधन है, जो कुछ उपयोग के मामलों में अर्थपूर्ण हो सकता है (उदाहरण के रूप में परिणाम के पन्नों के इलाज के वकील /books/231/pages/52। मैं इस तरह के रूप में अक्सर इस्तेमाल किया अनुरोध पैरामीटर के एक जंगली सीमा के चयन समाप्त हो गया pagesize, page[size]और limitआदि समर्थन करने के अलावा में Rangeहैडर (और अनुरोध पैरामीटर के रूप में भी)।

Comments

मुझे Rangeहेडर में विशेष रूप से दिलचस्पी थी , हालांकि मुझे इस बात के पर्याप्त सबूत नहीं मिले कि bytesश्रेणी प्रकार के अलावा कुछ भी उपयोग करना वैध है।

— VisioN

मुझे लगता है कि स्पष्ट प्रमाण आरएफसी की धारा 14.5 में पाए जा सकते हैं : acceptable-ranges = 1#range-unit | "none"मुझे लगता है कि यह सूत्रीकरण स्पष्ट रूप से अन्य रेंज इकाइयों के लिए जगह छोड़ देता है bytes, हालांकि कल्पना केवल परिभाषित करती है bytes।

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

Answer 4

वैकल्पिक जब आपको वास्तविक वस्तुओं की आवश्यकता न हो

फ्रैंकी पेनोव का जवाब निश्चित रूप से जाने का सबसे अच्छा तरीका है ताकि आप हमेशा अपनी संस्थाओं के अनुरोध के बारे में सभी अतिरिक्त मेटाडेटा के साथ आइटम वापस कर सकें। यही तरीका होना चाहिए।

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

/api/members?metaonly=true
/api/members?includeitems=0

या कुछ इसी तरह ...

Comments

हेडर में इस जानकारी को एम्बेड करने से यह फायदा होता है कि आप केवल गिनती प्राप्त करने के लिए एक HEAD अनुरोध कर सकते हैं।

— felixfbecker

@felixfbecker ठीक है, पहिया को फिर से मजबूत करने और सभी प्रकार के विभिन्न तंत्रों के साथ एपीआई को बंद करने के लिए धन्यवाद :)

— EralpB

पहिया को सुदृढ़ करने और एपीआई को अव्यवस्थित करने के लिए @EralpB धन्यवाद !? HTTP में HEAD को Specify किया जाता है। metaonlyया includeitemsनहीं है।

— felixfbecker

@felixfbecker केवल "वास्तव में" आपके लिए था, बाकी ओपी के लिए है। गलतफहमी के लिए खेद है।

— यूरालप बी ११'१

Rest, HTTP का लाभ उठाने और इसका यथासंभव उपयोग करने के लिए है। इस मामले में सामग्री-रेंज (RFC7233) का उपयोग किया जाना चाहिए। शरीर के भीतर समाधान अच्छा नहीं हैं, खासकर क्योंकि यह HEAD के साथ काम नहीं करेगा। नए हेडर बनाने का सुझाव दिया गया है क्योंकि यहाँ अनावश्यक और गलत हैं।

— वंस शिपले

Answer 5

आप HEAD अनुरोध के जवाब में एक कस्टम HTTP हेडर के रूप में गिनती वापस कर सकते हैं। इस तरह, यदि कोई ग्राहक केवल गिनती चाहता है, तो आपको वास्तविक सूची वापस करने की आवश्यकता नहीं है, और अतिरिक्त URL की कोई आवश्यकता नहीं है।

(या, यदि आप एंडपॉइंट से एंडपॉइंट के लिए नियंत्रित वातावरण में हैं, तो आप कस्टम HTTP क्रिया जैसे COUNT का उपयोग कर सकते हैं।)

Comments

"कस्टम HTTP हेडर"? यह कुछ आश्चर्यजनक होने के शीर्ष पर होगा, जो बदले में मुझे लगता है कि एक विपरीत एपीआई होना चाहिए के विपरीत है। अंत में, यह अस्वाभाविक होना चाहिए।

— डोनल फैलो

@ मुझे पता है। लेकिन सभी अच्छे जवाब पहले ही ले लिए गए थे। :(

— bzlm

मुझे भी पता है, लेकिन कभी-कभी आपको सिर्फ दूसरे लोगों को जवाब देने देना होता है। या अन्य तरीकों से अपने योगदान को बेहतर बनाएं, जैसे कि दूसरों के बजाय इसे सबसे अच्छे तरीके से क्यों किया जाना चाहिए, इसका विस्तृत विवरण।

— डोनाल्ड फेलो

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

— जेम्स बिलिंगहैम

मुझे इस तरह की चीज़ के लिए HTTP हेडर का उपयोग करना बहुत पसंद है (यह वास्तव में जहां यह है)। मानक लिंक हेडर इस मामले में उपयुक्त हो सकता है (Github API इसका उपयोग करता है)।

— माइक मार्सैकी

Answer 6

मैं उसी के लिए हेडर जोड़ने की सलाह दूंगा, जैसे:

HTTP/1.1 200

Pagination-Count: 100
Pagination-Page: 5
Pagination-Limit: 20
Content-Type: application/json

[
  {
    "id": 10,
    "name": "shirt",
    "color": "red",
    "price": "$23"
  },
  {
    "id": 11,
    "name": "shirt",
    "color": "blue",
    "price": "$25"
  }
]

जानकारी के लिए देखें:

https://github.com/adnan-kamili/rest-api-response-format

स्वैगर फ़ाइल के लिए:

https://github.com/adnan-kamili/swagger-response-template

Answer 7

"X -" के रूप में - उपसर्ग को पदावनत किया गया। (देखें: https://tools.ietf.org/html/rfc6648 )

हमने "एक्सेप्ट-रेंज्स" को पेजेशन को मैप करने के लिए सबसे अच्छी शर्त के रूप में पाया: https://tools.ietf.org/html/rfc7233#section-2.3 "रेंज यूनिट्स" के रूप में "बाइट्स" या "हो सकता है" टोकन "। दोनों एक कस्टम डेटा प्रकार का प्रतिनिधित्व नहीं करते हैं। (देखें: https://tools.ietf.org/html/rfc7233#section-4.2 ) फिर भी, यह कहा जाता है कि

HTTP / 1.1 कार्यान्वयन MAY अन्य इकाइयों का उपयोग करके निर्दिष्ट सीमाओं की उपेक्षा करते हैं।

जो इंगित करता है: कस्टम रेंज यूनिट का उपयोग करना प्रोटोकॉल के खिलाफ नहीं है, लेकिन इसे अनदेखा किया जा सकता है।

इस तरह, हमें Accept-Ranges को "सदस्यों" या जो कुछ भी इकाई प्रकार टाइप करना होगा, हम उम्मीद करेंगे। और इसके अलावा, कंटेंट-रेंज को भी वर्तमान रेंज पर सेट करें। (देखें: https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.12 )

किसी भी तरह से, मैं 200 की बजाय 206 भेजने के लिए RFC7233 ( https://tools.ietf.org/html/rfc7233#page-8 ) की सिफारिश पर टिकूंगा :

यदि सभी पूर्व शर्त सही हैं, तो सर्वर
लक्ष्य संसाधन के लिए रेंज हेडर फ़ील्ड का समर्थन करता है , और निर्दिष्ट सीमा (एस)
मान्य और संतोषजनक हैं (जैसा कि धारा 2.1 में परिभाषित किया गया है), सर्वर
एक 206 (आंशिक सामग्री) प्रतिक्रिया भेजें पेलोड के साथ एक
या एक से अधिक आंशिक अभ्यावेदन हैं जो
धारा 4 में परिभाषित संतोषजनक रेंज के अनुरूप हैं ।

इसलिए, परिणामस्वरूप, हमारे पास निम्न HTTP हेडर फ़ील्ड होंगे:

आंशिक सामग्री के लिए:

206 Partial Content
Accept-Ranges: members
Content-Range: members 0-20/100

पूर्ण सामग्री के लिए:

200 OK
Accept-Ranges: members
Content-Range: members 0-20/20

Answer 8

लगता है सबसे आसान सिर्फ एक जोड़ने के लिए

GET
/api/members/count

और सदस्यों की कुल गिनती लौटाते हैं

Comments

अच्छा विचार नहीं। आप ग्राहकों को उनके पृष्ठों पर पेजिनेशन बनाने के लिए 2 अनुरोध करने के लिए बाध्य करते हैं। पहला संसाधनों की सूची प्राप्त करने का अनुरोध करता है और दूसरा कुल गिनने का।

— जेकिस

मुझे लगता है कि यह अच्छा तरीका है ... आप केवल परिणाम की सूची भी वापस कर सकते हैं जैसे कि json और कलेक्शन के क्लाइंट साइड चेक साइज़ पर तो इस तरह का मामला मूर्खतापूर्ण उदाहरण है ... इसके अलावा आपके पास / एपीआई / सदस्य / गिनती और फिर / एपीआई हो सकते हैं / सदस्य? ऑफसेट = 10 और सीमा = 20

— माइकेल ज़ीब्रो

यह भी ध्यान रखें कि बहुत सारे प्रकार के पेजिनेशन के लिए गिनती की आवश्यकता नहीं होती है (जैसे कि अनन्त स्क्रॉल) - ग्राहक की आवश्यकता न होने पर इसकी गणना क्यों करें

— tofarr

Answer 9

एक नए अंतिम बिंदु के बारे में क्या है / / एपीआई / सदस्य / गिनती जो सिर्फ सदस्यों को बुलाता है ।ाउंट () और परिणाम देता है

Comments

काउंट को एक स्पष्ट समापन बिंदु देते हुए यह एक स्टैंडअलोन पता योग्य संसाधन बनाता है। यह काम करेगा, लेकिन आपके एपीआई के लिए किसी भी नए के लिए दिलचस्प सवाल उठाएगा - क्या संग्रह के सदस्यों की गणना संग्रह से एक अलग संसाधन है? क्या मैं इसे PUT अनुरोध के साथ अपडेट कर सकता हूं? क्या यह एक खाली संग्रह के लिए मौजूद है या केवल अगर इसमें आइटम हैं? यदि membersसंग्रह POST अनुरोध द्वारा बनाया जा सकता है /api, तो /api/members/countसाइड इफेक्ट के रूप में भी बनाया जाएगा , या क्या मुझे अनुरोध करने से पहले इसे बनाने के लिए एक स्पष्ट POST अनुरोध करना होगा? :-)

— फ्रैंकी पेनोव

Answer 10

कभी-कभी फ्रेमवर्क (जैसे $ संसाधन / एंगुलरजेएस) को क्वेरी परिणाम के रूप में एक सरणी की आवश्यकता होती है, और आपके पास वास्तव {count:10,items:[...]}में इस तरह की प्रतिक्रिया नहीं हो सकती है जैसे कि मैं प्रतिक्रियादाताओं में "गिनती" संग्रहीत करता हूं।

PS वास्तव में आप ऐसा $ संसाधन / AngularJS के साथ कर सकते हैं, लेकिन इसके लिए कुछ ट्विक्स की आवश्यकता होती है।

Comments

वो क्या ट्विस्ट हैं? वे इस तरह के सवालों पर मददगार होंगे: stackoverflow.com/questions/19140017/…

— JBCP

कोणीय परिणाम के रूप में एक सरणी क्वेरी परिणाम के रूप में नहीं है, आपको बस विकल्प संसाधन संपत्ति के साथ अपने संसाधन को कॉन्फ़िगर करना होगा:isArray: false|true

— रेमी बेचारे

Answer 11

आप countsएक संसाधन के रूप में विचार कर सकते हैं । URL तब होगा:

/api/counts/member

Answer 12

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

मुझे पसंद है कि गणना के लिए अलग समापन बिंदु है (या पैरामीटर के साथ एक ही समापन बिंदु है)। क्योंकि आप लंबे समय तक उपभोग करने वाली प्रक्रिया को सही ढंग से शुरू किए गए प्रोग्रेसबार दिखा कर तैयार कर सकते हैं।

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

<data>
  <originalRequest>
    <filter/>
    <filter/>
  </originalReqeust>
  <totalRecordCount/>
  <pageSize/>
  <offset/>
  <list>
     <item/>
     <item/>
  </list>
</data>

मेरा कुल, मौजूदा समापन बिंदु के लिए एक प्रतिमान पैरामीटर पसंद करते हैं। इसलिए, जब निर्दिष्ट प्रतिक्रिया में केवल मेटाडेटा होता है।

endpoint? फिल्टर = मूल्य

<data>
  <count/>
  <list>
    <item/>
    ...
  </list>
</data>

endpoint? फिल्टर = मान और countOnly सच =

<data>
  <count/>
  <!-- empty list -->
  <list/>
</data>