Django REST पेजिनेशनमध्ये प्रभुत्व मिळवा: जागतिक स्तरावर स्केलेबल APIs साठी कस्टम क्लासेस तयार करणे

वेब डेव्हलपमेंटच्या जगात, मजबूत आणि स्केलेबल APIs तयार करणे अत्यंत महत्त्वाचे आहे. जसे ॲप्लिकेशन्स वाढतात, तसाच ते हाताळत असलेल्या डेटाचे प्रमाणही वाढते. एकाच API प्रतिसादात प्रचंड प्रमाणात डेटा देणे केवळ अकार्यक्षम नाही, तर यामुळे वापरकर्त्याचा अनुभव खराब होऊ शकतो, लोडिंगला वेळ लागू शकतो आणि सर्व्हरवर ताण वाढू शकतो. इथेच पेजिनेशन कामी येते - मोठ्या डेटासेटला लहान, व्यवस्थापित करण्यायोग्य भागांमध्ये विभागण्याचे हे एक महत्त्वाचे तंत्र आहे.

Django REST फ्रेमवर्क (DRF) उत्कृष्ट इन-बिल्ट पेजिनेशन पर्याय प्रदान करते जे बहुतेक सामान्य गरजा पूर्ण करतात. तथापि, जसजशा तुमच्या API च्या गरजा विकसित होतात, विशेषतः जेव्हा विविध जागतिक प्रेक्षकांना सेवा देताना किंवा विशिष्ट फ्रंटएंड फ्रेमवर्कसह एकत्रित करताना, तुम्हाला अनेकदा डीफॉल्ट पर्यायांच्या पलीकडे जाण्याची आवश्यकता भासेल. हे सर्वसमावेशक मार्गदर्शक DRF च्या पेजिनेशन क्षमतांचा सखोल अभ्यास करेल, आणि तुमच्या API च्या डेटा वितरणावर अतुलनीय लवचिकता आणि नियंत्रण देणारे कस्टम पेजिनेशन क्लासेस कसे तयार करावे यावर लक्ष केंद्रित करेल.

तुम्ही जागतिक ई-कॉमर्स प्लॅटफॉर्म, डेटा ॲनालिटिक्स सेवा, किंवा सोशल नेटवर्क तयार करत असाल तरी, जगभरात उच्च-कार्यक्षमता आणि वापरकर्ता-अनुकूल अनुभव देण्यासाठी अनुकूल पेजिनेशन धोरणे समजून घेणे आणि अंमलात आणणे महत्त्वाचे आहे.

API पेजिनेशनचे सार

मूलतः, API पेजिनेशन म्हणजे डेटाबेस क्वेरीमधून मिळालेल्या मोठ्या परिणामांच्या संचाला डेटाच्या वेगळ्या "पानांमध्ये" किंवा "स्लाइसमध्ये" विभागण्याची प्रक्रिया. एकाच वेळी शेकडो किंवा हजारो रेकॉर्ड्स परत करण्याऐवजी, API एक लहान उपसंच परत करते, सोबत मेटाडेटा देतो जो क्लायंटला उर्वरित डेटामधून नेव्हिगेट करण्यास मदत करतो.

आधुनिक APIs साठी पेजिनेशन अपरिहार्य का आहे?

• कार्यक्षमता ऑप्टिमायझेशन (Performance Optimization): नेटवर्कवर कमी डेटा पाठवल्याने बँडविड्थचा वापर कमी होतो आणि प्रतिसादाची वेळ सुधारते, जे कमी गतीच्या इंटरनेट कनेक्शन असलेल्या प्रदेशांमधील वापरकर्त्यांसाठी महत्त्वपूर्ण आहे.
• वर्धित वापरकर्ता अनुभव (Enhanced User Experience): वापरकर्त्यांना संपूर्ण डेटासेट लोड होण्याची प्रतीक्षा करायची नसते. डेटाचे पेजिनेशन केल्याने जलद सुरुवातीच्या लोड वेळा आणि एक सहज ब्राउझिंग अनुभव मिळतो, विशेषतः मोबाइल डिव्हाइसवर.
• सर्व्हरवरील भार कमी (Reduced Server Load): मोठे क्वेरीसेट मिळवणे आणि सिरियलाइज करणे सर्व्हरची लक्षणीय संसाधने (CPU, मेमरी) वापरू शकते. पेजिनेशन हा ताण मर्यादित करते, ज्यामुळे तुमचा API अधिक मजबूत आणि स्केलेबल बनतो.
• कार्यक्षम डेटा हाताळणी (Efficient Data Handling): क्लायंटसाठी, डेटाचे लहान तुकडे प्रक्रिया करणे सोपे आणि कमी मेमरी-केंद्रित असते, ज्यामुळे अधिक प्रतिसादक्षम ॲप्लिकेशन्स तयार होतात.
• जागतिक स्केलेबिलिटी (Global Scalability): जसा तुमचा वापरकर्ता आधार जगभरात विस्तारतो, तसा डेटाचे प्रमाण प्रचंड वाढते. प्रभावी पेजिनेशन हे सुनिश्चित करते की तुमचा API डेटाच्या प्रमाणाची पर्वा न करता कार्यक्षम राहील.

