Huh? If you could do this, why would you want to?
I thought one of the benefits of REST was to leverage the built-in verbs of HTTP (POST, GET, PUT, etc.) to implement your service’s actions on a resource or object? The parameterized URL plus an completely optional XML payload provides the interface. You don’t need a SOAP interface on top of all that.
If you need strong type checking, to define your own verbs or action, always need to send or receive an XML message that conforms to a pre-defined schema, need support for multiple protocols (HTTP, JMS or even SMTP) or need maximum interoperability from a variety of clients, then use SOAP.
If the verbs that make up HTTP are sufficient for your application, you’ve spent time understanding how to define an effective RESTful service and you don’t need to exchange more complex XML documents, then REST may be just the ticket.
There are numerous SOAP vs REST comparisons around, some even rise above the flame war level to be pretty useful.
However, REST over SOAP would seem to offer the worst of both worlds.
My $0.02,
Mark
#Integration-Server-and-ESB#Universal-Messaging-Broker#webMethods