2009-11-30 22 views
8

Sto progettando un'API per un servizio Web e non riesco a decidere tra l'uso di attributi XML, elementi o un'architettura mista.servizi di web design API: gli elementi XML vs. attributi

Lascia che ti mostri un esempio. Supponiamo di avere un oggetto chiamato Dominio. Questo modello dispone di 3 proprietà (tld, sld, trd e il name in sé) e un metodo valid? che restituisce vero se il dominio è valida.

# 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 

mio API chiamata /domain/parser prende un dominio in input e restituisce la risposta analizzata. La prima possibilità è di usare un elemento per ogni attributo di dominio.

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

Ma alcune interfacce utilizzano attributi.

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

E non dimenticare attributi e valore.

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

Secondo lei, che è la scelta più potente, flessibile ed espressivo? Inoltre, considera che la risposta verrà pubblicata in XML e JSON (a breve).

+1

Altri hanno risposto ai punti principali; ma una nota aggiuntiva è che la questione della rappresentazione JSON alternativa dovrebbe essere ortogonale alla rappresentazione XML. Cioè, la scelta tra elementi e attributi non dovrebbe avere alcun effetto su come JSON dovrebbe essere strutturato. Dato che XML e JSON differiscono strutturalmente, non dovresti convertire tra i due: piuttosto, li produci separatamente ma dallo stesso oggetto che hai. Ciò consente a entrambe le rappresentazioni di essere "ottimali", come nel non essere costretti a usare i mapping per superare le limitazioni (che è fatto da alcuni mapping JSON, per convertire da XML). – StaxMan

risposta

8

Il modello che uso è:

  • elementi sono per i dati
  • attributo sono per i metadati (ad esempio dati relativi ai dati)

se si utilizza XSD la maggior parte se non tutti i meta-dati dovrebbe andare in là, ma se non sono attributi buon posto di schema per esso.

Quindi, con il tuo esempio, potrei fare qualcosa di simile:

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

I progettisti di WCF hanno scelto di evitare attributi, principalmente per motivi di prestazioni. Il serializzatore predefinito WCF, DataContractSerializer, non supporta gli attributi (quindi potrebbe essere qualcosa da tenere in considerazione), ma è circa il 10% più veloce rispetto al più flessibile XmlSerializer in .NET.

Quindi, se mai vedere voi stessi fornire un documento per essere consumato da un client WCF, è probabile che cercare di evitare di attributi, se mai possibile.

Gli attributi sono sempre e solo andando essere "atomica", ad esempio, una stringa, un int, ecc. - gli elementi offrono molta più flessibilità in questo modo. Inoltre, gli attributi non esistono mai da soli - sono sempre virati su un elemento.

Dalla mia esperienza personale e preferenze personali, avrei probabilmente cercare di utilizzare per lo più elementi ed evitare gli attributi per quanto mi è possibile. Ma questa è solo una preferenza e un gusto personale - gli attributi sono assolutamente validi in XML, nessun problema.

+0

Questo è strano! Quindi mi stai dicendo, ad esempio, che l'API di FeedBurner è incompatibile con WCF? http://code.google.com/apis/feedburner/awareness_api.html –

+0

@weppos: no - se l'utility svccil WCF rileva eventuali attributi in un XML, tornerà invece al (più lento, legacy) XmlSerializer. –

3

È principalmente una questione di gusti, ma ci sono alcune considerazioni tecniche. Gli attributi sono leggermente più limitati in quali caratteri possono contenere. Hanno il vantaggio (?) Che l'ordine è immateriale ma non possono essere ripetuti. Questo può essere un po influenzare la vostra scelta in base a ciò che set di strumenti avete

+1

Tecnicamente gli attributi possono contenere esattamente gli stessi caratteri, basta citare un insieme leggermente diverso di caratteri. – StaxMan

+0

Vero in linea di principio - ma sarebbe molto laborioso e innaturale evitare la normalizzazione degli spazi bianchi. –

3

Se i dati possono essere pensati come avere due livelli, dove si è i dati di base e l'altro è una sorta di metadati (ad esempio, etichette per alcuni elementi) allora si potrebbe desiderare di utilizzare elementi per l'ex e gli attributi per questi ultimi, ad esempio:

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

genere se si striscia tutti gli attributi i dati rimanenti sembra ancora significativo.

Un'altra regola che a volte utilizzo è attributi per dati di riepilogo e elementi per il resto. Quindi se voglio inviare una lista di riepilogo, per esempio, io mando l'elemento superiore più i suoi attributi e tralascio gli elementi contenuti. Per esempio.

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

, che in un elenco diventa:

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

In alternativa, se nessuno di questi casi si applicano allora si potrebbe semplicemente voler utilizzare gli elementi per tutto ciò che ha struttura interna o in cui l'ordine è importante, e gli attributi per tutto il resto, secondo il tuo secondo esempio XML.

Problemi correlati