DRF चे इन-बिल्ट पेजिनेशन पर्याय: एक संक्षिप्त आढावा

Django REST फ्रेमवर्क बॉक्सच्या बाहेर तीन प्राथमिक पेजिनेशन शैली प्रदान करते, प्रत्येक वेगवेगळ्या परिस्थितींसाठी योग्य आहे:

१. PageNumberPagination

ही कदाचित सर्वात सामान्य आणि सोपी पेजिनेशन शैली आहे. क्लायंट एक विशिष्ट पान क्रमांक आणि पर्यायाने पानाचा आकार सांगतात. DRF त्या पानावरील परिणाम परत करते, सोबत पुढील आणि मागील पानांच्या लिंक्स आणि एकूण आयटमची संख्या देते.

उदाहरण विनंती: /items/?page=2&page_size=10

वापराची प्रकरणे: स्पष्ट पान नेव्हिगेशन असलेल्या पारंपारिक वेब ॲप्लिकेशन्ससाठी आदर्श (उदा. "पान १० पैकी १").

जागतिक विचार: लक्षात ठेवा की काही सिस्टीम ०-इंडेक्स पाने पसंत करू शकतात. DRF डीफॉल्टनुसार १-इंडेक्स वापरते, जे जागतिक स्तरावर सामान्य आहे, परंतु सानुकूलनाची आवश्यकता असू शकते.

मूलभूत सेटअप (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10
}
            

              
                Copy
              
            
          

२. LimitOffsetPagination

ही शैली क्लायंटला एक offset (किती आयटम वगळायचे) आणि एक limit (किती आयटम परत करायचे) निर्दिष्ट करण्याची परवानगी देते. हे इन्फिनिट स्क्रोलिंग सारख्या परिस्थितींसाठी किंवा जेव्हा क्लायंटला डेटा पुनर्प्राप्तीवर अधिक नियंत्रण हवे असते तेव्हा अधिक लवचिक असते.

उदाहरण विनंती: /items/?limit=10&offset=20

वापराची प्रकरणे: इन्फिनिट स्क्रोल, कस्टम पेजिनेशन लॉजिक किंवा डेटाबेस-शैलीतील स्लाइसिंग लागू करणाऱ्या क्लायंटसाठी उत्तम.

जागतिक विचार: जे क्लायंट ऑफसेटवर आधारित स्वतःची "पाने" व्यवस्थापित करण्यास प्राधान्य देतात त्यांच्यासाठी खूप लवचिक, जे विविध फ्रंट-एंड लायब्ररी किंवा मोबाइल क्लायंटसह एकत्रीकरणासाठी फायदेशीर ठरू शकते.

मूलभूत सेटअप (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.LimitOffsetPagination',
    'PAGE_SIZE': 10  # default limit if not provided
}
            

              
                Copy
              
            
          

३. CursorPagination

कर्सर पेजिनेशन अत्यंत मोठ्या डेटासेटसाठी किंवा जेव्हा सातत्यपूर्ण क्रमवारी महत्त्वाची असते तेव्हा अधिक मजबूत उपाय प्रदान करते. पान क्रमांक किंवा ऑफसेट वापरण्याऐवजी, ते परिणामांचा पुढील संच निश्चित करण्यासाठी एक अपारदर्शक "कर्सर" (बहुतेकदा एनकोड केलेला टाइमस्टॅम्प किंवा युनिक आयडेंटिफायर) वापरते. ही पद्धत पेजिनेशन दरम्यान डेटा समाविष्ट/हटवल्यामुळे होणाऱ्या डुप्लिकेट किंवा वगळलेल्या आयटमसाठी अत्यंत प्रतिरोधक आहे.

उदाहरण विनंती: /items/?cursor=cD0xMjM0NTY3ODkwMTIyMzM0NQ%3D%3D

वापराची प्रकरणे: "इन्फिनिट स्क्रोल" परिस्थितींसाठी आदर्श जेथे डेटासेट सतत बदलत असतो (उदा. सोशल मीडिया फीड), किंवा जेव्हा लाखो रेकॉर्ड्स हाताळताना कार्यक्षमता आणि सुसंगतता अत्यंत महत्त्वाची असते.

