Bonnes pratiques d'intégration Box

Préservez la couverture des résultats et les permissions lors de la réduction des appels. Pour les travaux en masse ou les erreurs 429, estimez les appels par élément complété et le taux de requête maximal par acteur Box et endpoint. Budgétisez les uploads et les recherches par rapport à leurs limites séparées. Vérifiez les limites de débit actuelles ; des limites utilisateur, endpoint, entreprise et de qualité de service temporaire peuvent s'appliquer.

Réduire les appels

Pour les révisions, tracez les requêtes Box à travers les boucles et les chemins de retry avant de modifier la concurrence ou de demander plus de capacité.

• Réutilisez les tokens d'accès en cache. Demandez les champs nécessaires à une décision dans la réponse de liste quand c'est supporté, et réutilisez les données retournées au lieu de récupérer chaque élément à nouveau. fields réduit le nombre d'appels uniquement quand il remplace une lecture de suivi.
• Utilisez la plus grande taille de page utile supportée. Pour les collections volumineuses ou changeantes, utilisez la pagination par marqueur quand c'est supporté ; suivez next_marker jusqu'au bout et ne traitez pas un marqueur comme un point de contrôle durable.
• Utilisez les webhooks ou les événements avec un chemin de rattrapage au lieu de scans complets répétés. Dédupliquez les livraisons ; vérifiez les positions du flux d'événements après un traitement réussi. Interrogez les templates de métadonnées d'entreprise supportés au lieu de récupérer les métadonnées pour chaque fichier.
• Quand le contenu reste dans Box, préférez les opérations de copie, déplacement ou mise à jour côté Box au téléchargement et réupload.

Contrôler les travaux en masse et les retries

• Limitez la concurrence entre les workers partageant un acteur Box, en tenant compte des limites endpoint et entreprise. Sur 429, respectez Retry-After sur tous les workers affectés. Les SDK officiels actuels font des retries sur 429 ; vérifiez la version installée avant d'ajouter une autre couche de retry. Pour HTTP direct, utilisez un backoff borné avec jitter.
• Pour les travaux longue durée, persistez les résultats par élément pour que le travail puisse reprendre. Réconciliez les écritures incertaines avant de les retenter.
• Rafraîchissez les tokens expirés sur 401 ; mettez en pause si les défaillances persistent. Pour 403, enregistrez les refus spécifiques à l'élément et mettez en pause quand les défaillances indiquent que l'accès de l'acteur ou de l'app est incorrect.
• Si le trafic nécessaire dépasse toujours la capacité disponible après suppression des appels évitables, signalez le besoin de capacité. Ne faites pas de rotation d'identités pour contourner les limites.

Vérifier le résultat

Enregistrez les appels Box et les 429 par acteur, endpoint et statut ; comparez les appels par élément complété et le débit du travail complété sur une charge de travail représentative. Utilisez le rapport Platform Activity pour les totaux historiques par app. Si un token atteint un navigateur ou un autre composant côté client, réduisez-le.