Pagination API REST: Guide Approfondie

Dans le monde du développement d'applications modernes, les API REST servent de couche de communication fondamentale, permettant à des systèmes disparates d'échanger des données de manière transparente. À mesure que les applications augmentent en taille et en complexité, le volume de données qu'elles gèrent augmente également. Demander un ensemble de données entier, contenant potentiellement des millions, voire des milliards d'enregistrements, en un seul appel API est inefficace, peu fiable et constitue un goulot d'étranglement majeur en termes de performances. C'est là qu'intervient une technique cruciale dans la conception et le développement d'API : la pagination d'API REST. Ce guide offre un aperçu approfondi et complet de la mise en œuvre de la pagination dans les API REST, couvrant tout, des concepts fondamentaux aux implémentations avancées dans le monde réel à l'aide de diverses piles technologiques comme Node.js, Python et .NET.

Les Fondamentaux de la Pagination d'API REST

Avant de plonger dans des exemples de code complexes et des modèles de conception, il est essentiel d'avoir une solide compréhension de ce qu'est la pagination et pourquoi elle est un aspect non négociable de la conception d'API professionnelle.

Qu'est-ce que la Pagination dans les API REST ?

À la base, la pagination d'API REST est une technique utilisée pour prendre la réponse d'un point de terminaison d'API REST et la segmenter en unités plus petites et plus gérables, souvent appelées "pages". Au lieu de fournir un ensemble de données potentiellement massif en une seule fois, l'API renvoie un petit morceau prévisible des données. De manière cruciale, la réponse de l'API inclut également des métadonnées qui permettent à un client de récupérer incrémentalement les morceaux suivants s'il a besoin de plus de données.

Ce processus est analogue aux pages d'un livre ou aux résultats de recherche sur Google. On vous présente la première page de résultats, ainsi que des contrôles pour naviguer vers la deuxième, la troisième, et ainsi de suite. Comme le soulignent des communautés de développeurs comme DEV Community et des plateformes telles que Merge.dev, il s'agit du processus de division d'un grand ensemble de données en morceaux plus petits, qui peuvent être récupérés incrémentalement par un client s'il souhaite vraiment toutes ces données. C'est un concept fondamental pour la construction d'applications robustes et évolutives.

Pourquoi la Pagination est-elle une Exigence Fondamentale dans la Conception d'API Moderne ?

La motivation principale de la pagination est de garantir que les réponses API sont plus faciles à gérer pour le serveur et le client. Sans elle, les applications seraient confrontées à de sévères limitations et à une mauvaise expérience utilisateur. Les principaux avantages incluent :

• Amélioration des Performances et Réduction de la Latence : L'avantage le plus significatif est la vitesse. Transférer une petite charge utile JSON de 25 enregistrements est infiniment plus rapide que de transférer une charge utile de 2,5 millions d'enregistrements. Cela se traduit par une sensation rapide et réactive pour l'utilisateur final.
• Fiabilité Améliorée de l'API : Les réponses HTTP volumineuses ont une probabilité plus élevée d'échouer en cours de transfert en raison de délais d'attente réseau, de connexions interrompues ou de limites de mémoire côté client. La pagination crée des requêtes plus petites et plus résilientes. Si une page ne parvient pas à se charger, le client peut simplement réessayer cette requête spécifique sans avoir à recommencer tout le transfert de données.
• Réduction de la Charge Serveur : Générer une réponse massive peut mettre une pression importante sur les ressources du serveur. La requête de base de données peut être lente, et la sérialisation de millions d'enregistrements en JSON consomme une quantité considérable de CPU et de mémoire. La pagination permet au serveur d'effectuer des requêtes plus petites et plus efficaces, améliorant sa capacité globale et sa capacité à servir plusieurs clients simultanément.
• Traitement Efficace Côté Client : Pour les applications clientes, en particulier celles exécutées sur des appareils mobiles ou dans un navigateur web, l'analyse d'un énorme objet JSON peut bloquer l'interface utilisateur et entraîner une expérience frustrante. Les morceaux de données plus petits sont plus faciles à analyser et à afficher, ce qui se traduit par une application plus fluide.

Stratégies et Techniques Courantes de Pagination

Il existe plusieurs façons d'implémenter la pagination, mais deux stratégies principales sont devenues les normes de facto dans l'industrie. Le choix entre elles a des implications significatives sur les performances, la cohérence des données et l'expérience utilisateur.