जागतिक विचार: सतत अद्यतनित होणाऱ्या डेटासाठी उत्कृष्ट सुसंगतता प्रदान करते, हे सुनिश्चित करते की सर्व जागतिक वापरकर्त्यांना माहितीचा एक विश्वसनीय, क्रमबद्ध प्रवाह दिसेल, मग त्यांनी त्यांची विनंती केव्हाही सुरू केली असली तरी.

मूलभूत सेटअप (settings.py):

            REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.CursorPagination',
    'PAGE_SIZE': 10,
    'CURSOR_ORDERING': '-created_at' # Field to order by
}
            

              
                Copy
              
            
          

कस्टम का जायचे? अनुकूल पेजिनेशनची शक्ती

DRF चे इन-बिल्ट पर्याय शक्तिशाली असले तरी, अशा अनेक परिस्थिती आहेत जिथे ते तुमच्या विशिष्ट आर्किटेक्चरल गरजा, क्लायंट आवश्यकता किंवा व्यावसायिक तर्काशी पूर्णपणे जुळत नाहीत. इथेच एक कस्टम पेजिनेशन क्लास तयार करणे अनमोल ठरते.

जेव्हा इन-बिल्ट पुरेसे नसते:

• युनिक फ्रंटएंड आवश्यकता: तुमच्या फ्रंटएंडला विशिष्ट पॅरामीटर नावे (उदा. page आणि page_size ऐवजी start आणि limit) किंवा अतिरिक्त मेटाडेटा (जसे की प्रदर्शित आयटमची श्रेणी, किंवा जटिल सारांश आकडेवारी) समाविष्ट करणारी सानुकूल प्रतिसाद रचना आवश्यक असू शकते.
• बाह्य किंवा लेगसी सिस्टीमसह एकत्रीकरण: थर्ड-पार्टी APIs किंवा जुन्या सेवांसह एकत्रित करताना, तुम्हाला त्यांचे पेजिनेशन पॅरामीटर्स किंवा प्रतिसाद स्वरूप अचूकपणे अनुकरण करावे लागू शकते.
• जटिल व्यावसायिक तर्क: कदाचित पानाचा आकार वापरकर्त्याच्या भूमिका, सबस्क्रिप्शन टियर किंवा क्वेरी केलेल्या डेटाच्या प्रकारानुसार गतिशीलपणे बदलला पाहिजे.
• वर्धित मेटाडेटा गरजा: count, next, आणि previous च्या पलीकडे, तुम्हाला current_page, total_pages, items_on_page, किंवा तुमच्या जागतिक वापरकर्ता आधाराशी संबंधित इतर सानुकूल आकडेवारी समाविष्ट करण्याची आवश्यकता असू शकते.
• विशिष्ट क्वेरींसाठी कार्यक्षमता ऑप्टिमायझेशन: अत्यंत विशेष डेटा ऍक्सेस पॅटर्नसाठी, एक कस्टम पेजिनेशन क्लास डेटाबेससह अधिक कार्यक्षमतेने संवाद साधण्यासाठी ऑप्टिमाइझ केला जाऊ शकतो.
• जागतिक सुसंगतता आणि प्रवेशयोग्यता: API प्रतिसाद विविध भौगोलिक प्रदेशांमधील विविध क्लायंटद्वारे सुसंगत आणि सहजपणे पार्स करण्यायोग्य असल्याची खात्री करणे, संभाव्यतः भिन्न भाषा-विशिष्ट पॅरामीटर्स ऑफर करणे (जरी सामान्यतः API एंडपॉइंटसाठी शिफारस केलेली नसली तरी, क्लायंट-साइड प्रतिनिधित्वासाठी).
• सानुकूल तर्कासह "अधिक लोड करा" / इन्फिनिट स्क्रोल: LimitOffsetPagination वापरता येत असले तरी, एक कस्टम क्लास "अधिक लोड करा" कार्यक्षमता कशी वागते यावर सूक्ष्म-नियंत्रण प्रदान करते, ज्यात वापरकर्त्याच्या वर्तनावर किंवा नेटवर्क परिस्थितीवर आधारित गतिशील समायोजन समाविष्ट आहे.

तुमचा पहिला कस्टम पेजिनेशन क्लास तयार करणे

DRF मधील सर्व कस्टम पेजिनेशन क्लासेस rest_framework.pagination.BasePagination किंवा त्याच्या विद्यमान ठोस अंमलबजावणी जसे की PageNumberPagination किंवा LimitOffsetPagination पासून इनहेरिट केले पाहिजेत. विद्यमान क्लासमधून इनहेरिट करणे अनेकदा सोपे असते कारण ते बरेच बॉयलरप्लेट लॉजिक प्रदान करते.

बेस पेजिनेशन घटकांना समजून घेणे

