2009-11-30 9 views
8

Estoy diseñando una API para un servicio web y no puedo decidir entre usar atributos XML, elementos o una arquitectura mixta.Diseño de API de servicios web: elementos XML vs. atributos

Déjame mostrarte un ejemplo. Supongamos que tengo un objeto llamado Dominio. Este modelo tiene 3 propiedades (tld, sld, trd y name) y un método valid? que devuelve verdadero si el dominio es válido.

# 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 

Mi API denominada /domain/parser tiene un dominio de entrada y devuelve la respuesta analizada. La primera posibilidad es usar un elemento para cada atributo de dominio.

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

Pero algunas interfaces usan atributos.

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

Y no olvide los atributos y el valor.

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

En su opinión, ¿cuál es la opción más poderosa, flexible y expresiva? Además, considere que la respuesta se publicará en XML y JSON (pronto).

+1

Otros han respondido a los puntos principales; pero una nota adicional es que la pregunta de la representación JSON alternativa debe ser ortogonal a la representación XML. Es decir, su elección de elementos vs atributos no debería tener ningún efecto sobre cómo debería estructurarse JSON. Dado que XML y JSON difieren estructuralmente, no debe convertir entre los dos: en su lugar, los produce por separado, pero desde el mismo objeto que tiene. Esto permite que ambas representaciones sean "óptimas", ya que no se ven obligadas a utilizar asignaciones para superar las limitaciones (lo que se hace mediante algunas asignaciones JSON para convertir desde XML). – StaxMan

Respuesta

8

El patrón de uso es:

  • elementos son para datos
  • atributo son para los metadatos (es decir, datos sobre los datos)

si usa la mayoría de los metadatos del esquema XSD, si no todos sus metadatos deberían ir allí, pero si no tiene atributos, es un buen lugar para ello.

Así que con su ejemplo que podría hacer algo como esto:

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

Los diseñadores de WCF eligieron evitar los atributos, principalmente por motivos de rendimiento. El serializador predeterminado WCF, el DataContractSerializer, no admite atributos (por lo que podría ser algo a tener en cuenta), pero es aproximadamente un 10% más rápido que el XmlSerializer más flexible en .NET.

Así que si alguna vez se ve a sí mismo sirviendo contenido para ser consumido por un cliente WCF, es probable que trate de mantenerse alejado de los atributos, si es posible.

Los atributos solo serán "atómicos", p. una cadena, un int. etc. - los elementos ofrecen mucha más flexibilidad de esa manera. Además, los atributos nunca existen por sí solos, siempre están añadidos a un elemento.

Desde mi experiencia personal y preferencia personal, lo más probable es que intente utilizar la mayoría de los elementos y evitar los atributos tanto como pueda. Pero eso es solo una preferencia personal y un gusto: los atributos son absolutamente válidos en XML, no hay problema.

+0

¡Esto es extraño! Entonces, ¿me está diciendo que, por ejemplo, la API de FeedBurner es incompatible con WCF? http://code.google.com/apis/feedburner/awareness_api.html –

+0

@weppos: no - si la utilidad svcutil de WCF detecta algún atributo en un XML, en su lugar cambiará a XmlSerializer (más lento). –

3

Es principalmente una cuestión de gusto, pero hay algunas consideraciones técnicas. Los atributos son un poco más restringidos en cuanto a los caracteres que pueden contener. Tienen la ventaja (?) De que el orden es inmaterial pero no pueden repetirse. Esto puede influir ligeramente su elección de acuerdo con lo que el conjunto de herramientas que tiene

+1

Técnicamente, los atributos pueden contener exactamente los mismos caracteres, solo hay que citar un conjunto ligeramente diferente de caracteres. – StaxMan

+0

Verdadero en principio, pero sería mucho trabajo y antinatural evitar la normalización del espacio en blanco. –

3

Si sus datos pueden ser considerados como teniendo dos niveles, donde se encuentra los datos básicos y el otro es una especie de metadatos (por ejemplo, etiquetas para ciertos elementos), entonces es posible que desee utilizar elementos para el primero y atributos de este último, por ejemplo:

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

Normalmente, si se tira de todos los atributos de los datos que todavía sigue pareciendo significativo.

Otra regla que a veces uso es atributos para datos de resumen y elementos para el resto. Entonces, si quiero enviar una lista de resumen, por ejemplo, solo envío el elemento superior más sus atributos y omito los elementos que contiene. P.ej.

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

el cual en una lista se convierte en:

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

Alternativamente, si ninguno de esos casos se aplican a continuación, es posible que quieran utilizar elementos para cualquier cosa que tiene una estructura interna o donde el orden es importante, y atributos para todo lo demás, según su segundo ejemplo de XML.

Cuestiones relacionadas