Whats the best way to offer SOAP/XML + REST/JSON?

Question

I'm creating a general purpose web service that is likely to have a number of different clients, some of which I cannot anticipate at this time.

I already have a nice Java Services API and am looking to provide a web services facade on top of that.

There are great arguments on both sides of the SOAP vs REST debate and it leaves me wondering if there is an easy way to offer both? Not necessarily both at the same time for the same deployment (although that might be nice)...but rather to offer a choice to customers.

Answer 1

Briefly, a single WCF service can offer multiple endpoints for the same service contract. One can be REST, one can be SOAP/XML, one can be TCP/IP+binary.

Answer 2

No, there isn't. SOAP and REST are such different architectures that any framework that proports to make it easy to do both is probably doing a bad job at one of them.

While it's easy to get a set of functions or methods to a WSDL file, SOAP endpoint and so on that's because functions, and SOAP both do basically the same thing with no constraints on what happens. A caller sets up a function call with a number of parameters, fires it and (usually) waits for a response or exception.

Making HTTP endpoints for each method is what some people think is enough to make a RESTful endpoint, but it's not. However, making such HTTP endpoints may still make sense to you, in which case you should go ahead and find a framework that provides this.

The reason my answer starts with "No, there isn't" is because in order to make a REST interface, it's not enough to publish HTTP endpoints, you have to do a lot more work:

• finding media types to reuse
• finding link relations to reuse
• designing your own media types
• defining your own link relations

And there's no framework in the world that will take an arbitrary list of function signatures and do those four things for you. Frameworks allow you to leverage more of HTTP than SOAP does (e.g. OAuth, OpenID, caching, idempotency), but they don't take you all the way to REST.

Answer 3

Yes, you can offer both (and I'd recommend to do it). You can make the decision of which format the response should be in based on either the HTTP Accept header (application/soap+xml vs. application/json) or a custom query parameter (eg http://example.com/myapi?fmt=soap vs. http://example.com/myapi?fmt=json). In any case, you need to have clear default fallback value, if the client has not specified explicitly the desired format for the response.

You might also consider adding REST/POX response format as well, with Atom+optional extensions as your response container. (application/atom+xml and http://example.com/myapi?fmt=atom for the two methods above)

Answer 4

I'd stick with the simple REST solution. Amazon has both REST and SOAP apis for the same services and the REST services are used 85% of the time so if you don't have a specific need for SOAP then I wouldn't implement it.

Answer 5

I'm not really keen on soap web services but googling around i've found that Axis 2 framework from apache not only provides SOAP 1.1 and SOAP 1.2 but also REST/POX with the same business logic implementation. YOu can see more information:

http://ws.apache.org/axis2/