Generic WCF JSON Deserialization

Question

I am a bit new to WCF and will try to clearly describe what I am trying to do.

I have a WCF webservice that uses JSON requests. I am doing fine sending/receiving JSON for the most part. For example, the following code works well and as expected.

JSON sent:

{ "guy": {"FirstName":"Dave"} }

WCF:

    [DataContract]
    public class SomeGuy
    {
        [DataMember]
        public string FirstName { get; set; }

    }

[OperationContract]
    [WebInvoke(Method = "POST",
               BodyStyle = WebMessageBodyStyle.WrappedRequest,
               RequestFormat = WebMessageFormat.Json,
               ResponseFormat = WebMessageFormat.Json)]
    public string Register(SomeGuy guy)
    {
        return guy.FirstName;
    }

This returns a JSON object with "Dave" as expected. The problem is that I cannot always guarantee that the JSON I recieve will exactly match the members in my DataContract. For example, the JSON:

{ "guy": {"firstname":"Dave"} }

will not serialize correctly because the case does not match. guy.FirstName will be null. This behavior makes sense, but I don't really know how to get around this. Do I have to force the field names on the client or is there a way I can reconcile on the server side?

A possibly related question: can I accept and serialize a generic JSON object into a StringDictionary or some kind of simple key value structure? So no matter what the field names are sent in the JSON, I can access names and values that have been sent to me? Right now, the only way I can read the data I'm receiving is if it exactly matches a predefined DataContract.

Answer 1

It really depends on what you are using the data for. In theory, you can keep this generic by having a string return type. However the data would represent an object and the client side control should know how to enumerate the JSON Object returned. You can return type which may also help.

Then in your client side code you can have a feature that knows how to determine and read different types.

Answer 2

You can try and add another DataMember attribute with the lowercase name, but I assume you want a case-insensitive approach to reconciling member names, in which case, using extra DataMember attributes becomes unreasonable.

You could provide a IDataContractSurrogate implementation, but that is going to involve a lot of extra work on your part, as well as a lot of reflection (there's no way to do this in a static way which can be verified at compile-time).

Personally, I've given up on using the DataContractSerializer when it comes to JSON. Rather, I use Json.NET for all of my JSON needs. I can see where you might be able to plug in Json.NET into the DataContractSerializer through a IDataContractSurrogate, but it's still going to be a little rough.

Json.NET was an easy choice given the difficulty of using the DataContractSerializer. Also, add to the fact that the DataContractSerializer for JSON doesn't handle DateTimeOffset values correctly, and it was a no-brainer for me, especially since I was working in an ASP.NET MVC environment.

This is really the better choice if you are exposing RESTful services using JSON as the encoding, you can mix and match that with WCF to expose all the endpoints over all the transport and message protocols you need.

Answer 3

As the name implies, a data contract is a set of rules. If you want to reliably map messages to operations, then those rules need to be followed.

Why can't you guarantee that the casing will be correct? If you just want to use lowercase identifiers from JavaScript instead, you can use the MessageParameter attribute for that - but you still have to choose a specific name.

In theory you could accept raw JSON and deserialize it manually (just take a string parameter and use any JSON library for deserialization), but that is really not in the spirit of WCF.

I think what you really need to fix is not the fact that the data contract is case sensitive, but the fact that the JSON isn't being put together correctly at the client side.

---

If you want to accept the raw JSON string in your operation, then change the BodyStyle to WebMessageBodyStyle.Bare, and change your method signature to accept a single string parameter, which will be populated with whatever JSON string was sent by the client.

Note that all you get is a single string out of this, you have to do all the parsing and property mapping and validation and error handling yourself. It's not the route I would choose to take, but if you're willing to take on the effort and risk involved, it's one potential option.

Answer 4

Thanks to everyone for the ideas and conversation. They pointed me in some really good research directions. Here's where it landed me.

In order to achieve my goal of having a service that can accept a completely arbitrary list of "key": "value" pairs as a raw JSON string and then decide what do do with them without having to know the "key" names beforehand, I combined casper and aaron's advice.

1st, to access the raw JSON string, this MSDN blog was very helpful.

I was unable to simply change the single method parameter to String and the BodyStyle to WebMessageBodyStyle.Bare without problems. When setting BodyStyle to Bare, make sure that the endpoint behaviorConfiguration is set to <webHttp/> and not <enableWebScript/>.

The second note is that, as Casper mentioned, the method can only have 1 parameter. This parameter needs to be a Stream in order to access the raw text though (see MSDN blog above).

Once you have the raw JSON string, it's just a matter of deserializing it into a StringDictionary. I chose JSON.Net for this and it works wonderfully. Here's a bare bones example to illustrate.

[OperationContract]
[WebInvoke(Method = "POST",
    BodyStyle = WebMessageBodyStyle.Bare,
    ResponseFormat = WebMessageFormat.Json)]
public string Register(Stream rawJSON)
{

    // Convert our raw JSON string into a key, value
    StreamReader sr = new StreamReader(rawJSON);
    Dictionary<string, string> registration = JsonConvert.DeserializeObject<Dictionary<string, string>>(sr.ReadToEnd());

    // Loop through the fields we've been sent.
    foreach (KeyValuePair<string, string> pair in registration)
    {
        switch (pair.Key.ToLower())
        {
            case "firstname":
                return pair.Value;
                break;
        }

    }
}

This allows me to accept an arbitrary list of fields via JSON and for the field names to be case insensitive. I know it's not the strictest approach to data integrity or to how WCF services would ideally be structured, but, as far as I can tell, it's the simplest way to get where I want to go.

If anyone has another method or a reason why this sort of solution is way off base, I'd love to hear it. Thanks again, everyone!