BasePagination वाढवताना, तुम्ही सामान्यतः दोन मुख्य पद्धती ओव्हरराइड कराल:

• paginate_queryset(self, queryset, request, view=None): ही पद्धत संपूर्ण क्वेरीसेट, वर्तमान विनंती आणि व्ह्यू घेते. तिची जबाबदारी क्वेरीसेटला स्लाइस करणे आणि वर्तमान "पानासाठी" ऑब्जेक्ट्स परत करणे आहे. तिने नंतरच्या वापरासाठी पेजिनेटेड पेज ऑब्जेक्ट (उदा. self.page मध्ये) संग्रहित केले पाहिजे.
• get_paginated_response(self, data): ही पद्धत वर्तमान पानाच्या सिरियलाइज्ड डेटा घेते आणि पेजिनेटेड डेटा आणि कोणत्याही अतिरिक्त पेजिनेशन मेटाडेटा (जसे की पुढील/मागील लिंक्स, एकूण संख्या, इत्यादी) असलेले Response ऑब्जेक्ट परत केले पाहिजे.

सोप्या बदलांसाठी, PageNumberPagination किंवा LimitOffsetPagination पासून इनहेरिट करणे आणि फक्त काही ॲट्रिब्यूट्स किंवा मदतनीस पद्धती ओव्हरराइड करणे अनेकदा पुरेसे असते.

उदाहरण १: वर्धित मेटाडेटासह CustomPageNumberPagination

समजा तुमच्या जागतिक क्लायंटना पेजिनेशन प्रतिसादामध्ये अधिक तपशीलवार माहितीची आवश्यकता आहे, जसे की वर्तमान पान क्रमांक, एकूण पानांची संख्या, आणि वर्तमान पानावर प्रदर्शित होत असलेल्या आयटमची श्रेणी, DRF च्या डीफॉल्ट count, next, आणि previous व्यतिरिक्त. आम्ही PageNumberPagination चा विस्तार करू.

तुमच्या ॲप किंवा प्रोजेक्ट डिरेक्टरीमध्ये pagination.py नावाची फाईल तयार करा:

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination
from rest_framework.response import Response

class CustomPaginationWithMetadata(PageNumberPagination):
    page_size = 10
    page_size_query_param = 'page_size'
    max_page_size = 100

    def get_paginated_response(self, data):
        return Response({
            'links': {
                'next': self.get_next_link(),
                'previous': self.get_previous_link()
            },
            'pagination_info': {
                'total_items': self.page.paginator.count,
                'total_pages': self.page.paginator.num_pages,
                'current_page': self.page.number,
                'items_per_page': self.get_page_size(self.request),
                'current_page_items_count': len(data),
                'start_item_index': self.page.start_index(), # 1-based index
                'end_item_index': self.page.end_index() # 1-based index
            },
            'data': data
        })
            

              
                Copy
              
            
          

स्पष्टीकरण:

• आम्ही PageNumberPagination पासून इनहेरिट करतो जेणेकरून page आणि page_size पॅरामीटर्स हाताळण्यासाठी त्याच्या मूळ तर्काचा फायदा घेता येईल.
• JSON प्रतिसाद रचना सानुकूलित करण्यासाठी आम्ही get_paginated_response ओव्हरराइड करतो.
• आम्ही एक 'pagination_info' डिक्शनरी जोडली आहे ज्यात हे समाविष्ट आहे:
• total_items: सर्व आयटमची एकूण संख्या (सर्व पानांवर).
• total_pages: उपलब्ध एकूण पानांची संख्या.
• current_page: वर्तमान प्रतिसादाचा पान क्रमांक.
• items_per_page: प्रति पान कमाल आयटमची संख्या.
• current_page_items_count: वर्तमान पानावर परत आलेल्या आयटमची वास्तविक संख्या.
• start_item_index आणि end_item_index: वर्तमान पानावरील आयटमची १-आधारित इंडेक्स श्रेणी, जी UIs साठी खूप उपयुक्त असू शकते जी "आयटम X-Y पैकी Z" दर्शवते.
• स्पष्टतेसाठी वास्तविक डेटा 'data' की अंतर्गत नेस्ट केलेला आहे.

एका व्ह्यूवर कस्टम पेजिनेशन लागू करणे:

            # myapp/views.py

from rest_framework import generics
from .models import Product
from .serializers import ProductSerializer
from .pagination import CustomPaginationWithMetadata

class ProductListView(generics.ListAPIView):
    queryset = Product.objects.all().order_by('id')
    serializer_class = ProductSerializer
    pagination_class = CustomPaginationWithMetadata # Apply your custom class
            

              
                Copy
              
            
          

