2009-11-30 6 views
8

Je conçois une API pour un service Web et je ne peux pas décider entre l'utilisation d'attributs XML, d'éléments ou d'une architecture mixte. Je vais vous montrer un exemple.Conception d'API de services Web: éléments XML et attributs

Supposons que j'ai un objet appelé Domaine. Ce modèle a 3 propriétés (tld, sld, trd et name lui-même) et une méthode valid? qui renvoie true si le domaine est valide.

# I'm using ruby but 
# consider this as pseudo-code 
class Domain 
    attr_accessor :tld, :sld, :trd, :name 

    def valid? 
    true # force true 
    end 
end 

Mon api appelé /domain/parser prend un domaine en entrée et renvoie la réponse analysable. La première possibilité consiste à utiliser un élément pour chaque attribut de domaine.

<result> 
    <domain> 
    <name>www.google.it</name> 
    <tld>it</tld> 
    ... 
    <valid>true</true> 
    </domain> 
</result> 

Mais certaines interfaces utilisent des attributs.

<result> 
    <domain tld="it" sld="google.com" trd="www" rule="*.foo" name="www.google.it" valid="true" /> 
</result> 

Et n'oubliez pas les attributs et la valeur.

<result> 
    <domain tld="it" sld="google.com" trd="www" rule="*.foo" name="www.google.it" valid="true"> 
    www.google.it 
    </domain> 
</result> 

À votre avis, qui est le choix le plus puissant, flexible et expressif? En outre, considérez que la réponse sera servie dans XML et JSON (bientôt).

+1

D'autres ont répondu à des points principaux; mais une remarque supplémentaire est que la question de la représentation JSON alternative doit être orthogonale à la représentation XML. C'est-à-dire que votre choix d'éléments et d'attributs ne devrait avoir aucun effet sur la façon dont JSON devrait être structuré. Puisque XML et JSON diffèrent structurellement, vous ne devriez pas convertir entre les deux: plutôt, les produire séparément, mais à partir du même objet que vous avez. Ceci permet aux deux représentations d'être "optimales", comme de ne pas être obligé d'utiliser des mappages pour surmonter les limitations (ce qui est fait par certains mappages JSON, pour convertir à partir de XML). – StaxMan

Répondre

8

Le modèle que je l'utilise est:

  • éléments sont pour l'attribut de données
  • sont pour les méta-données (à savoir les données sur les données)

Si vous utilisez le schéma XSD, la plupart sinon toutes vos méta-données devraient y aller, mais si vous n'avez pas d'attributs, c'est un bon endroit pour cela.

donc avec votre exemple, je pourrais faire quelque chose comme ceci:

<result> 
    <domain valid="true"> 
    <name>www.google.it</name> 
    <tld>it</tld> 
    ... 
    </domain> 
</result> 
5

Les concepteurs de WCF ont choisi d'éviter les attributs, principalement pour des raisons de performances. Le sérialiseur par défaut WCF, DataContractSerializer, ne prend pas en charge les attributs (ce qui peut être quelque chose à prendre en compte), mais il est environ 10% plus rapide que le XmlSerializer plus flexible de .NET. Par conséquent, si vous considérez que vous conservez du contenu devant être consommé par un client WCF, vous essaierez probablement d'éviter les attributs, si possible.

Les attributs ne seront jamais que "atomiques", par ex. une chaîne, un int etc. - les éléments offrent beaucoup plus de flexibilité de cette façon. De plus, les attributs n'existent jamais seuls - ils sont toujours collés sur un élément. D'après mon expérience personnelle et mes préférences personnelles, j'essaierai probablement d'utiliser la plupart du temps des éléments et d'éviter autant que possible les attributs. Mais ce n'est vraiment qu'une préférence personnelle et un goût - les attributs sont absolument valables en XML, pas de problème.

+0

C'est bizarre! Donc vous me dites, par exemple, que l'API FeedBurner est incompatibile avec WCF? http://code.google.com/apis/feedburner/awareness_api.html –

+0

@weppos: non - si l'utilitaire WCF svcutil détecte des attributs dans un fichier XML, il retournera à la version (plus lente) de XmlSerializer. –

3

C'est principalement une question de goût, mais il y a quelques considérations techniques. Les attributs sont légèrement plus restreints dans les caractères qu'ils peuvent contenir. Ils ont l'avantage (?) Que cet ordre est immatériel mais ils ne peuvent être répétés. Cela peut légèrement influencer votre choix en fonction de ce jeu d'outils que vous avez

+1

Techniquement, les attributs peuvent contenir exactement les mêmes caractères, il suffit de citer un ensemble de caractères légèrement différent. – StaxMan

+0

Vrai en principe - mais ce serait beaucoup de travail et pas naturel d'éviter la normalisation des espaces. –

3

Si vos données peuvent être considérées comme ayant deux niveaux, où l'on est les données de base et l'autre est une sorte de méta-données (par exemple, étiquettes pour certains éléments), vous voudrez peut-être utiliser des éléments pour les premiers et les attributs de celui-ci, par exemple:

<result id="1"> 
    <domain type="default"> 
    <name unique="false">www.google.it</name> 
    <tld>it</tld> 
    ... 
    <valid>true</true> 
    </domain> 
</result> 

en règle générale, si vous arrachez tous les attributs les données restantes semble toujours significative.

Une autre règle que j'utilise parfois est les attributs pour les données récapitulatives et les éléments pour le reste. Ensuite, si je veux envoyer une liste récapitulative par exemple, j'envoie juste l'élément supérieur plus ses attributs et omets les éléments contenus. Par exemple.

<result> 
    <domain name="www.google.it"> 
    <tld>it</tld> 
    ... 
    <valid>true</true> 
    </domain> 
</result> 

qui, dans une liste devient:

<results> 
    <domain name="www.google.it" /> 
    <domain name="www.google.co.uk" /> 
    <domain name="www.google.com" /> 
</results> 

Par ailleurs, si aucun de ces cas s'appliquent alors vous pourriez vouloir utiliser des éléments pour tout ce qui a une structure interne ou lorsque l'ordre est important, et les attributs pour tout le reste, selon votre deuxième exemple XML.

Questions connexes