How REST can use SOAP as protocol?

Question

After reading lots of articles about web services, I got to know that REST can use SOAP as protocol. But I am not getting that, in REST architectural style how and where SOAP can fit?

Answer 1

REST is an architectural style, which if applied correctly allows the decoupling of clients from servers, similar to web browsers which aren't coupled to any specific web server in particular but to the media types they exchange. SOAP on the otherhand is a protocol that describes the syntax expected and its semantics in detail in a W3C recommendation which is usually said to couple clients to the implementation as the contract is usually pregenerated into stub-classes the actual client usually compiled against and interacting with. If the service interface is changing for some reasons older implementations will break with some certainty.

While REST itself is not a protocol itself (it does not define any syntax of messages to be exchange nor their order) it does however require to use other protocols according to the rules outlines by the protocol's standard. Most often REST APIs restrict themselfs to HTTP though. According to Roy Fielding however an application following the RESTful guidelines should not depend on a single communication protocol but support multiple ones. This can be HTTP, SMTP, (S)FTP and other protocols such as SOAP.

One of the main constraints REST imposes is, that APIs must be hypertext driven and support clients in their venture of interacting with the service. This usually goes hand in hand with providing clients with further URIs to interact with and hence allow a client to take further actions to follow a certain goal. The form of the URI isn't the important part (whether it contains a verb or not is not of relevance to a RESTful client) as a client should not analyze the URI itself and thus deduct certain semantics but instead use an accompanying relation name. If the actual URI changes for whatever reason a RESTful client will still be able to interact with the API itself by utilizing the relation name rather than having to interpret the URI itself.

In addition to that, the knowlege of what further actions a client can take are outlined by the media type both server and clients could aggree upon. The media type contains a set of processing instructions which tell the recipient on how to interpret received data.

A REST API response can thus contain a link to a SOAP endpoint which the client could invoke. The content negotiation may tell the client that media type application/soap+xml is required which gives the client a clue that a SOAP 1.2 service is sitting at the URI location. As SOAP services are usually invoked via plain HTTP POST the invocation of the service method itself isn't the actual problem, it's how the client will know what to send and how to format it actually.

Although SOAP clients are often compiled against stub-classes which implement a certain contract expoxed via WSDL, the service itself may be invoked dynamically by interpreting the WSDL contract and mingling the necessary information together as well and thus send a well-formed SOAP message to the respective endpoint. The problem I see here though is, that while the SOAP service endpoint as well as the method to invoke may be defined easily within an URI, the contract description (WSDL) may not necessarily be available by appending a ?wsdl to the end of that URI and thus the WSDL contract needs to be specified in some other way.

Neither HTML nor in JSON HAL define propper attributes in links to instruct clients to use certain WSDL contracts for generating a proper message content. Not sure if profiles can fill this spot actually. I'm also not aware that any other media type or protocol does at the moment. This would therefore require some kind of implicit (or as Fielding named it "out-of-band") information integrated into the client itself which increase the likelihood of failing in case someone publishes SOAP services or their contract differently as the client wont be able to lookup that WSDL any further.

In summary, while REST should be able to coop with SOAP in general, certain work has yet to be done in order to support clients in dynamically assembling the required information needed to issue valid requests to the service IMO. When such support is available I don't see a major issue of sending SOAP messages via RESTful clients. Though, I haven't seen any real-world attempts to invoke SOAP from a (real) RESTful API (though they are actually sparse yet). Usually both are separated. And while there have been attempts to describe REST services similar to SOAP (hint: WADL) this approach was everything but RESTful.