Pagination Basée sur l'Offset : L'Approche Fondamentale

La pagination basée sur l'offset, souvent appelée "pagination par numéro de page", est fréquemment la première approche que les développeurs apprennent. Elle est conceptuellement simple et se retrouve dans de nombreuses applications web. Elle fonctionne en utilisant deux paramètres principaux :

• limit (ou page_size) : Le nombre maximum de résultats à renvoyer sur une seule page.
• offset (ou page) : Le nombre d'enregistrements à ignorer depuis le début de l'ensemble de données. Si un paramètre page est utilisé, l'offset est généralement calculé comme (page - 1) * limit.

Une requête typique ressemble à ceci : GET /api/products?limit=25&offset=50

Cela se traduirait par une requête SQL comme :SQL

SELECT * FROM products ORDER BY created_at DESC LIMIT 25 OFFSET 50;

Cette requête ignore les 50 premiers produits et récupère les 25 suivants (c'est-à-dire les produits 51 à 75).

Avantages :

• Simplicité : Cette méthode est simple à mettre en œuvre, comme le montrent de nombreux tutoriels comme "Node.js REST API: Offset Pagination Made Easy".
• Navigation sans État : Le client peut facilement sauter à n'importe quelle page de l'ensemble de données sans avoir besoin d'informations préalables, ce qui la rend idéale pour les interfaces utilisateur avec des liens de page numérotés.

Inconvénients et Limitations :

• Mauvaises Performances sur de Grands Ensembles de Données : Le principal inconvénient est la clause OFFSET de la base de données. Pour une requête avec un offset important (par exemple, OFFSET 1000000), la base de données doit toujours récupérer les 1 000 025 enregistrements du disque, compter les millions premiers pour les ignorer, et seulement ensuite renvoyer les 25 derniers. Cela peut devenir incroyablement lent à mesure que le numéro de page augmente.
• Incohérence des Données (Dérive de Page) : Si de nouveaux enregistrements sont écrits dans la base de données pendant qu'un utilisateur pagine, l'ensemble de données entier se décale. Un utilisateur naviguant de la page 2 à la page 3 pourrait voir un enregistrement répété de la fin de la page 2, ou manquer un enregistrement entièrement. C'est un problème important pour les applications en temps réel et un sujet courant dans les forums de développeurs comme Stack Overflow lors de la discussion sur la manière d'assurer la cohérence des données.

Pagination Basée sur Curseur (Keyset) : La Solution Évolutive

La pagination basée sur curseur, également connue sous le nom de keyset ou seek pagination, résout les problèmes de performance et de cohérence de la méthode offset. Au lieu d'un numéro de page, elle utilise un "curseur", qui est un pointeur stable et opaque vers un enregistrement spécifique dans l'ensemble de données.

Le déroulement est le suivant :

1. Le client effectue une requête initiale pour une page de données.
2. Le serveur renvoie la page de données, ainsi qu'un curseur qui pointe vers le dernier élément de cet ensemble.
3. Pour la page suivante, le client renvoie ce curseur au serveur.
4. Le serveur récupère ensuite les enregistrements qui viennent après ce curseur spécifique, "cherchant" efficacement ce point dans l'ensemble de données.

Le curseur est généralement une valeur encodée dérivée de la ou des colonnes utilisées pour le tri. Par exemple, si le tri est basé sur created_at (un horodatage), le curseur pourrait être l'horodatage du dernier enregistrement. Pour gérer les égalités, une deuxième colonne unique (comme l'id de l'enregistrement) est souvent incluse.

Une requête utilisant un curseur ressemble à ceci : GET /api/products?limit=25&after_cursor=eyJjcmVhdGVkX2F0IjoiMjAyNS0wNi0wN1QxODowMDowMC4wMDBaIiwiaWQiOjg0N30=

Cela se traduirait par une requête SQL beaucoup plus performante :SQL

SELECT * FROM products
WHERE (created_at, id) < ('2025-06-07T18:00:00.000Z', 847)
ORDER BY created_at DESC, id DESC
LIMIT 25;

Cette requête utilise un index sur (created_at, id) pour "chercher" instantanément le point de départ correct, évitant une analyse complète de la table et la rendant constamment rapide quelle que soit la profondeur de la pagination par l'utilisateur.

Avantages :

• Hautement Performante et Évolutive : Les performances de la base de données sont rapides et constantes, ce qui la rend adaptée aux ensembles de données de toute taille.
• Cohérence des Données : Étant donné que le curseur est lié à un enregistrement spécifique, et non à une position absolue, l'ajout ou la suppression de nouvelles données ne causera pas d'éléments manquants ou répétés entre les pages.

Inconvénients :

• Complexité de l'Implémentation : La logique de génération et d'analyse des curseurs est plus complexe qu'un simple calcul d'offset.
• Navigation Limitée : Le client ne peut naviguer qu'à la page "suivante" ou "précédente". Il n'est pas possible de sauter directement à un numéro de page spécifique, ce qui la rend moins adaptée à certains modèles d'interface utilisateur.
• Nécessite une Clé de Tri Stable : L'implémentation est étroitement liée à l'ordre de tri et nécessite au moins une colonne unique et séquentielle.

Comparaison des Deux Principaux Types de Pagination

Le choix entre la pagination par offset et par curseur dépend entièrement du cas d'utilisation.

Bonnes Pratiques d'Implémentation pour la Pagination Côté Serveur

Quelle que soit la stratégie choisie, le respect d'un ensemble de bonnes pratiques se traduira par une API propre, prévisible et facile à utiliser. C'est souvent un élément clé pour répondre à la question "Quelle est la meilleure pratique pour la pagination côté serveur ?".

Conception de la Charge Utile de Réponse de Pagination

Une erreur courante est de ne renvoyer qu'un tableau de résultats. Une charge utile de réponse de pagination bien conçue doit être un objet qui "enveloppe" les données et inclut des métadonnées de pagination claires.JSON

{
  "data": [
    { "id": 101, "name": "Product A" },
    { "id": 102, "name": "Product B" }
  ],
  "pagination": {
    "next_cursor": "eJjcmVhdGVkX2F0Ij...",
    "has_next_page": true
  }
}

Pour la pagination par offset, les métadonnées seraient différentes :JSON

{
  "data": [
    // ... résultats
  ],
  "metadata": {
    "total_results": 8452,
    "total_pages": 339,
    "current_page": 3,
    "per_page": 25
  }
}

Cette structure permet au client de savoir facilement s'il y a plus de données à récupérer ou s'il faut afficher des contrôles d'interface utilisateur.

Utilisation de Liens Hypermedia pour la Navigation (HATEOAS)

Un principe fondamental de REST est HATEOAS (Hypermedia as the Engine of Application State). Cela signifie que l'API doit fournir aux clients des liens pour naviguer vers d'autres ressources ou actions. Pour la pagination, c'est incroyablement puissant. Comme démontré dans la documentation GitHub, une manière standardisée de le faire est d'utiliser l'en-tête HTTP Link.

Link: <https://api.example.com/items?page=3>; rel="next", <https://api.example.com/items?page=1>; rel="prev"

Alternativement, ces liens peuvent être placés directement dans le corps de la réponse JSON, ce qui est souvent plus facile à consommer pour les clients JavaScript :JSON

"pagination": {
  "links": {
    "next": "https://api.example.com/items?limit=25&offset=75",
    "previous": "https://api.example.com/items?limit=25&offset=25"
  }
}

Cela dispense le client d'avoir à construire les URL manuellement.

Permettre aux Clients de Contrôler la Taille de la Page

Il est bon de permettre aux clients de demander des pages de résultats supplémentaires pour les réponses paginées et également de modifier le nombre de résultats renvoyés sur chaque page. Cela se fait généralement avec un paramètre de requête limit ou per_page. Cependant, le serveur doit toujours appliquer une limite maximale raisonnable (par exemple, 100) pour empêcher les clients de demander trop de données à la fois et de surcharger le système.

Combinaison de la Pagination avec le Filtrage et le Tri

Les API du monde réel ne font pas que paginer ; elles doivent également prendre en charge le filtrage et le tri. Comme le montrent les tutoriels couvrant des technologies comme .NET, l'ajout de ces fonctionnalités est une exigence courante.

Une requête complexe pourrait ressembler à : GET /api/products?status=published&sort=-created_at&limit=50&page=2

Lors de l'implémentation, il est crucial que les paramètres de filtrage et de tri soient considérés comme faisant partie de la logique de pagination. L'ordre de sort doit être stable et déterministe pour que la pagination fonctionne correctement. Si l'ordre de tri n'est pas unique, vous devez ajouter une colonne unique pour départager les égalités (comme l'id) afin d'assurer un ordre cohérent entre les pages.

Exemples d'Implémentation dans le Monde Réel

Explorons comment implémenter ces concepts dans divers frameworks populaires.

Pagination d'API REST en Python avec Django REST Framework

L'une des combinaisons les plus populaires pour construire des API est Python avec le Django REST Framework (DRF). DRF offre un support puissant et intégré pour la pagination, ce qui facilite incroyablement le démarrage. Il propose des classes pour différentes stratégies :

• PageNumberPagination : Pour la pagination standard basée sur le numéro de page (offset).
• LimitOffsetPagination : Pour une implémentation d'offset plus flexible.
• CursorPagination : Pour une pagination basée sur curseur haute performance.

Vous pouvez configurer un style de pagination par défaut globalement, puis simplement utiliser un ListAPIView générique, et DRF gère le reste. C'est un excellent exemple de pagination d'API REST en Python.Python

# Dans votre settings.py
REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.CursorPagination',
    'PAGE_SIZE': 50
}

# Dans votre views.py
class ProductListView(generics.ListAPIView):
    queryset = Product.objects.all()
    serializer_class = ProductSerializer
    # DRF gère automatiquement toute la logique de pagination !

Construction d'une API REST Paginée avec Node.js, Express et TypeScript

Dans l'écosystème Node.js, vous construisez souvent la logique de pagination manuellement, ce qui vous donne un contrôle total. Cette section du guide fournit un aperçu conceptuel de la construction de la pagination avec Node.js, Express et TypeScript.

Voici un exemple simplifié d'implémentation de la pagination par curseur :TypeScript

// Dans votre contrôleur Express
app.get('/products', async (req: Request, res: Response) => {
  const limit = parseInt(req.query.limit as string) || 25;
  const cursor = req.query.cursor as string;

  let query = db.selectFrom('products').orderBy('createdAt', 'desc').orderBy('id', 'desc').limit(limit);

  if (cursor) {
    const { createdAt, id } = JSON.parse(Buffer.from(cursor, 'base64').toString('ascii'));
    // Ajoute la clause WHERE pour le curseur
    query = query.where('createdAt', '<=', createdAt).where('id', '<', id);
  }

  const products = await query.execute();

  const nextCursor = products.length > 0
    ? Buffer.from(JSON.stringify({
        createdAt: products[products.length - 1].createdAt,
        id: products[products.length - 1].id
      })).toString('base64')
    : null;

  res.json({
    data: products,
    pagination: { next_cursor: nextCursor }
  });
});

Pagination dans un Écosystème Java ou .NET

Les frameworks dans d'autres écosystèmes offrent également un support robuste pour la pagination.

• Java (Spring Boot) : Le projet Spring Data rend la pagination triviale. En utilisant un PagingAndSortingRepository, vous pouvez définir une signature de méthode comme Page<Product> findAll(Pageable pageable);. Spring implémente automatiquement la méthode, gère les paramètres de requête page, size et sort, et renvoie un objet Page contenant les résultats et toutes les métadonnées de pagination nécessaires. C'est une réponse de bonne pratique à la question "Comment implémenter la pagination dans une API REST Java ?".
• .NET : Dans le monde .NET, les développeurs utilisent souvent des extensions IQueryable avec des méthodes comme .Skip() et .Take() pour implémenter la pagination par offset. Pour des scénarios plus avancés, des bibliothèques peuvent aider à construire des solutions basées sur curseur qui se traduisent par des requêtes SQL efficaces.

### Cas d'Utilisation Réel : Paginating a Product Catalog API

Considérez un site de commerce électronique avec une "API de Catalogue de Produits". C'est un cas d'utilisation réel parfait. Le catalogue est vaste et dynamique, avec de nouveaux produits ajoutés fréquemment.

• Problème : Si le site utilise la pagination par offset pour sa liste de produits, et qu'un nouveau produit est ajouté pendant qu'un client navigue de la page 1 à la page 2, le client pourrait voir le dernier produit de la page 1 répété en haut de la page 2. C'est une expérience utilisateur déroutante.
• Solution : L'implémentation de la pagination basée sur curseur est la solution idéale. Le bouton "Charger plus" sur le front-end passerait le curseur du dernier produit visible. L'API renverrait alors l'ensemble de produits suivant après celui-ci, garantissant que la liste s'allonge simplement sans doublons ni éléments manqués pour l'utilisateur.

Sujets Avancés et Problèmes Courants

Comme les développeurs sur Stack Overflow et Reddit le découvrent souvent, la construction d'un système de pagination véritablement robuste nécessite de gérer de nombreux détails et cas limites.

Comment Assurer la Cohérence des Données dans une API Paginée

C'est l'un des sujets avancés les plus critiques. Comme discuté, la seule manière fiable de garantir la cohérence des données dans un système avec des écritures fréquentes est d'utiliser la pagination keyset/curseur. Sa conception empêche intrinsèquement la dérive de page. Si pour une raison quelconque vous êtes bloqué avec la pagination par offset, il existe des solutions de contournement complexes, comme la création d'un instantané temporaire et immuable des ID pour l'ensemble de résultats complet et la pagination à travers cette liste, mais c'est très dépendant de l'état et généralement non recommandé pour les API REST.

Gestion des Cas Limites Étranges

Une API prête pour la production doit gérer les entrées incorrectes avec élégance. Considérez ces cas limites courants :

• Un client demande page=0 ou offset=-50. L'API ne doit pas renvoyer une erreur 500. Elle doit renvoyer un 400 Bad Request avec un message d'erreur clair.
• Un client fournit un curseur mal formé ou invalide. L'API doit à nouveau renvoyer un 400 Bad Request.
• Un client fournit un curseur valide, mais l'élément qu'il pointe a été supprimé. Une bonne stratégie consiste à considérer le curseur comme pointant vers "l'espace" où se trouvait cet élément et à renvoyer la page de résultats suivante à partir de ce point.

Implémentation Côté Client

Le côté client est l'endroit où la logique de pagination est consommée. L'utilisation de JavaScript pour récupérer des données paginées à partir d'une API REST comme un pro implique de lire les métadonnées de pagination et de les utiliser pour effectuer les requêtes suivantes.

Voici un exemple simple de fetch pour un bouton "Charger plus" utilisant la pagination par curseur :JavaScript

const loadMoreButton = document.getElementById('load-more');
let nextCursor = null; // Stocke le curseur globalement ou dans l'état du composant

async function fetchProducts(cursor) {
  const url = cursor ? `/api/products?cursor=${cursor}` : '/api/products';
  const response = await fetch(url);
  const data = await response.json();

  // ... affiche les nouveaux produits ...
  nextCursor = data.pagination.next_cursor;

  if (!nextCursor) {
    loadMoreButton.disabled = true; // Plus de pages
  }
}

loadMoreButton.addEventListener('click', () => fetchProducts(nextCursor));

// Chargement initial
fetchProducts(null);

L'Avenir de la Récupération de Données API et des Standards de Pagination

Bien que REST soit dominant depuis des années, le paysage évolue constamment.

Évolution des Standards de Pagination d'API REST

Il n'existe pas de RFC unique et formel qui définisse les standards de pagination d'API REST. Cependant, un ensemble de conventions fortes a émergé, impulsé par les API publiques de grandes entreprises technologiques comme GitHub, Stripe et Atlassian. Ces conventions, telles que l'utilisation de l'en-tête Link et la fourniture de métadonnées claires, sont devenues la norme de facto. La cohérence est essentielle ; une plateforme API bien conçue utilisera la même stratégie de pagination sur tous ses points de terminaison basés sur des listes.

L'Impact de GraphQL sur la Pagination

GraphQL présente un paradigme différent. Au lieu de multiples points de terminaison, il dispose d'un point de terminaison unique où les clients envoient des requêtes complexes spécifiant les données exactes dont ils ont besoin. Cependant, la nécessité de paginer de grandes listes de données ne disparaît pas. La communauté GraphQL a également standardisé la pagination basée sur curseur via une spécification formelle appelée Relay Cursor Connections Spec. Celle-ci définit une structure précise pour la pagination des données, utilisant des concepts comme first, after, last et before pour fournir une pagination robuste vers l'avant et vers l'arrière.

Conclusion : Résumé des Bonnes Pratiques de Pagination

Maîtriser la pagination d'API REST est une compétence essentielle pour tout développeur back-end. C'est une technique indispensable pour construire des applications évolutives, performantes et conviviales.

Pour résumer les bonnes pratiques de pagination d'API REST :

1. Toujours Paginer : Ne jamais renvoyer une liste illimitée de résultats depuis un point de terminaison API.
2. Choisir la Bonne Stratégie : Utiliser la pagination simple par offset pour les petits ensembles de données, non critiques ou statiques. Pour tout ce qui est grand, dynamique ou orienté utilisateur, préférer fortement la pagination basée sur curseur pour ses performances supérieures et sa cohérence des données.
3. Fournir des Métadonnées Claires : Votre charge utile de réponse doit toujours inclure des informations qui indiquent au client comment obtenir la page de données suivante, qu'il s'agisse d'un next_cursor ou de numéros de page et de liens.
4. Utiliser l'Hypermedia : Utiliser l'en-tête Link ou des liens dans le corps de votre JSON pour rendre votre API plus découvrable et plus facile à utiliser.
5. Gérer les Erreurs avec Élégance : Valider tous les paramètres de pagination et renvoyer des erreurs 400 Bad Request claires pour les entrées invalides.

En suivant ce guide et en intériorisant ces principes, vous pouvez concevoir et construire des API REST professionnelles, prêtes pour la production, capables de s'adapter efficacement à toute demande.

FAQ sur la Pagination d'API REST

1. Quelle est la principale différence entre la pagination par offset et par curseur ?

La principale différence réside dans la manière dont elles déterminent l'ensemble de données à récupérer. La pagination par offset utilise un offset numérique (comme "sauter les 50 premiers éléments") pour trouver la page suivante. Cela peut être lent pour de grands ensembles de données car la base de données doit toujours compter les éléments ignorés. La pagination par curseur utilise un pointeur stable ou "curseur" qui pointe vers un enregistrement spécifique (comme "obtenir les éléments après l'ID produit 857"). C'est beaucoup plus efficace car la base de données peut utiliser un index pour sauter directement à cet enregistrement.

2. Quand est-il approprié d'utiliser la pagination par offset au lieu de la pagination par curseur ?

La pagination par offset est appropriée pour les ensembles de données petits, non critiques en termes de performance, ou qui ne changent pas souvent. Son principal avantage est la simplicité et la capacité pour un utilisateur de sauter à n'importe quel numéro de page spécifique (par exemple, "Aller à la Page 10"). Cela la rend adaptée aux tableaux de bord d'administration ou aux outils internes où l'expérience utilisateur de sauter entre les pages est plus importante que la gestion des changements de données en temps réel.

3. Comment la pagination basée sur curseur empêche-t-elle le problème de sauter ou de répéter des éléments ?

La pagination basée sur curseur empêche l'incohérence des données car elle ancre la requête suivante à un élément spécifique, et non à une position numérique. Par exemple, si vous demandez la page après l'élément avec ID=100, peu importe si de nouveaux éléments sont ajoutés avant lui ; la requête commencera toujours à récupérer à partir du bon endroit. Avec la pagination par offset, si un nouvel élément est ajouté à la page 1 pendant que vous la visualisez, lorsque vous demandez la page 2, le dernier élément de la page 1 sera maintenant le premier élément de la page 2, provoquant une répétition.

4. Existe-t-il une norme officielle pour les réponses de pagination d'API REST ?

Il n'existe pas de RFC unique, officielle ou de norme formelle qui dicte la manière dont toute la pagination d'API REST doit être implémentée. Cependant, des conventions fortes et de bonnes pratiques ont émergé de l'industrie, largement établies par de grandes API publiques comme celles de GitHub et Stripe. Ces conventions incluent l'utilisation d'un en-tête HTTP Link avec les attributs rel="next" et rel="prev", ou l'intégration d'un objet pagination avec des métadonnées claires et des liens directement dans le corps de la réponse JSON.

5. Comment dois-je gérer le tri et le filtrage avec mes points de terminaison paginés ?

Le tri et le filtrage doivent être appliqués avant la pagination. Les résultats paginés doivent être une "vue" de l'ensemble de données déjà trié et filtré. Il est crucial que l'ordre de tri soit stable et déterministe. Si un utilisateur trie par un champ non unique (comme une date), vous devez ajouter une clé de tri secondaire unique (comme l'id d'un enregistrement) pour servir de départage. Cela garantit que l'ordre des éléments est toujours le même, ce qui est essentiel pour que la pagination par offset et par curseur fonctionne correctement.