Actuellement, Zendesk propose une pagination basée sur les décalages pour la quasi-totalité de ses points de terminaison API REST actuels. Même si cela convient à la plupart des utilisations à petite échelle (par ex. les demandes qui ne vont pas au-delà de 10 pages de données), cela met une pression exponentielle sur l'infrastructure quand il est utilisé à grande échelle avec des décalages de pages élevés. Ces demandes de décalage élevé entraînent des temps de réponse élevés et de mauvaises performances car pour chaque nouvelle page demandée, le travail d'assemblement de toutes les pages précédentes doit être commencé en premier.
Afin de fournir une meilleure expérience aux développeurs et des performances plus rapides pour nos clients, nous allons bientôt passer à une pagination principalement basée sur le curseur et implémenter des limites pour les demandes de décalage de page très élevées.
- Qu'est-ce que la pagination basée sur le curseur ?
- Comment et pourquoi effectuons-nous ces modifications ?
- Limites de la pagination par décalage
- Comment puis-je commencer à mettre en œuvre ces modifications ?
- Quels sont les points finaux pris en charge ?
Qu'est-ce que la pagination basée sur le curseur ?
La pagination par curseur utilise un pointeur vers un élément spécifique dans un jeu de données pour marquer votre progression. Il s'agit d'une sorte de marque-page vous permettant de demander le prochain lot d'éléments du jeu de données en plaçant le curseur sur les demandes suivantes. Au lieu de demander à la page suivante de parcourir les éléments, vous fournissez le curseur de la réponse précédente. Cela présente l'avantage d'offrir des résultats plus rapides pour des volumes élevés.
Comment et pourquoi effectuons-nous ces modifications ?
Prochainement, les modifications des Zendesk seront mises en place afin d'améliorer l'utilisation de l'API à grande échelle. Il s'agit notamment de mettre la pagination à base de curseur à la disposition du plus grand nombre, en commençant par notre Utilisateurs, Tickets et Marqueurs, avant d'ajouter la majorité de nos points de terminaison en 2021.
La pagination basée sur l'offset continuera d'être proposée avec une portée et une profondeur considérablement limitées. Cela inclut notamment de limiter les demandes d'appels offset très longs (demandes de plus de 1 000 pages), ce qui aura divers effets (des plus positifs) pour les gros consommateurs de nos API.
Les avantages de la pagination basée sur le curseur incluent :
- Les demandes ne seront plus affectées par les délais d'expiration extrêmement longs rencontrés lors des demandes avec un nombre de pages très élevé. Cela se traduira par des performances plus rapides pour presque toutes les intégrations qui nécessitent de parcourir des ensembles entiers de ressources page par page.
- Les demandes qui utilisent la pagination basée sur le curseur ne représenteront plus le risque pour l'infrastructure associé à une pagination basée sur le décalage de page élevé, allant des pannes de service aux incidents dus à une pression sur l'infrastructure.
- Pour les intégrations qui utilisent la pagination basée sur le décalage pour exporter un jeu complet de ressources, le passage à la pagination basée sur le curseur sera relativement facile et ne nécessitera que peu de retouches pour préparer les intégrations au changement. Au lieu d'utiliser un next_page , l'intégration peut utiliser le paramètre decurseur pour créer une nouvelle page.
Consultez cette page pour une comparaison plus détaillée.
Limites de la pagination par décalage
Zendesk souhaite que tout le trafic pouvant utiliser la pagination basée sur le curseur abandonne la pagination basée sur les décalages.
Pour encourager cette évolution, à partir du 15 septembre 2021, Zendesk mettra en œuvre des limites de débit pour les demandes de plus de 1 000 pages (100000 pages ressources). Pour toutes les demandes de plus de 1 000 pages, l'accès sera limité à 10 demandes par minute.
Cela ralentira (mais n'arrêtera pas) les demandes qui sollicitent notre infrastructure de façon disproportionnée. Si une demande de plus de 1 000 pages est envoyée à une vitesse supérieure à 10 fois par minute, le système renvoie 429 réponses et vous devrez réitérer la demande ultérieurement. Le message d'erreur indiquera également le temps restant avant que les utilisateurs puissent envoyer leur prochaine demande et poursuivre leur recherche.
Les demandes effectuées avec la pagination basée sur le curseur n'auront pas de limite similaire et seront plus rapides que les demandes de décalage de page élevé.
Comment puis-je commencer à mettre en œuvre ces modifications ?
Nous vous conseillons d'envisager de passer à la pagination basée sur le curseur. dès que possible. Consultez Pagination des listes en utilisant la pagination par curseur. Quand vous aurez pris connaissance des modifications et en avoir discuté en interne, nous vous demandons de passer en revue quelques-uns :
- Veiller à ce que les intégrations qui continueront à utiliser la pagination par décalages le fassent dans les limitesde nos capacités.
- Passez en revue toutes les parties de vos intégrations qui utilisent l'API spécifiquement pour regrouper toutes les données disponibles ou simplement pour créer des rapports sur les modifications. Ce sont généralement des candidats idéaux pour l'entrepôt de données.
- Si vous utilisez le point de terminaison pour extraire toutes les données disponibles, commencez à travailler sur le passage à la pagination basée sur le curseur.
- Si vous utilisez l'API pour créer des rapports sur les modifications quotidiennes, commencez à utiliser nos API incrémentales., ce qui permettrait un volume important de toutes les données pertinentes pour ce cas d'utilisation. L'utilisation de la pagination basée sur le curseur pour votre exportation initiale, puis le passage à l'API incrémentale pour capturer les modifications, réduiront considérablement le nombre d'appels nécessaires pour recueillir les données pertinentes.
- Si vous envoyez actuellement des demandes à plusieurs pages en parallèle, envisagez l'option incrémentale ci-dessus, car la pagination parallélisée n'est pas prise en charge et elle est très exigeante pour notre infrastructure.
Quels sont les points finaux pris en charge ?
Pour une liste des points finaux qui prennent en charge la pagination avec décalage de curseur, consultez Points de terminaison avec la capacité CBP dans l'annonce des limites de la pagination en fonction des décalages.
Si, après lecture, vous avez d'autres questions ou inquiétudes, nous nous ferons un plaisir d'en discuter avec vous et vos équipes d'ingénierie et d'intégrations.
Nous vous remercions d'avoir pris le temps de revenir sur ces points. Nous espérons travailler bientôt avec vous pour développer des outils meilleurs, plus rapides et plus évolutifs, afin de mieux servir vos clients.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.