Abroad, the REST-versus-SOAP debate seems already settled[1], for both enterprise and consumer applications. In Japan, however, discussions still reveal considerable confusion, almost like the situation around 2009. Today I will address several misconceptions about REST. This is roughly written, but I am asked so often that it can serve as an FAQ. Many points below are explained in greater detail in [2] Service Station: REST in Detail.
Misconception 1: Is REST a protocol for mashups and unsuitable for server-to-server communication?
I struggle to understand where this misconception comes from. Perhaps people hear that REST is HTTP-based and mistakenly equate it with communication between a browser and a Web server.
That is, of course, wrong.
HTTP is extremely convenient for server-to-server communication, just as it is between browsers and Web servers.
Misconception 2: Is REST less secure than SOAP?
The answer is clearly no. Apparently I am not alone in finding this question frustrating; see [2]. The SOAP-related WS-* specifications contain various complex mechanisms, including many security mechanisms. Message-level encryption can protect security even as a message passes among parties. REST, by contrast, is very simple and has no message-encryption mechanism by itself. But the same is true of SOAP: additional WS-* specifications provide it. REST can likewise encrypt a message with JWE, for example. The result is the same.
Operational practice is often the larger factor. Suppose SOAP communication uses XML Encryption. If the encryption mode is CBC, currently the most common, careless error handling creates a security vulnerability. Indeed, many implementations likely have one. Discussing security merely at the SOAP-versus-REST level is fruitless.
Misconception 3: Can REST not be used for transaction processing?
SOAP+WS-* does support advanced distributed transactions that plain REST does not; plain REST requires manual coding. But remember that this benefit comes at the price of tight coupling between 2 endpoints. Modern systems avoid tight coupling and seek alternatives, beginning by reconsidering designs that require atomic distributed transactions.
Misconception 4: SOAP considers interoperability and is more interoperable than REST.
This too is entirely mistaken. As Flanders says in [2], if interoperability means the technical ability to communicate between 2 endpoints, REST is plainly more interoperable. REST uses simple standard technologies, whereas SOAP+WS-* consists of combinations drawn from a vast set of specifications. Even for the same functionality, vendor products may use subtly different specifications or parameters, producing the tragedy that systems connect only when locked into one vendor.
REST basically requires only an HTTP stack, which is supported everywhere—on servers, PCs, and mobile phones. That is a major interoperability advantage.
Misconception 5: WSDL makes SOAP programs easier to write.
WSDL is certainly convenient. Why, then, do many newer REST frameworks lack a WSDL-like facility?
Probably because REST is simple enough not to need one.[3]
Misconception 6: REST is for consumers, while SOAP is for enterprises.
That depends on what “enterprise” means. If, as many say, scalability and application extensibility are defining characteristics, REST is actually better suited to enterprises.
REST’s scalability advantage is evident from its adoption by most large-scale Internet services. RESTful properties—servers need not retain state and can fully exploit HTTP caching—make such services possible.
For application extensibility, organically connecting multiple systems is key, such as combining a system with cloud services. Here too, loosely coupled REST has an advantage over tightly coupled SOAP+WS-*. REST may therefore be better suited to modern business needs.
Misconception 7: So everything should use REST?
No, wait. REST and SOAP+WS-* are merely tools. There is no reason to force REST where it does not fit. If a protocol must be SMTP, for example, SOAP may be more appropriate.
Given this, current best practice in choosing an architecture is:
- First consider whether REST can do it.
- For portions REST cannot handle, consider another method, such as SOAP.
The key is using the right tool in the right place.
[1] These days it is hard even to find someone who wants to use SOAP. Admittedly, directly comparing REST and SOAP is not entirely fair. (Added note: as [2] explains, REST is an architectural style, whereas SOAP is a protocol specification for exchanging data between 2 endpoints. Direct comparison is as fruitless as comparing oranges and apples. This should be clear on the assumption that [2] is also read, but I note it just in case. (11/22))
[2] http://msdn.microsoft.com/ja-jp/magazine/dd942839.aspx
[3] Someone pointed out that the reason may not be “because it is simple enough not to need one,” but “because it is single-purpose enough not to need one.” Fair point. More precisely, perhaps REST decomposes functionality until such a facility is unnecessary. Meanwhile, REST enthusiasts also seem to dislike APIs being hidden. The importance of being able to write requests by hand may influence this design consideration. (Added 11/22)