So here's the problem - I have a DataTable I want WCF (.NET 3.5) to send out in a JSON store format commonly used in ExtJS, etc - basically "Rows[{"Field1":value,"Field2":value},{...}]" but I cannot find the right structure to feed back to the Operation contract to send it out in this format.
So any ideas, or any further info needed.
Thanks, in advance!
AndyPC, unfortunately, you're out of luck.
If you're dealing with an object whose type is an IXmlSerializable, the WCF JSON serializer delegates to IXmlSerializable methods first, gets the serialized XML out of them, wraps the XML in a JSON string, and just passes that on. This is one of the major weaknesses of the WCF JSON model in .NET 3.5. I think the entity framework (WCF Data Services) technologies try to handle this more elegantly, but not sure. I'd recommend manually using the JSON serializer and crafting up a string or a manual serialization mechanism that does what you want...
Related
I noticed that Web API can return a DataTable as JSON but balks when returning it as XML.
What is (or are) the base interface(s) that your objects should inherit from in order for Web API to automagically serialize them?
And why would it be able to serialize a given object as JSON but not XML?
ASP.NET Web API uses DataContractSerializer for XML and JSON.NET for JSON. So, the respective serialization requirements hold good with web API as well. Check out this and this.
DataTable should get serialized by DCS, since DataTable implements IXmlSerializable. If you want more control over how XML is produced, you can implement IXmlSerializable yourself.
I am building an API using the WebAPI in ASP.NET MVC 4.0. I have built model classes based on sample XML supplied by my Business Analyst using the new, super smart Paste XML as Classes feature.
The problem is, when my client Accepts application/xml, the serialized response doesn't look like the original XML.
I have manually deserialized and serialized some XML (roundtrip) using the XMLSerializer, and although its better, closer to the original, it still lacks some namespace prefixes.
How can I ensure the output is exactly on spec.?
Firstly, you'll need to ensure the WebAPI is using the XmlSerializer to format your WebAPI responses, or at least use the XmlSerializer just for this resource/API.
In the WebApiConfig.cs file you'll find the route registration stuff and also some commented-out code.
Add under that chunk, add the following:
var xmlSerializer = new XmlSerializer(typeof(FruitXmlModel));
config.Formatters.XmlFormatter.SetSerializer<FruitXmlModel>(xmlSerializer);
This will specify the old XmlSerializer be used when serializing the FruitXmlModel CLR type. Note that you'll probably need to reference the XML serialization assemblies.
Next, you'll need to add this code to the class in your model that represents the element in your XML that begins the new namespace.
...
[XmlNamespaceDeclarations]
public XmlSerializerNamespaces Namespaces = new XmlSerializerNamespaces();
public FruitXmlModel() // ctor for one of my models
{
this.Namespaces.Add("banana", "http://www.fruitschema.org/banana");
}
...
If you've used the Paste XML as Classes feature, then this class should already be annotated with the correct attributes XmlTypeAttribute with the correct namespace set.
All being well, this simple change will provide the WebAPI and the XmlSerializer all that's needed to produce the properly prefixed XML output.
I wish you good luck, Luke, hope to meet again soon.
WCF REST service works great in a way that it will reply/accept JSON or XML depending on header.
I want to tweak built-in JSON serializer a little so it encodes/decodes Byte[] little different. More specifically, I want to use Base64 for that.
Is that any pointers/samples where I can set custom type serializer that will affect whole service?
The post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/05/03/wcf-extensibility-message-formatters.aspx shows how to replace the default JSON serializer (DataContractJsonSerializer) with a custom one (in this case, JSON.NET).
I just succeeded swapping out the default DataContractJsonSerializer with JSON.NET serializer in my WCF REST services 4.0 using NETFx Json.NET MediaTypeFormatter . Also see JSON.NET Serializer for WCF REST Services for the solution to a problem I ran into to get this working.
By default WCF use DataContractSerialization so if we can change it then my question is how to change it and when should we need which serialization on wcf ?
You can use the XmlSerializerFormatAttribute attribute on your service contract to force WCF to use the XmlSerializer.
WCF has a nice feature that a method can return Message or a Stream (see Returning raw json (string) in wcf and How to set Json.Net as the default serializer for WCF REST service as examples). The corresponding code which you need to write can be more easy as if you will use more advance techniques Extending Encoders and Serializers. So it is very easy to implement Streaming Message Transfer for example or just returning JPG or Excel file as a result of some WCF method.
The default choice of DataContractSerializer is good for most purpose. You can also use the DataContractJsonSerializer specially for REST type services and if the client expects Json content type. The other option is XmlSerializer for interoperability purpose if you need more control over the generated XML. DataContractSerializer is more efficient than XmlSerializer.
In 3rd party options you can use protobuf-net from Google which is more efficient than DataContract Serializer.
I have a question on the types that can be returned by a WCF service.Are there any specific complex types that can't be returned by a WCF service? To put more clearly, can we have any kind of complicated datatypes to be defined as Data Contracts and have them returned by the Service operations? Is there any limitation to any type?
Yes - anything that cannot be serialized into a message constrained by a XML schema file.
This includes:
interfaces (only concrete types)
generics
any data structure that doesn't just contain data, but also behavior (like a SqlConnection or something like that)
the Windows API primitives, like a Brush or other drawing elements
The main point is: whatever you're trying to send from client to server must be able to be serialized into an XML message, expressed in a XML schema, and deserialized back into a new object