Should I even bother supporting anything but RESTful HTTP?

Question

I'm developing a WCF-based API for my company's CRM software. In the future, it will be used to develop applications on multiple platforms. I know WCF provides named pipe, TCP, and HTTP transports, but should I bother with the complexity of supporting all three when everything seems to be using RESTful HTTP these days?

Answer 1

For simplicity, HTTP transport would be the most widely used transport with the most amount of flexibility. It also will likely work in almost all situations. Note that there is overhead involved so it isn't the fastest. There's always tradeoffs.

Answer 2

I have not looked at Indigo in a while, but as far as I remember, there are some things that RESTful HTTP does not support and has no analog, like WS-Transactions, WS-Security and couple others. If you need these, you'll have to switch to SOAP. If not, REST should be good enough for your company.

There's also the question of performance. SOAP encoded as binary XML over TCP or named pipe offers will be a bit faster than text XML over HTTP.

On the other hand, adding TCP and named pipes for the most parts is almost trivial and the cost is mostly around te deployment and configuration of the app server.

So, I wouldn't rule these two out of question from the start. Nor would I add them as features until needed. What I'd do though is to make sure both SOAP and REST over HTTP work properly for the service, just so that I have the option to expand in future if required.

Answer 3

In general your WCF components shouldn't be coupled to anything including transport, security, and other protocols and technologies. The ultimate goal (probably not 100% possible yet) would be to write your service interface and implementation once and then be able to use them in any sort of environment over any protocol with any sort of security. All of that can be defined in your configuration files and in your client apps.

Answer 4

REST is the architectural style of the web, not just xml files over htttp without SOAP.

WCF is a framweork with the sole purpose in life is to abstract developers from the underlying platform / protocol / stack of specs. WCF REST was a poor addition to the toolkit to let you expose POX services.

RESTfulness requires distribution, lack of session, designing of custom media types or reuse of existing ones, and many other properties you need to think about. Designing a REST architecture is as much about xml ove rhttp as designing an SOA one is about having a soap envelope.

Answer 5

You've asked two different questions without realizing it.

The first question is, what transport should I use -- HTTP, TCP, or named pipes? Since you're building a new service from scratch, I'd suggest using HTTP as the transport since your service will have a much easier time getting through firewalls. The other transport types are used primarily to simplify communication with other services and clients that might not understand HTTP.

The second question is, what style of HTTP web service should I use? Should I adopt the WS-* stack, an XML-RPC pattern, plain old XML (POX), or a RESTful approach? This is a more complicated question.

WCF makes the ws-* and XML-RPC styles easy. The POX style of webservice is somewhat tricker to configure using WCF. Building a truly RESTful service using WCF is quite hard -- you'll have to understand the fundamentals of how WCF works and disable some of the "magic" that it performs for you.

I think the RESTful architecture style is simple and proven, and a good choice. But it's difficult to configure WCF to support it properly. If you're tied to WCF as your platform, consider using one of the other styles.