Is a Soap Service running on HTTP a REST service

Question

I have a Soap service that is running over http. Is this also a REST service. What are the criteria that would make it a REST service. What are the criteria that would definitively exclude it as a REST service? There are posts (e.g. here) that compare REST and Soap but do not seem to answer this question directly. My answer is: Yes, a Soap service at its functional level is an http request that returns an XML payload where state is not maintained by the server and is therefore a REST service.

Answer 1

Fielding stated in his dissertation:

REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

If you compare the above mentioned properties with Web-browsing, you will find plenty of similarities between both as Fielding just took the concepts which made the Web such a success and applied it onto a more general field, that also should allow applications to "surf the Web".

In order to rightfully call an architecture REST it has to support self-descriptiveness, scalability and cacheability while also respecting and adhering to the rules and semantics outlined by the underlying transport protocol and enforce the usage of well-defined standards, such as media types, link relation names, HTTP operations, URI standards, ...

Self-descriptiveness of a service is utilized by HATEOAS (or hate-us, as I tend to pronounce it, as people like me who see the benefit in REST always have to stress this key-term, which therefore also ended up in its own meme). Via HATEOAS a client is served by the server with all the available "actions" a client could take from the current "state" the client is in. An "action" here is just a link with an accompanying link-relation name a client can use to deduce when to best invoke that URI. The media-type the response was returned for may define what to do with such links. HTML i.e. states that on clicking a link a GET request is triggered and the content of the link is loaded either in the current pane or in a new tab, depending on the arguments the link has. Other media-types may defines something similar or something different at all. The general motto here, though, is: proceeding thru exploring. The interaction model in a REST architecture is therefore best designed as affordance and state machine while the actual service should follow more like a Web site approach where a server is teaching a client, i.e. on how a request has to look like and where to send the request to (similar to HTML forms).

As plenty of Web pages are more or less static and a majority of requests are retrieval focused, the Web heavily relies on caching. The same is generally expected from REST APIs as well, hence the strong requirement for cacheability here, as this could reduce the workload on servers quite notably if proper caching is in place.

By keeping client state away from servers this also allows to add new copies of a service onto new servers located behind a load balancer or new regions and thus increase scalability. A client usually does not care where it retrieves the data from, hence a server might just return a URI pointing to a clone instead of itself.

SOAP on the other hand is RPC, like Java's remote method invocation (RMI) or CORBA, where you have an own interface definition language (IDL) to generate client side stub-code for you, that contains the actual logic on how to transform certain objects into byte streams and how to send them over the wire, where you invoke certain methods.

Where SOAP violates REST constraints is clearly by the lack of caching support as well as out-of-band knowledge that needs to be available before actually using a client. SOAP messages are usually always exchanged as POST operations, which are not cacheable by default. Certain HTTP headers are available to allow intermediary servers to cache the response though SOAP doesn't make use of such and thus lacks general support for it.

A client developed for SOAP endpoint A will most likely also not be interoperable with a further SOAP endpoint B ran by a different company. While one might argue that a Web client also does not know how to process each of the different media-types, browsers usually provide plugin mechanism to load that kind of knowledge into the client. A media type is in addition to that also standardized, at least it should be, and may therefore be usable with plenty of servers (think of Flash-support i.e.). A further problem SOAP services have is, that once anything is changed in the WSDL definition clients not aware of the update will most likely stop to work with that updated service until the client code is updated to work with the latest version of the generated stub classes.

In regards to the XML format exchanged in SOAP: While technically it is doable for a REST service to return a SOAP XML payload, the format itself lacks support of HATEOAS, which is a necessity and not an option. How should a client make further choices based on the received response simply on the content received without any a-priori knowledge of the API itself?

I hope you can see that SOAP lacks support of caching, may have problems with scalability as well as leads to a tight coupling of clients to the actual API. The lack of HATEOAS support by the SOAP message envelop/header/body also does not allow clients to explore the API freely and thus adapt to server changes automatically.

Answer 2

Proper REST services follow the architectural guidelines spelled out in chapter five of Roy Fielding's dissertation. Most people erroneously use the term "REST API" when they really mean "HTTP API". Statelessness is a necessary but not sufficient condition for an API to adhere to the REST architectural guidelines.