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.
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:
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.