De votre question, je crois comprendre que l'interface de service Web ressemble à quelque chose comme ceci:
/product/
/product/{ProductId}
/product/{ProductName}
/product/category/{CategoryId}
Puisque vous demandez si vous devez stocker CategoryName, je suppose qu'il est unique (comme ProductName). Je suppose également que le service Web gère les cas où les produits ou les catégories sont renommés de façon transparente (c'est-à-dire en fournissant une redirection ou tout autre moyen permettant de détecter cela et de le gérer en conséquence). Si ce n'est pas le cas, n'envisagez pas de stocker des noms en tant que références à des produits ou catégories - utilisez toujours des ID.
Je fournirait la même réponse à vos des questions # 1 et # 2. Même si l'unicité de ProductName et CategoryName vous permettra techniquement de les stocker dans votre application en tant qu'identifiants uniques de produits et de catégories, j'opterais plutôt pour le stockage de leurs identifiants. Le point de décision principal serait votre support de stockage. Comme vous utilisez une base de données et que le service Web vous permet d'accéder aux objets par des ID numériques uniques, les règles de normalisation de la base de données doivent s'appliquer. Vous devez donc stocker les ID. Ce qui précède suppose cependant que vous utilisez une base de données relationnelle - si vous utilisez une base de données NoSQL, je suppose que stocker des noms à la place des ID serait également une option viable (du moins pour autant que je sache avec mon compréhension actuelle des solutions NoSQL, malheureusement je n'ai encore aucune expérience pratique avec l'un d'entre eux).
En ce qui concerne la question n ° 3 - Je tiendrais avec les conventions de nommage que vous utilisez déjà dans votre base de données.Il existe de nombreuses conventions différentes pour nommer les tables et les colonnes, donc je doute vraiment qu'il existe des conventions standardisées sur la façon de nommer les colonnes référençant les objets de service Web. Je les nomme en fonction de vos conventions de nommage existantes et d'une manière que des colonnes soit claire pour tous ceux qui utilisent le système. Notez que s'il est possible que vous utilisiez d'autres services Web à l'avenir, vous devriez envisager de conserver le nom du service dans le nom de la colonne plutôt que d'utiliser un préfixe ws générique, par exemple. AmazonProductId ou AmazonCategoryId.
Je vais essayer de rappeler quelques éléments de mon expérience, mais je ne voudrais pas les étiqueter comme les meilleures pratiques - seulement des sujets de réflexion. Dans mon expérience, j'ai trouvé utile de traiter les données des services Web de la même manière que les données d'une base de données - au moins du point de vue d'une application, où votre couche de stockage serait abstraite de la logique applicative. J'entends par là que vous devriez penser à et préparer des scénarios similaires, peu importe si votre support de stockage est une base de données ou un service Web. De même que les bases de données, les services Web peuvent tomber en panne, les deux peuvent avoir des données corrompues ou corrompues, les deux vous obligeront à nettoyer ou à traiter les données en entrée.
Mise en cache des données devrait être un élément qui est élevé sur votre liste - en dehors des raisons de performances évidentes, il peut vous permettre de faire face aux pannes du service Web (à une mesure limitée par les données que vous mettez en cache).
Un exemple serait que votre application affiche une liste de produits les plus fréquemment achetés dans votre application. Si votre application stocke uniquement les ID de produits, vous devez effectuer une ou plusieurs demandes auprès du service Web afin de récupérer les noms de tous les produits que vous devez afficher dans la liste. Si vous mettez en cache les noms de produits localement ou dans votre base de données, vous obtiendrez de meilleures performances, conserverez vos ressources et vous disposerez également d'un scénario de sécurité au cas où le service Web tomberait en panne.
L'intégrité référentielle est un autre aspect important à considérer lors de l'utilisation de services Web. Comme le service Web est complètement séparé de votre base de données, vous n'avez pas la possibilité de créer des clés étrangères comme vous le feriez dans une solution de base de données uniquement. Cela signifie que les modifications de données dans le service Web (c'est-à-dire les mises à jour ou les suppressions de produits) peuvent briser l'intégrité des données dans votre base de données. En ce qui concerne références, ceux-ci dépendent principalement du type de service Web que vous êtes sur le point d'utiliser (vous n'avez pas spécifié quel service vous allez utiliser). Si le service est basé sur les principes REST, je peux recommander Restful Web Services by Leonard Richardson and Sam Ruby. Même s'il n'est pas axé sur l'intégration d'applications/services en tant que telle, c'est une excellente introduction à REST.