WCF REST pour les options XML

Question

Je crée un service WCF REST, dans lequel je retourne du code XML.

J'ai une interface avec la méthode

[OperationContract] 
[WebInvoke(Method = "GET", RequestFormat = WebMessageFormat.Xml, UriTemplate = "?listcameras", ResponseFormat = WebMessageFormat.Xml)] 
List<TItem> ListItems(); 

où TItem

[DataContract(Name = "SomeContract", Namespace = "")] 
public class TITem 
{ 
    [DataMember] 
    public string Member1 
    { 
     get; 
     set; 
    } 

    [DataMember] 
    public string Member2 
    { 
     get; 
     set; 
    } 
} 

Lorsque vous appelez cette méthode que je puis obtenir retourné en XML à partir d'un HttpWebRequest, une liste des types TItem de en XML . Notez ci-dessus que je dois faire Namespace = "" sinon je ne peux pas sembler utiliser le XDocument. Descendants méthode et obtenir un nom correspondant.

Je veux juste quelques opinions si c'est le meilleur moyen de récupérer XML à partir de certains services WCF. Je veux que mon service WCF soit extensible et renvoie éventuellement plus que du code XML dans le futur

Answer 1

L'utilisation d'un espace de noms string.Empty ne pose aucun problème. L'intérêt d'utiliser un espace de noms est de le distinguer des autres contrats de données qui ont le même nom DataContract mais un espace de noms DataContract différent. Ceci est particulièrement important car les noms/espaces de noms DataContract ne sont pas nécessairement liés aux noms/espaces de noms dérivés de leur représentation de type CLR. En d'autres termes, si vous êtes sûr que vous n'aurez pas d'autres types avec le même nom DataContract dans un espace de noms différent dans votre application - et si vous pensez que vous ne le ferez plus dans le futur à cause de la gestion des versions considérations - vous pouvez continuer à utiliser string.Empty comme espace de noms de contrat de données. Au-delà de l'attribut d'opération (WebGet/WebInvoke), vous devez également prendre en compte la liaison et le comportement que vous utilisez maintenant et que vous utiliserez dans le futur. Par exemple, en ce moment, vous utilisez WebHttpBinding et WebHttpBehavior. Vous pouvez également contrôler quels formats de données sont supportés au niveau de WebHttpBinding - XML, JSON, Binary, etc. Vous pouvez également contrôler quel TYPE de XML est retourné par WebHttpBehavior - le XML peut être "nu" ou il peut être " enveloppé ", qui a l'imbrication supplémentaire. Enfin, vous pouvez même brancher votre propre DataContractSerializerOperationBehavior à un moment donné pour brancher un nouveau format de sérialiseur ou de données, si vous le souhaitez (mais si vous le faites, vous devrez implémenter votre propre sérialiseur, formateur, comportement , binding, encoder, etc. comme cela a été fait pour SOAP et JSON.)

Espérons que cela aide!