Best Practice pour la mise à disposition des données produit par serveur API

La mise à disposition de données de produits via des services REST fait aujourd'hui partie des exigences centrales des systèmes PIM modernes. Pour que de telles interfaces restent viables à long terme et puissent être étendues sans grands efforts de développement, il est nécessaire de concevoir une API qui soit flexible, efficace et proprement structurée.

Un principe central à cet égard est la structuration dynamique des données de produits : Étant donné que les exigences relatives aux produits, aux attributs, aux descriptions ou aux contenus marketing évoluent en permanence, l'API ne doit pas dépendre d'instructions fixes stockées dans le code. Au lieu de cela, la structure doit être conçue de manière à ce que de nouvelles caractéristiques, de nouvelles catégories de texte ou de nouvelles relations du produit puissent être intégrées dans la sortie de l'API uniquement par configuration ou par modification du stock de données. De cette manière, les services REST restent stables alors que les modèles de données sous-jacents se développent ou évoluent.
Les méthodes suivantes sont directement issues de la pratique et ont déjà permis de mettre en place des solutions aussi flexibles que performantes dans de nombreux projets clients.

Sélection adaptée au marché

Dans de nombreuses entreprises, les produits sont utilisés sur différents marchés cibles. Les conditions juridiques régionales, les différentes stratégies d'assortiment ou les différents modèles de prix et de disponibilité peuvent jouer un rôle.

Une API produit moderne doit donc permettre de limiter les données de produits en fonction du marché cible, de sorte que les systèmes ne récupèrent que les données dont ils ont réellement besoin.

Il en va de même pour le filtrage linguistique. Étant donné que les données de produits sont souvent disponibles en plusieurs langues, l'API doit permettre de récupérer de manière ciblée certaines versions linguistiques. Cela permet non seulement d'améliorer l'efficacité technique, mais aussi d'éviter les transferts de données inutiles et les coûts de stockage du côté du client.

Une API crossbase typique filtre à la fois en fonction du marché et de la langue. Les corrélations sont créées dans le "Channel Output Management", et chaque canal de sortie reçoit ainsi le paquet d'informations approprié : les gammes de catalogue contrôlent le volume des articles, les combinaisons langue-pays le contenu. Le site web de notre client Lamello en est un bon exemple : https://lamello.com/fr/

Ne transmettre que ce qui est nécessaire

Pour la synchronisation des systèmes, il est en outre décisif de ne pas devoir livrer à nouveau toutes les données de produits à chaque appel. Une restriction liée au temps, par exemple via un horodatage "Last Modified", permet de ne mettre à disposition que les produits qui ont été modifiés depuis le dernier appel. Cela permet non seulement de réduire le volume des données, mais aussi d'améliorer les performances du traitement, notamment en cas de stocks importants de produits et d'appels réguliers.
Déterminer un tel "delta" n'a de sens que pour des quantités de données très importantes. Nous le recommandons à nos clients qui mettent à disposition plusieurs milliers de produits avec de nombreuses variantes par API pour des systèmes de boutiques et des configurateurs.

Contrôle individuel

Pour obtenir une flexibilité particulièrement élevée, il est recommandé d'utiliser des paramètres génériques pour les fonctions d'interrogation et de commande telles que la radiomessagerie, les filtres et le tri. En mettant à disposition de telles fonctions de manière générale et non pas individuellement pour chaque nouvelle exigence dans l'API, l'interface peut couvrir un large éventail de scénarios d'évaluation et de sortie de données sans perdre en clarté ni devoir être continuellement étendue.
Une bonne coordination avec les développeurs web du système cible, par exemple du CMS, est ici nécessaire. Les fonctions de recherche d'un site web, en particulier, profitent des requêtes paramétrées de l'API.

Séparer les données de produits de la hiérarchie

Un autre aspect important est la séparation entre les données de produits et les structures de produits.
Par structures produits, on entend dans ce contexte une hiérarchisation telle qu'elle est par exemple nécessaire pour la navigation d'un site web. De telles structures reproduisent des catégories, des sous-catégories et des chemins de navigation et ne représentent donc pas les caractéristiques d'un produit individuel, mais la classification organisationnelle. Comme ces hiérarchisations peuvent évoluer indépendamment des données de produits, elles devraient être mises à disposition séparément via l'API. Cela permet aux systèmes cibles de construire systématiquement leurs logiques de navigation ou de catégorisation sans avoir à transférer à nouveau l'ensemble de la structure à chaque interrogation sur un produit.

Vous connaissez certainement cette situation dans votre vie quotidienne : Au niveau d'un produit, les corrections sont plus fréquentes qu'au niveau de la structure de navigation. crossbase fait d'ailleurs une distinction très claire entre la structure interne de maintenance des données et les autres structures utilisées pour vos canaux de sortie.

Réduire la redondance des contenus récurrents

Dans une mesure similaire, les données maîtresses, telles que les désignations d'attributs disponibles en plusieurs langues, devraient être livrées séparément des données de produits. Ces informations changent relativement rarement et sont utilisées en commun par de nombreux produits. Si elles sont mises à disposition séparément et accessibles par clé, cela réduit considérablement la taille des réponses individuelles aux produits et simplifie le traitement du côté du destinataire.

Les listes de valeurs utilisées par les sites web pour les formulaires de recherche sont un autre exemple de données maîtresses. Il serait fastidieux d'extraire toutes les valeurs possibles d'une caractéristique de tous les produits. La récupération centralisée des données maîtresses permet d'y parvenir beaucoup plus rapidement !

Conclusion

Une API de données de produits basée sur REST qui tient compte de tous ces principes sera claire, flexible, efficace et à l'épreuve du temps. Elle peut être étendue extrêmement rapidement sans devoir modifier le code existant, prend en charge les intégrations dans de multiples environnements système et peut gérer sans problème des stocks de données croissants et des exigences de plus en plus élevées.