आता, जेव्हा तुम्ही /products/?page=1&page_size=5 ऍक्सेस कराल, तेव्हा तुम्हाला असा प्रतिसाद मिळेल:

            {
    "links": {
        "next": "http://api.example.com/products/?page=2&page_size=5",
        "previous": null
    },
    "pagination_info": {
        "total_items": 25,
        "total_pages": 5,
        "current_page": 1,
        "items_per_page": 5,
        "current_page_items_count": 5,
        "start_item_index": 1,
        "end_item_index": 5
    },
    "data": [
        { "id": 1, "name": "Global Gadget A", "price": "29.99" },
        { "id": 2, "name": "Regional Widget B", "price": "15.50" }
    ]
}
            

              
                Copy
              
            
          

हे वर्धित मेटाडेटा जटिल UIs तयार करणाऱ्या फ्रंटएंड डेव्हलपर्ससाठी अविश्वसनीयपणे उपयुक्त आहे, जे त्यांच्या भौगोलिक स्थानाची किंवा पसंतीच्या फ्रेमवर्कची पर्वा न करता एक सुसंगत आणि समृद्ध डेटा रचना प्रदान करते.

उदाहरण २: डीफॉल्ट आणि कमाल मर्यादांसह FlexiblePageSizePagination

अनेकदा, तुम्हाला क्लायंटला त्यांच्या पसंतीचा पानाचा आकार निर्दिष्ट करण्याची परवानगी द्यायची असते परंतु गैरवापर टाळण्यासाठी आणि सर्व्हर लोड व्यवस्थापित करण्यासाठी कमाल मर्यादा देखील लागू करायची असते. ही सार्वजनिक-मुखी जागतिक APIs साठी एक सामान्य आवश्यकता आहे. चला एक कस्टम क्लास तयार करूया जो PageNumberPagination वर आधारित आहे.

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination

class FlexiblePageSizePagination(PageNumberPagination):
    page_size = 20  # Default page size if not specified by client
    page_size_query_param = 'limit' # Client uses 'limit' instead of 'page_size'
    max_page_size = 50 # Maximum page size allowed

    # Optionally, you can also customize the page query parameter name:
    page_query_param = 'page_number' # Client uses 'page_number' instead of 'page'
            

              
                Copy
              
            
          

स्पष्टीकरण:

• page_size: क्लायंटने limit पॅरामीटर प्रदान न केल्यास प्रति पान आयटमची डीफॉल्ट संख्या सेट करते.
• page_size_query_param = 'limit': क्लायंट विशिष्ट पानाचा आकार विनंती करण्यासाठी वापरत असलेल्या क्वेरी पॅरामीटरला page_size वरून limit मध्ये बदलते.
• max_page_size = 50: हे सुनिश्चित करते की जरी क्लायंटने limit=5000 विनंती केली तरी, API प्रति पान फक्त कमाल ५० आयटम परत करेल, ज्यामुळे संसाधनांचा ऱ्हास टाळता येतो.
• page_query_param = 'page_number': पान क्रमांकासाठी क्वेरी पॅरामीटरला page वरून page_number मध्ये बदलते.

हे लागू करणे:

            # myapp/views.py

from rest_framework import generics
from .models import Item
from .serializers import ItemSerializer
from .pagination import FlexiblePageSizePagination

class ItemListView(generics.ListAPIView):
    queryset = Item.objects.all().order_by('name')
    serializer_class = ItemSerializer
    pagination_class = FlexiblePageSizePagination
            

              
                Copy
              
            
          

आता, क्लायंट /items/?page_number=3&limit=30 विनंती करू शकतात. जर त्यांनी limit=100 विनंती केली, तर API शांतपणे ते ५० वर मर्यादित करेल, API वापरावरील मजबूत नियंत्रण प्रदान करेल.

प्रगत सानुकूलन परिस्थिती

१. क्वेरी पॅरामीटर्स पूर्णपणे सानुकूलित करणे

जर तुम्हाला पूर्णपणे भिन्न क्वेरी पॅरामीटर्सची आवश्यकता असेल, जसे की start_index आणि item_count, जे काही जुन्या API डिझाइन किंवा विशिष्ट भागीदार एकत्रीकरणांचे अनुकरण करतात? तुम्हाला हे पॅरामीटर्स पार्स करणाऱ्या पद्धती ओव्हरराइड कराव्या लागतील.

            # myapp/pagination.py

from rest_framework.pagination import PageNumberPagination
from rest_framework.response import Response

