Améliorations de l'API REST

Améliorations de l'API REST de la vitrine

Les six scénarios suivants montrent les interactions utilisateur qui appellent les API REST mises à jour. Il s'agit d'améliorations REST axées sur la vitrine.

Un utilisateur invité ajoute un produit à son panier.

Pour plus d'informations, voir POST /store/{storeId}/guestidentity.

Un utilisateur générique se connecte en tant qu'utilisateur inscrit

Lorsqu'un utilisateur se connecte à l'aide de son nom d'utilisateur et de son mot de passe, il appelle loginidentity pour se connecter. Ce service REST est amélioré pour renvoyer deux autres paramètres d'information sur les attributs : privacyNoticeVersion et marketingTrackingConsent. Ces deux valeurs d'attributs peuvent être utilisées pour vérifier si la fenêtre de politique de confidentialité apparaît ou non. Par exemple, si la version de l'avis de confidentialité est mise à jour vers une version plus récente après l'avoir comparée au cookie WC_PrivacyNoticeVersion_{storeId}, la fenêtre d'avis de confidentialité Just-in-Time s'affiche. Cette fenêtre affiche la version mise à jour à l'utilisateur.

Pour plus d'informations, voir POST /store/{storeId}/loginidentity.

Un utilisateur générique s'inscrit

Lorsqu'un utilisateur générique s'inscrit, il appelle le service REST pour créer un nouvel utilisateur. Ce service REST est amélioré pour accepter deux nouveaux paramètres dans le corps de la publication : privacyNoticeVersion et marketingTrackingConsent.

Pour plus d'informations, voir POST/store/{storeId}/person.

Un utilisateur inscrit affiche les informations de son compte

Lorsqu'un utilisateur inscrit affiche les informations de son compte, le service REST pour obtenir les données du compte est amélioré pour renvoyer des attributs supplémentaires : privacyNoticeVersion, privacyNoticeVersionTimestamp, marketingTrackingConsent et marketingTrackingConsentTimestamp.

Pour plus d'informations, voir GET/store/{storeId}/person.

Un utilisateur inscrit met à jour ses informations de compte

Un utilisateur inscrit peut mettre à jour son consentement marketing à partir de la page Compte, où le service REST peut être appelé. Ce service REST est amélioré pour accepter deux paramètres dans le corps : privacyNoticeVersion et marketingTrackingConsent. En conséquence, si l'utilisateur retire son consentement pour les communications marketing, les données de comportement de l'utilisateur sont supprimées.

Pour plus d'informations, voir PUT/store/{storeId}/person.

Un utilisateur lance la page Confidentialité à partir du pied de page pour mettre à jour son consentement aux communications marketing

Un utilisateur peut afficher la page Confidentialité et modifier ses données de consentement aux communications marketing. Le service /store/{storeId}/event/update_marketing_tracking_consent est appelé à mettre à jour les données de consentement aux communications marketing. Si l'utilisateur retire son consentement aux communications marketing, les données de comportement de l'utilisateur pour cet utilisateur sont supprimées en conséquence.

Pour plus d'informations, voir POST /store/{storeId}/event/update_marketing_tracking_consent.

Améliorations de l'API REST pour les agents de protection des données

Les cinq scénarios suivants montrent comment un agent de protection des données peut récupérer et supprimer les données utilisateur en fonction de la demande d'un client ou d'autres critères. Le rôle utilisateur par défaut de ces services est spiuser. Vous pouvez modifier le rôle de l'utilisateur en fonction de vos besoins.

Un utilisateur demande que ses renseignements personnels soient retirés du magasin

Vos développeurs peuvent fournir à un agent de protection des données des outils pour supprimer les informations personnelles d'un client de la base de données HCL Commerce. Le service /store/{storeId}/person/{userId} est appelé pour effacer toutes les données client.

Lorsque les données personnelles sont supprimées, le nom et l'adresse de la personne, toutes les informations relatives aux commandes, adresses, comptes d'utilisateurs, rôles de membre, listes de souhaits et au paiement qui appartiennent à cette personne seront supprimés.

Pour plus d'informations, voir DELETE /store/{storeId}/person/{userId}.

Un utilisateur demande que son historique de commande soit supprimé

L'historique des commandes de l'utilisateur peut être supprimé à l'aide d'un seul appel de service REST. Le service /store/{storeId}/order/@history?userId={userId} est appelé pour effacer l'historique des commandes du client.

Pour plus d'informations, voir DELETE /store/{storeId}/order/@history?userId={userId}.

Un agent de protection des données ou un client demande des données sur le comportement des utilisateurs collectées pour des activités de marketing

L'agent de protection des données souhaite avoir accès aux données de comportement de l'utilisateur d'un client parce que ces données sont obsolètes ou que le client a choisi de retirer son consentement pour une activité de marketing particulière. Le service /store/{storeId}/user_behavior?userId={userId} est appelé pour extraire les données de comportement utilisateur.

Pour plus d'informations, voir GET /store/{storeId}/user_behavior?userId={userId}.

Le comportement de l'utilisateur d'un client doit être supprimé, sur demande ou selon d'autres critères

Le comportement de l'utilisateur d'un client peut devenir obsolète, ou autrement être signalé pour la suppression sur demande, selon la stratégie, etc. Le service /store/{storeId}/user_behavior/{userId} est appelé pour supprimer le comportement utilisateur.

Pour plus d'informations, voir DELETE /store/{storeId}/user_behavior/{userId}.

Un client demande sa liste de souhaits

Un client ou un agent de protection des données peut demander la liste de souhaits du client. Le service /store/{storeId}/wishlist?userId={userId} extrait la liste de présélection.

Pour plus d'informations, voir GET /store/{storeId}/wishlist?userId={userId}.