Hacker News new | ask | show | jobs
by strommen 4050 days ago
WCF is great if you want to make a single data service available as JSON via REST, XML via SOAP, a custom binary protocol via raw TCP, and who-knows-what else.

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.

4 comments

WCF is passable iff both your sides are .NET - in which case it is an overkill, slow and unneededly complex. If your other endpoint is not .NET, it's all of that and also horribly broken.

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.

I remember so much pain trying to get a .NET WCF and Java SOAP service to work together when they should have been compatible. This is an amusing read: http://harmful.cat-v.org/software/xml/soap/simple :)

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

Strangely that's the one area where I've always had success with WCF.
> Have enumerations somewhere? WCF will encode them as integers.

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.

On phone, can't copy/paste.

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.

> On XML iirc too

It serializes correctly.

For JSON you need an appropriate converter but as I said I would not use WCF with JSON.

WCF's REST is the ugliest implementation of HTTP/REST I've seen from any framework, whilst its RPC method signatures, SOAP format and code-gen client proxies provide one of the most fragile combination of technologies used in web services today: http://www.infoq.com/articles/interview-servicestack
What are some other libraries and frameworks that should be used? (For C# web services)
There is also a proxy generator for Web API so you still keep some of the benefits of WCF.

https://github.com/faniereynders/WebApiProxy/wiki/WebApi-C%2...

for web services

Nancy http://nancyfx.org/

service stack https://servicestack.net/

Asp.net web api http://www.asp.net/web-api

Worth considering:

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.

Web API is the easiest thing you can use. I switching from desktop programming to web and creating restful services in web api allowed me to do a lot with little and also teach me a thing or two about REST. I highly recommend it.
Or if you want to flow delegated credentials, or use cross-system transactions. The enterprise stuff actually does something that can be useful inside a company.

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.