Résultats de la page utilisant OData
Utilisez l’en-tête de requête Prefer: odata.maxpagesize pour contrôler le nombre d’enregistrements renvoyés. Si vous ne spécifiez pas de nombre, jusqu’à 5 000 enregistrements peuvent être renvoyés pour chaque demande. Vous ne pouvez pas demander une taille de page supérieure à 5 000.
Notes
Dataverse ne prend pas en charge l’option de requête $skip ; par conséquent, vous ne pouvez pas utiliser la combinaison de $top et $skip pour la pagination. Découvrez comment utiliser l’option de requête $top pour limiter le nombre de lignes
L’exemple suivant renvoie uniquement les deux premiers enregistrements de contact :
Demande :
GET [Organization URI]/api/data/v9.2/contacts?$select=fullname
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.maxpagesize=2
Réponse :
HTTP/1.1 200 OK
OData-Version: 4.0
Preference-Applied: odata.maxpagesize=2
{
"@odata.context": "[Organization URI]/api/data/v9.2/$metadata#contacts(fullname)",
"value": [
{
"@odata.etag": "W/\"72201545\"",
"fullname": "Yvonne McKay (sample)",
"contactid": "49b0be2e-d01c-ed11-b83e-000d3a572421"
},
{
"@odata.etag": "W/\"80648695\"",
"fullname": "Susanna Stubberod (sample)",
"contactid": "70bf4d48-34cb-ed11-b596-0022481d68cd"
}
],
"@odata.nextLink": "[Organization URI]/api/data/v9.2/contacts?$select=fullname&$skiptoken=%3Ccookie%20pagenumber=%222%22%20pagingcookie=%22%253ccookie%2520page%253d%25221%2522%253e%253ccontactid%2520last%253d%2522%257bD5026A4D-D01C-ED11-B83E-000D3A572421%257d%2522%2520first%253d%2522%257b49B0BE2E-D01C-ED11-B83E-000D3A572421%257d%2522%2520%252f%253e%253c%252fcookie%253e%22%20istracking=%22False%22%20/%3E"
}
Lorsqu’il y a plus d’enregistrements que ceux demandés, l’annotation @odata.nextLink fournit une URL que vous pouvez utiliser avec GET pour renvoyer la page suivante de données, comme le montre l’exemple suivant :
Demande :
GET [Organization URI]/api/data/v9.2/contacts?$select=fullname&$skiptoken=%3Ccookie%20pagenumber=%222%22%20pagingcookie=%22%253ccookie%2520page%253d%25221%2522%253e%253ccontactid%2520last%253d%2522%257bD5026A4D-D01C-ED11-B83E-000D3A572421%257d%2522%2520first%253d%2522%257b49B0BE2E-D01C-ED11-B83E-000D3A572421%257d%2522%2520%252f%253e%253c%252fcookie%253e%22%20istracking=%22False%22%20/%3E
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0
Prefer: odata.maxpagesize=2
Réponse :
HTTP/1.1 200 OK
OData-Version: 4.0
Preference-Applied: odata.maxpagesize=2
{
"@odata.context": "[Organization URI]/api/data/v9.2/$metadata#contacts(fullname)",
"value": [
{
"@odata.etag": "W/\"80648710\"",
"fullname": "Nancy Anderson (sample)",
"contactid": "72bf4d48-34cb-ed11-b596-0022481d68cd"
},
{
"@odata.etag": "W/\"80648724\"",
"fullname": "Maria Campbell (sample)",
"contactid": "74bf4d48-34cb-ed11-b596-0022481d68cd"
}
],
"@odata.nextLink": "[Organization URI]/api/data/v9.2/contacts?$select=fullname&$skiptoken=%3Ccookie%20pagenumber=%223%22%20pagingcookie=%22%253ccookie%2520page%253d%25222%2522%253e%253ccontactid%2520last%253d%2522%257bF2318099-171F-ED11-B83E-000D3A572421%257d%2522%2520first%253d%2522%257bBB55F942-161F-ED11-B83E-000D3A572421%257d%2522%2520%252f%253e%253c%252fcookie%253e%22%20istracking=%22False%22%20/%3E"
}
Vous devez mettre en cache les résultats renvoyés ou la valeur de l’URL @odata.nextLink et l’utiliser pour revenir aux pages précédentes.
Ne modifiez pas la valeur de l’URL @odata.nextLink ou n’y ajoutez pas des options de requête. Pour chaque demande ultérieure de pages supplémentaires, vous devez utiliser la même valeur de préférence odata.maxpagesize que celle utilisée dans la demande initiale. Vous pouvez continuer à parcourir les données jusqu’à ce qu’il n’y ait plus d’annotation @odata.nextLink dans les résultats.
Dans les exemples précédents, les informations codées étaient définies comme la valeur du paramètre $skiptoken dans la valeur de l’URL @odata.nextLink. Le serveur définit cette information codée pour contrôler la pagination. Vous ne devez pas modifier les informations codées ou les encoder davantage. Utilisez la valeur URL fournie pour récupérer la page suivante.
N’utilisez pas l’option de requête $top lors de la pagination des enregistrements
Utilisez l’option de requête $top pour limiter le nombre de résultats renvoyés. N’utilisez pas $top avec l’en-tête de demande Prefer: odata.maxpagesize. Si vous incluez les deux, $top est ignoré.
L’exemple suivant renvoie seulement les trois premières lignes de compte :
GET [Organization URI]/api/data/v9.2/accounts?$select=name,revenue&$top=3
Tri et pagination
La façon dont une page est triée fait une grande différence lors de la pagination des données. Si les informations de tri des résultats sont ambiguës, Dataverse ne peut pas renvoyer de manière cohérente ou efficace les données paginées.
Spécifiez un ordre pour votre requête. Avec FetchXml, si vous n’ajoutez aucun élément de commande à votre requête, Dataverse ajoute une commande basée sur la clé primaire de la table. Cependant QueryExpression ne le fait pas, et lorsque votre requête spécifie distinct des résultats, aucune valeur de clé primaire n’est renvoyée, donc Dataverse peut pas ajouter cet ordre par défaut. Vous devez spécifier un ordre de pagination. Sans aucun ordre spécifié, les résultats de la requête distinct peuvent être renvoyés dans un ordre aléatoire. OData ne propose aucune option pour renvoyer des résultats distincts, mais vous devez toujours appliquer un ordre lors de la récupération des résultats paginés.
La pagination est dynamique. Chaque requête est évaluée de manière indépendante au fur et à mesure qu’elle est reçue. Un cookie de pagination indique à Dataverse la page précédente. Avec ces données de cookie de pagination, Dataverse peut commencer par l’enregistrement suivant après le dernier de la page précédente.
La pagination fonctionnera mieux à l’avenir. Si vous revenez en arrière et récupérez une page que vous avez précédemment récupérée, les résultats peuvent être différents car des enregistrements peuvent être ajoutés, supprimés ou modifiés depuis la dernière récupération de la page. En d’autres termes, si la taille de votre page est de 50 et que vous revenez en arrière, vous obtenez 50 enregistrements, mais ce ne sont peut-être pas les mêmes 50 enregistrements. Si vous continuez à avancer dans les pages d’un jeu de données, vous pouvez vous attendre à ce que tous les enregistrements soient renvoyés dans un ordre cohérent.
Le tri déterministe est important
Le tri déterministe signifie qu’il existe un moyen de calculer un ordre de manière cohérente. Avec un ensemble d’enregistrements donné, les enregistrements sont toujours renvoyés dans le même ordre. Si vous avez besoin d’ordres et de pagination cohérents, vous devez inclure des valeurs uniques ou une combinaison de valeurs de colonne et spécifier un ordre pour qu’elles soient évaluées.
Exemple non déterministe
Examinons un exemple qui est non déterministe. Ce jeu de données contient uniquement des informations sur l’État et le Statut et est filtré pour renvoyer uniquement les enregistrements dans un État ouvert. Les résultats sont classés par Statut. Les trois premières pages sont demandées. Les résultats ressemblent à ce qui suit :
| État | Statut | Page |
|---|---|---|
| Ouvert | Actif | 1. Début |
| Ouvert | Actif | 1 |
| Ouvert | Actif | 1 Fin |
| Ouvert | Actif | |
| Ouvert | Actif | |
| Ouvert | Inactif | |
| Ouvert | Inactif |
Le cookie de pagination enregistre les informations sur le dernier enregistrement de la page. Lorsque la page suivante est demandée, le dernier enregistrement de la première page n’est pas inclus. Cependant, compte tenu des données non déterministes, rien ne garantit que les deux autres enregistrements de la première page ne soient pas inclus dans la deuxième page.
Pour obtenir un tri déterministe, ajoutez des ordres aux colonnes contenant des valeurs uniques ou des valeurs semi-uniques.
Exemple déterministe
Cette requête est similaire à la requête non déterministe, mais elle inclut la colonne ID de cas qui inclut des valeurs uniques. Il est également trié par Statut, mais également par ID de cas. Les résultats ressemblent à ce qui suit :
| État | Statut | ID d’incident | Page |
|---|---|---|---|
| Ouvert | Actif | Incident-0010 | 1. Début |
| Ouvert | Actif | Incident-0021 | 1 |
| Ouvert | Actif | Incident-0032 | 1 Fin |
| Ouvert | Actif | Incident-0034 | |
| Ouvert | Actif | Incident-0070 | |
| Ouvert | Inactif | Incident-0015 | |
| Ouvert | Inactif | Incident-0047 |
Dans la page suivante, le cookie aura Case-0032 stocké comme dernier enregistrement de la première page ; par conséquent, la page deux commencera avec l’enregistrement suivant après cet enregistrement. Les résultats ressemblent à ce qui suit :
| État | Statut | ID d’incident | Page |
|---|---|---|---|
| Ouvert | Actif | Incident-0010 | 1. Début |
| Ouvert | Actif | Incident-0021 | 1 |
| Ouvert | Actif | Incident-0032 | 1 Fin |
| Ouvert | Actif | Incident-0034 | 2. Début |
| Ouvert | Actif | Incident-0070 | 2 |
| Ouvert | Inactif | Incident-0015 | 2 Fin |
| Ouvert | Inactif | Incident-0047 |
Étant donné que cette requête tri les valeurs de colonne uniques, l’ordre est cohérent.
Pratiques recommandées pour les tris lors de la pagination des données
Notes
Lorsque cela est possible, les requêtes doivent être triées en fonction de la clé primaire de la table, car Dataverse est optimisé par défaut pour le tri sur la clé primaire. Le tri en fonction de champs non uniques ou complexes entraîne une surcharge excessive et des requêtes plus lentes.
Lorsque vous récupérez un ensemble limité de données à afficher dans une application, ou si vous devez renvoyer plus de 5 000 lignes de données, vous devez paginer les résultats. Les choix effectués pour déterminer l’ordre des résultats peuvent déterminer si les lignes de chaque page de données que vous récupérez chevauchent d’autres pages. Sans un tri approprié, le même enregistrement peut apparaître sur plusieurs pages.
Pour éviter que le même enregistrement apparaisse sur plusieurs pages, appliquez les pratiques recommandées suivantes :
Il est préférable d’inclure une colonne possédant un identificateur unique. Par exemple :
- Colonnes de clé primaire de la table
- Colonnes de numérotation automatique
- ID utilisateur/contact
Si vous ne pouvez pas inclure une colonne avec un identificateur unique, incluez plusieurs champs qui généreront très probablement des combinaisons uniques. Par exemple :
- Prénom + nom + adresse e-mail
- Nom complet + adresse e-mail
- Adresse e-mail + nom de l’entreprise
Anti-modèles pour les tris lors de la pagination des données
Les choix de tri suivants doivent être évités :
Les tris qui n’incluent pas d’identificateurs uniques
Les tris sur des champs calculés
Tris avec un ou plusieurs champs qui ne fournissent probablement pas un caractère unique, tels que :
- Statut et état
- Choix ou Oui/Non
- Nommez les valeurs par elles-mêmes. Par exemple
name,firstname,lastname - Champs de texte comme les titres, les descriptions et le texte sur plusieurs lignes
- Champs de nombres non uniques
Étapes suivantes
Découvrez comment agréger des données.
Notes
Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)
Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).