class StartIndexItemCountPagination(PageNumberPagination):
    # Override the default page_size for this custom scheme
    page_size = 10
    page_size_query_param = 'item_count'
    max_page_size = 100
    
    start_index_query_param = 'start_index'

    def get_page_number(self, request):
        try:
            # The start_index is 1-based, we need to convert it to a 0-based offset
            # then calculate the page number based on page_size
            start_index = int(request.query_params.get(self.start_index_query_param, 1))
            page_size = self.get_page_size(request)
            if page_size == 0: # Avoid division by zero
                return 1
            # Convert 1-based start_index to 0-based offset, then to page number
            # e.g., start_index=1, page_size=10 -> page 1
            # e.g., start_index=11, page_size=10 -> page 2
            return (start_index - 1) // page_size + 1
        except (TypeError, ValueError):
            return 1 # Default to page 1 if invalid

    def get_paginated_response(self, data):
        # You can still use the enhanced metadata here from Example 1 if desired
        return Response({
            'meta': {
                'total_records': self.page.paginator.count,
                'start': self.page.start_index(),
                'count': len(data),
                'next_start_index': self.get_next_start_index() # Custom next link logic
            },
            'data': data
        })

    def get_next_start_index(self):
        if not self.page.has_next():
            return None
        page_size = self.get_page_size(self.request)
        # Next page's start index is current end index + 1
        return self.page.end_index() + 1

    def get_next_link(self):
        # We need to rebuild the next link using our custom parameters
        if not self.page.has_next():
            return None

        url = self.request.build_absolute_uri()
        page_size = self.get_page_size(self.request)
        next_start_index = self.page.end_index() + 1

        # Use parse_qsl and urlencode for robust query param handling
        from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode
        
        scheme, netloc, path, params, query, fragment = urlparse(url);
        query_params = dict(parse_qsl(query))

        query_params[self.start_index_query_param] = next_start_index
        query_params[self.page_size_query_param] = page_size

        return urlunparse((scheme, netloc, path, params, urlencode(query_params), fragment)) 

    # You might also need to override get_previous_link similarly
    def get_previous_link(self):
        if not self.page.has_previous():
            return None

        url = self.request.build_absolute_uri()
        page_size = self.get_page_size(self.request)
        # Previous page's start index is current start index - page_size
        previous_start_index = self.page.start_index() - page_size
        if previous_start_index < 1:
            previous_start_index = 1

        from urllib.parse import urlparse, urlunparse, parse_qsl, urlencode
        
        scheme, netloc, path, params, query, fragment = urlparse(url);
        query_params = dict(parse_qsl(query))

        query_params[self.start_index_query_param] = previous_start_index
        query_params[self.page_size_query_param] = page_size

        return urlunparse((scheme, netloc, path, params, urlencode(query_params), fragment))


            

              
                Copy
              
            
          

मुख्य निष्कर्ष:

• सानुकूल start_index ला DRF च्या अंतर्गत पान क्रमांक संकल्पनेशी मॅप करण्यासाठी get_page_number ओव्हरराइड करणे महत्त्वाचे आहे.
• तुम्हाला get_next_link आणि get_previous_link देखील समायोजित करावे लागेल जेणेकरून व्युत्पन्न केलेले URLs तुमचे सानुकूल क्वेरी पॅरामीटर्स (start_index आणि item_count) योग्यरित्या वापरतील.
• हा दृष्टिकोन विशिष्ट अ-मानक पेजिनेशन योजनांची अपेक्षा करणाऱ्या क्लायंटसह अखंड एकत्रीकरणास अनुमती देतो, जे जागतिक स्तरावर जोडलेल्या प्रणालीमध्ये जिथे विविध मानके एकत्र अस्तित्वात असू शकतात तिथे महत्त्वाचे आहे.

२. शुद्ध "अधिक लोड करा" किंवा इन्फिनिट स्क्रोल लागू करणे

मोबाइल ॲप्लिकेशन्स किंवा सिंगल-पेज वेब ॲप्लिकेशन्ससाठी, "इन्फिनिट स्क्रोल" किंवा "अधिक लोड करा" पॅटर्नला अनेकदा प्राधान्य दिले जाते. याचा सामान्यतः अर्थ असा होतो की API फक्त next लिंक परत करते (जर अधिक डेटा उपलब्ध असेल) आणि कोणतेही पान क्रमांक किंवा एकूण संख्या नाही. LimitOffsetPagination एक चांगला प्रारंभ बिंदू आहे, परंतु आम्ही त्याचे आउटपुट सोपे करू शकतो.

            # myapp/pagination.py

from rest_framework.pagination import LimitOffsetPagination
from rest_framework.response import Response

class InfiniteScrollPagination(LimitOffsetPagination):
    default_limit = 25
    max_limit = 100
    limit_query_param = 'count'
    offset_query_param = 'start'

    def get_paginated_response(self, data):
        return Response({
            'next': self.get_next_link(),
            'previous': self.get_previous_link(),
            'results': data
        })
            

              
                Copy
              
            
          

स्पष्टीकरण:

