In practice you're almost always better off just picking a single format for your endpoint, in which case there's no reason to use WCF.
Have enumerations somewhere? WCF will encode them as integers. Have or need a date/time value in a format that isn't what WCF generates or expects - e.g. JSON Date() expressions? Doable, but error prone, slow and unintuitive (and ... In that case - why use WCF at all?)
WTF would have been a better name for this library.
The UK National Rail API is a WCF SOAP endpoint so I wrote this open source proxy with Web API to make it easier for non-.NET developers more familiar with restful JSON: https://github.com/jpsingleton/Huxley
Can you give an example of this? I have never had this problem.
> Have or need a date/time value in a format that isn't what WCF generates or expects
In my experience this is a data-interchange problem that will always exist. It is not unique to WCF.
I do agree that if you are using REST/Json then you should avoid WCF.
But e.g. Enum Direction { East, West, North, South };
Put that as a field in a structure that's sent/received through WCF; on JSON it will encode as numbers, regardless on any annotation you put. On XML iirc too - though I don't remember for sure. Want them as strings? You have to encode/decode yourself. But if you use .NET on both sides , you wouldn't notice unless you sniff the connection - until you change the enumeration order, for example, and all help breaks loose. Which is to be expected of a binary protocol, but completely unexpected for verbose text formats like JSON or XML.
It serializes correctly.
For JSON you need an appropriate converter but as I said I would not use WCF with JSON.
https://github.com/faniereynders/WebApiProxy/wiki/WebApi-C%2...
Nancy http://nancyfx.org/
service stack https://servicestack.net/
Asp.net web api http://www.asp.net/web-api
https://msdn.microsoft.com/en-us/library/jj823172%28v=vs.110...
My personal opinion is if you want to use an MS technology, use Web API unless you have a compelling reason to use WCF.
Also, the major advantage of SOAP is that at least it has a service description. So generating clients is an easy one step process (and, having shipped such a service, when works on many platforms and languages reasonably well). All these new HTTP/JSON APIs require custom clients each time. Until they invent WSDL for such services... And full circle. Except JSON instead of XML, so it's totally OK.