Meilleures pratiques en matière d'API

Les recommandations de meilleures pratiques sont basées sur l'expérience des clients IBM , des représentants de service et des testeurs d'assurance qualité. Ces meilleures pratiques ont pour but de fournir des conseils généraux sur les sujets de préoccupation qui se sont posés lors de l'utilisation du logiciel.

Pour effectuer des appels API, vous devez utiliser un jeton d'accès valide. Un jeton est généralement valide pendant 12 heures. Générer le jeton une fois et le réutiliser en le mettant en cache. Par exemple, vous pouvez stocker le jeton en mémoire du côté du client et le réutiliser pour tous les appels ultérieurs effectués à partir du même client. Pour plus d'informations sur la génération d'un jeton, voir Accès aux API et authentification.
Si une API est appelée avec un jeton manquant ou non valide, une erreur d'authentification est reçue dans la réponse. Comme pratique recommandée pour gérer les erreurs d'authentification, émettez une nouvelle demande de génération de jeton pour actualiser le cache de jeton. Ensuite, réessayez en appelant l'API Sterling Intelligent Promising avec le nouveau jeton.
Implémentez une méthode pour régénérer automatiquement un jeton avant le délai d'expiration (par exemple, toutes les 11 heures) ou lorsque vous rencontrez une réponse 401 Non autorisé.
Veillez à ce que la taille maximale de la charge utile par demande ne dépasse pas 500 Ko. Cette limite est fixée pour maintenir la stabilité et éviter les défaillances.
Pour des performances optimales, limitez chaque appel API à 100 combinaisons élément-nœud ou élément-réseau. Ensuite, séparez toutes les combinaisons supplémentaires en plusieurs appels API.
Passer les en-têtes HTTP qui ne sont mentionnés que dans la documentation de l'API. Pour plus d'informations, voir la documentation de l'API.

API de disponibilité

Pour les détails d'un produit ou les pages de liste d'un site web, utilisez l' API "Get Node Availability Product by Date" (/availability/{itemId}/node) ou " Get Network Availability Product by Date" (/availability/{itemId}/network) pour l'article en question.
Pour les paniers ou les commandes, utilisez l' API "Get Node Availability" (/availability/node) ou " Get Network Availability API" (/availability/network) avec les articles du panier ou de la commande.
Pour le retrait du panier, utilisez l' API Réservations (/reservations) afin d'éviter les ventes excessives.
Pour les API de disponibilité V2, utilisez le format de date pour requestedEndTs. Par exemple, "2020-03-02Z".
Si un horodatage est utilisé à la place d'une date, par exemple 2020-03-02T15:43:18.279Z avec une composante temporelle, l'API émet une exception de mauvaise requête.
Note : La validation du format de date pour requestedEndTs est applicable à partir de la fin de la version de juillet.

API de groupe de distribution

L'API Update Distribution Group ne prend en charge que la méthode PUT. Comme la demande PUT est idempotent, la mise à jour d'un groupe de distribution existant remplace l'intégralité du groupe.
- Si vous ajoutez de nouveaux noeuds d'expédition à un groupe de distribution existant, assurez-vous que le contenu inclut également des noeuds d'expédition existants.
- Si vous supprimez des noeuds d'expédition d'un groupe de distribution existant, assurez-vous que le contenu inclut uniquement les noeuds d'expédition que vous souhaitez conserver dans le groupe.
L'API synchronise automatiquement la disponibilité du groupe de distribution lorsque des noeuds d'expédition sont ajoutés ou supprimés du groupe.
Ne déclenchez pas de synchronisations ultérieures pour le même groupe de distribution tant que les synchronisations précédentes ne sont pas terminées. La synchronisation du groupe de distribution n'est pas un processus instantané. En outre, il est recommandé de soumettre moins de demandes. Par exemple, si vous supprimez trois noeuds du groupe de distribution, soumettez une demande avec les trois noeuds supprimés.
Vous pouvez extraire le statut de synchronisation avec l'API GET Job. Lorsque l'API Distribution Group est appelée, une référence à une URL pour l'API GET Job est présentée dans la sortie de l'API. Exemple :
```
{
    "job": {
        "href": "http://api.watsoncommerce.ibm.com/inventory/us-abcdabcd/v1/jobs/a2f173e7-2023-4e3d-b21d-2b6801f61d1b"
    }
}
```
Vous pouvez appeler l'API GET Job avec cette URL pour obtenir l'état du travail fourni, comme le montre l'exemple suivant.
```
{
    "id": "a2f173e7-2023-4e3d-b21d-2b6801f61d1b",
    "status": "completed",
    "triggeredTs": "2021-02-22T19:59:12.585Z",
    "startedTs": "2021-02-22T19:59:12.849Z",
    "completedTs": "2021-02-22T19:59:13.155Z",
    "data": {
        "distributionGroupId": "USEast",
        "diffNodes": [
            "USEast-Node1",
            "USEast-Node2"
        ],
        "sourceTs": "2021-02-22T19:59:12.565Z"
    }
}
```
Passez en revue la zone status de la sortie.

terminé

Le travail a abouti. Dans ce cas, vous pouvez soumettre la demande suivante.

démarré

Le travail est en cours. Dans ce cas, ne déclenchez pas une autre synchronisation pour le même groupe de distribution. Toutefois, vous pouvez déclencher une synchronisation pour un groupe de distribution différent.

Déclenché

Le travail n'a pas encore démarré. Dans ce cas, ne déclenchez pas une autre synchronisation pour le même groupe de distribution. Toutefois, vous pouvez déclencher une synchronisation pour un groupe de distribution différent.

Si l'API renvoie le code de statut 404, vous pouvez soumettre à nouveau la demande en toute sécurité.