• आम्ही get_paginated_response ला फक्त next, previous, आणि results समाविष्ट करण्यासाठी सोपे करतो.
• आम्ही क्वेरी पॅरामीटर्सला count (लिमिटसाठी) आणि start (ऑफसेटसाठी) सानुकूलित केले आहे, जे "अधिक लोड करा" परिस्थितींमध्ये सामान्य आहेत.
• हा पॅटर्न जागतिक सामग्री फीडसाठी अत्यंत प्रभावी आहे जिथे वापरकर्ते सतत डेटामधून स्क्रोल करतात, एक अखंड अनुभव प्रदान करतात.

तुमच्या DRF प्रोजेक्टमध्ये कस्टम पेजिनेशन एकत्रित करणे

एकदा तुम्ही तुमचे कस्टम पेजिनेशन क्लासेस परिभाषित केले की, तुमच्याकडे त्यांना तुमच्या DRF प्रोजेक्टमध्ये एकत्रित करण्याचे दोन प्राथमिक मार्ग आहेत:

१. ग्लोबल डीफॉल्ट पेजिनेशन

तुम्ही तुमच्या settings.py फाईलमध्ये REST_FRAMEWORK कॉन्फिगर करून तुमच्या प्रोजेक्टमधील सर्व API व्ह्यूजसाठी एक कस्टम पेजिनेशन क्लास डीफॉल्ट म्हणून सेट करू शकता:

            # settings.py

REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'myapp.pagination.CustomPaginationWithMetadata',
    'PAGE_SIZE': 15, # Default page size for views using this class globally
    # ... other DRF settings
}
            

              
                Copy
              
            
          

हे उपयुक्त आहे जर तुमचे बहुतेक API एंडपॉइंट्स समान पेजिनेशन लॉजिक वापरणार असतील, ज्यामुळे तुमच्या ॲप्लिकेशनमध्ये सर्व जागतिक क्लायंटसाठी सुसंगत वर्तन सुनिश्चित होते.

२. प्रति-व्ह्यू पेजिनेशन

अधिक सूक्ष्म नियंत्रणासाठी, तुम्ही थेट एका वैयक्तिक व्ह्यू किंवा व्ह्यूसेटवर एक विशिष्ट पेजिनेशन क्लास लागू करू शकता:

            # myapp/views.py

from rest_framework import generics
from .models import Order
from .serializers import OrderSerializer
from .pagination import InfiniteScrollPagination, CustomPaginationWithMetadata

class RecentOrdersView(generics.ListAPIView):
    queryset = Order.objects.all().order_by('-order_date')
    serializer_class = OrderSerializer
    pagination_class = InfiniteScrollPagination # Specific to this view

class ProductCatalogView(generics.ListAPIView):
    queryset = Product.objects.all().order_by('name')
    serializer_class = ProductSerializer
    pagination_class = CustomPaginationWithMetadata # Another specific class
            

              
                Copy
              
            
          

ही लवचिकता तुम्हाला प्रत्येक एंडपॉइंटच्या गरजेनुसार पेजिनेशन वर्तन अचूकपणे अनुकूल करण्याची परवानगी देते, विविध क्लायंट प्रकारांना (उदा. मोबाइल ॲप विरुद्ध डेस्कटॉप वेब विरुद्ध भागीदार एकत्रीकरण) किंवा विविध डेटा प्रकारांना पूर्ण करते.

जागतिक API पेजिनेशनसाठी सर्वोत्तम पद्धती

जागतिक प्रेक्षकांद्वारे वापरल्या जाणाऱ्या APIs साठी पेजिनेशन लागू करताना, मजबूतपणा, कार्यक्षमता आणि एक सुसंगत डेव्हलपर अनुभव सुनिश्चित करण्यासाठी या सर्वोत्तम पद्धतींचा विचार करा:

