WCF REST for XML选项

Question

I am making a WCF REST service, in which I return back some XML.

I have an interface with the method

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

where TITem

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

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

When calling this method I then get returned back in XML from a HTTPWebRequest, a list of type TITem's in XML. Notice above I have to make Namespace = "" else I can't seem to use the XDocument. Descendants method and get a matching name.

I just want some opinions if this is the best way to get back XML from some WCF Service. I do want my WCF Service to be extensible and possibly return more than just XML in the future

Answer 1

There is no problem with using a namespace that's string.Empty. The whole point of using a namespace at all is to distinguish it from other data contracts that have the same DataContract name but a different DataContract namespace. This is particularly important because DataContract names/namespaces are in no way necessarily related to the names/namespaces as derived from their CLR type representation.

In other words, if you're sure you will NOT have other types with the same DataContract name in a different namespace in your application -- and if you believe that you will not one in the future because of versioning considerations -- you can continue to use string.Empty as the data contract namespace.

Beyond just the operation attribute (WebGet/WebInvoke), you also need to consider what binding and behavior you're using now and that you'll use in the future. For example, right now, you may be using WebHttpBinding and WebHttpBehavior. You can control what data formats are supported at the WebHttpBinding level as well -- XML, JSON, Binary, etc. You can also control what TYPE of XML is returned from WebHttpBehavior -- the XML can be "bare" or it can be "wrapped", which has extra nesting. Finally, you can even plug in your own DataContractSerializerOperationBehavior at some point to plug in an entirely new serializer or data format of your own, should you so choose (though if you do that, you will need to implement your own serializer, formatter, behavior, binding, encoder, etc. like it has been done for SOAP and JSON.)

Hope this helps!