Utilisation de GUID comme ID dans un service Web d'intégration de données public

Question

Pour mettre la question en contexte, le système exposant le service Web utilise les GUID en interne en tant qu'identifiants pour toutes les entités. Dans ce cas, lors de la conception d'un service Web d'intégration de données public (utilisé principalement pour importer ou exporter des données du système vers d'autres systèmes externes), que considéreriez-vous comme le pour et le contre de l'utilisation des identifiants internes dans le système? interface du service? Avec une telle solution, les méthodes d'exportation du service Web retourneraient les dto identifiés avec des GUID et les méthodes d'importation accepteraient des dto similaires - je suppose que le système externe serait responsable de générer de nouveaux GUID pour de nouvelles entités.

Quels sont les problèmes potentiels que l'on pourrait rencontrer avec cette approche?

La pile technologique pour le système et le service web est .NET/WCF/SOAP

Answer 1

D'abord, regardons plus générique « comment puis-je configurer une API publique » question, mon premier exercice consiste à déterminer ce que l'information est nécessaire au consommateur du service. Je regarde aussi s'il y a une dénomination propre à l'entreprise dans le modèle d'objet. Je crée ensuite un modèle de service (contrat de données, si vous voulez que WCF spécifique) qui correspond à la vue que je veux montrer au consommateur. Cela inclut une clé unique, qui est plus souvent une chaîne SKU (clé lisible par l'utilisateur) qu'un GUID/int (la clé primaire dérivée réelle), car le SKU est public et le moyen de stockage dans la base de données ne l'est pas. Donc, en général, je n'exposerais pas ces concepts clés primaires, si c'est ce que le GUID est.

Maintenant à la question de "voyez-vous des problèmes avec cette approche". Je vais me concentrer sur des concepts plus généraux afin que vous puissiez prendre une décision plus éclairée, car il n'y a pas 100% de bonnes/mauvaises réponses.

Tant que cela est machine à machine et l'utilisation du GUID est quelque chose que les deux systèmes sont conscients, je ne vois rien de particulièrement effrayant à propos de cette approche. Si cette ultime va à un système lisible par l'homme où le GUID doit interagir, alors vous avez un problème.

Un problème potentiel avec le système est d'exposer vos propres informations de clé primaire aux systèmes client ou client, qui n'ont pas à comprendre ce niveau de détail. Si cela est en fait "semi-public" avec une liste de fournisseurs, le "risque" pourrait être moindre. C'est le problème principal que je vois. On pourrait argumenter le poids du GUID (128 bits) par rapport à un identificateur plus petit, mais c'est une fausse réponse, IMO, car la latence du réseau l'emporte sur l'envoi de quelques octets de plus en tant que paramètre de requête.