This project is read-only.

support SOAP and REST services - best practices?

Topics: Web Api
Feb 26, 2011 at 1:20 AM

Currently all of our services are SOAP based services (WCF basicHttpBinding).

We are now interested in :

  1.   Providing an additional REST interface to all the existing SOAP services so that we can be accessed via SOAP or REST clients.
  2.   Also, going forward, we want to design our new services keeping in mind that we will expose them using both SOAP and REST interfaces.

As an experiment for case (1), we took two of our very simple existing SOAP services and created a REST version of them (using the WebHTTPBinding) and the REST version is basically a Facade of CRUD operations that delegate to existing code that the SOAP service also uses.

How does this "REST Facade" approach fare for "more complex" existing SOAP services (with too many operations that don't easily fit into the REST CRUD interface) that we also need to expose as REST based services? How does WCF HTTP fare in this situation?



Feb 26, 2011 at 3:21 PM


Creating a service that respects the REST constraints and can also deliver equivalent functionality via SOAP endpoints is an extremely difficult thing to do for all but the most simple cases.  However, I think the problem is just one of terminology.  

I believe what you are trying to do is a HTTP API  (what I like to call a HAPI service) that is a direct equivalent to the SOAP API.  The WCF HTTP libraries are very capable of supporting you in creating HAPI services.

It is critical to realize that you are not trying to achieve a RESTful architeciture.  To do that you would need to implement hypermedia based resources and ensure that clients use that hypermedia to drive their own client state.  I see people who regularly fail to make this distinction between a RESTful service and a HAPI service and they end up getting very confused by the "rules of REST" which seem to be arbitrary and pointless.  

A HAPI service is a perfectly valid approach and can be achieved in parallel with a SOAP interface.  

Feb 26, 2011 at 6:08 PM

Thanks for the reply.

1) For a start, the initial goal is to just support the "HAPI" (HTTP API) interface.

2) But, we are also exploring supporting a RESTful architecture (not just an HTTP API) and let the client drive the client state (a.k.a. application state) using hypermedia. 

Consider this hypothetical scenario:  If all we care about is (1) and not (2)  i.e., provide an HTTP API and not the hypermedia driven application - are there any reasons to prefer WCF HTTP (i.e. currently in wcf.codeplex) to the existing WCF WebHttpBinding available in the .NET frameworks 3.5/4.0?






Feb 26, 2011 at 6:23 PM

Absolutely.  The new WCF HTTP is more flexible in the parameters it accepts in operations.  It allows full, strongly typed, access the HTTP headers.  The HttpOperationHandlers and HttpMessageHandlers allow you to easily apply cross cutting concerns.  The WCF HTTP is far more flexible when it comes to delivering different media types.  The original WCF REST supported XML, JSON and Stream and anything else was tricky.  Integrating with ASP.NET MVC is easier, add DI is easier.  In general the extensibility model is much simpler.

This library is first and foremost a HTTP library, not a REST library.  A RESTful architecture can be built on top, but there is currently very little out of the box to support that, other than a strong HTTP library.