• सुसंगतता महत्त्वाची आहे: तुमच्या संपूर्ण API मध्ये, किंवा किमान एंडपॉइंट्सच्या तार्किक गटांमध्ये, एक सुसंगत पेजिनेशन प्रतिसाद रचना मिळवण्याचा प्रयत्न करा. यामुळे तुमच्या API सह एकत्रित होणाऱ्या डेव्हलपर्ससाठी घर्षण कमी होते, मग ते टोकियोमध्ये असोत किंवा टोरंटोमध्ये.
• स्पष्ट दस्तऐवजीकरण: तुमचे पेजिनेशन पॅरामीटर्स (उदा. page, limit, cursor, start_index) आणि अपेक्षित प्रतिसाद स्वरूप यांचे सखोल दस्तऐवजीकरण करा. प्रत्येक प्रकारासाठी उदाहरणे द्या. हे आंतरराष्ट्रीय डेव्हलपर्ससाठी महत्त्वाचे आहे ज्यांना स्पष्टीकरणासाठी तुमच्या टीमशी थेट संपर्क साधता येत नाही. OpenAPI (Swagger) सारखी साधने येथे खूप मदत करू शकतात.
• कार्यक्षमता ऑप्टिमायझेशन:
• डेटाबेस इंडेक्स: क्रमवारीसाठी वापरलेली फील्ड (उदा. id, created_at) तुमच्या डेटाबेसमध्ये योग्यरित्या अनुक्रमित असल्याची खात्री करा जेणेकरून क्वेरी जलद होतील, विशेषतः ORDER BY क्लॉजसाठी.
• क्वेरी ऑप्टिमायझेशन: तुमच्या डेटाबेस क्वेरींचे निरीक्षण करा. जेव्हा फक्त विशिष्ट फील्डची आवश्यकता असेल तेव्हा SELECT * टाळा.
• कॅशिंग: डेटाबेस लोड कमी करण्यासाठी वारंवार ऍक्सेस केलेल्या स्थिर किंवा हळू बदलणाऱ्या पेजिनेटेड डेटासाठी कॅशिंग लागू करा.
• सुरक्षा आणि गैरवापर प्रतिबंध:
• क्लायंटला जास्त मोठे डेटासेट विनंती करण्यापासून रोखण्यासाठी नेहमी max_page_size (किंवा max_limit) लागू करा, ज्यामुळे डिनायल-ऑफ-सर्व्हिस (DoS) हल्ले किंवा संसाधनांचा ऱ्हास होऊ शकतो.
• पेजिनेशनसाठी सर्व इनपुट पॅरामीटर्स सत्यापित करा (उदा. पान क्रमांक सकारात्मक पूर्णांक असल्याची खात्री करा).
• वापरकर्ता अनुभव विचार:
• स्पष्ट नेव्हिगेशन लिंक्स (next, previous) प्रदान करा.
• UIs साठी, आयटमची एकूण संख्या आणि एकूण पाने (लागू असल्यास) दर्शवणे वापरकर्त्यांना उपलब्ध डेटाची व्याप्ती समजण्यास मदत करते.
• प्रदर्शनाचा क्रम विचारात घ्या. जागतिक डेटासाठी, अनेकदा एक सुसंगत created_at किंवा id आधारित क्रमवारी स्थानिक-विशिष्ट क्रमवारीपेक्षा चांगली असते जोपर्यंत स्पष्टपणे विनंती केली जात नाही.
• त्रुटी हाताळणी: पेजिनेशन पॅरामीटर्स अवैध किंवा श्रेणीबाहेर असताना स्पष्ट, वर्णनात्मक त्रुटी संदेश (उदा. 400 Bad Request) परत करा.
• सखोल चाचणी: विविध पानांच्या आकारांसह, डेटासेटच्या सुरुवातीला आणि शेवटी, आणि रिकाम्या डेटासेटसह पेजिनेशनची चाचणी घ्या. हे विशेषतः सानुकूल अंमलबजावणीसाठी महत्त्वाचे आहे.

निष्कर्ष

Django REST फ्रेमवर्कची पेजिनेशन प्रणाली मजबूत आणि अत्यंत विस्तारक्षम आहे. इन-बिल्ट PageNumberPagination, LimitOffsetPagination, आणि CursorPagination क्लासेस अनेक वापराची प्रकरणे कव्हर करत असले तरी, कस्टम पेजिनेशन क्लासेस तयार करण्याची क्षमता तुम्हाला तुमच्या API च्या डेटा वितरणाला विशिष्ट आवश्यकतांनुसार पूर्णपणे अनुकूल करण्यास सक्षम करते.

डीफॉल्ट वर्तने कशी ओव्हरराइड करावी, समृद्ध मेटाडेटा कसा जोडावा, किंवा पॅरामीटर योजना पूर्णपणे कशी बदलावी हे समजून घेऊन, तुम्ही असे APIs तयार करू शकता जे केवळ कार्यक्षम आणि कार्यक्षमच नाहीत तर जागतिक प्रेक्षकांसाठी अविश्वसनीयपणे लवचिक आणि डेव्हलपर-अनुकूल देखील आहेत. तुमच्या Django REST फ्रेमवर्क ॲप्लिकेशन्सची पूर्ण क्षमता अनलॉक करण्यासाठी आणि जगभरातील वापरकर्त्यांना आणि इंटिग्रेटर्सना एक उत्कृष्ट अनुभव देण्यासाठी कस्टम पेजिनेशनचा स्वीकार करा.

तुम्ही कोणत्या कस्टम पेजिनेशन आव्हानांचा सामना केला आहे? खालील टिप्पण्यांमध्ये तुमचे अंतर्दृष्टी आणि उपाय सामायिक करा!