In the last two posts we looked at the request and response formats and error handling for REST and SOAP.  In this final blog of REST vs. SOAP we want to take a look at a few other important areas that are crucial in choosing one philosophy over the other.   After reading this post you should have enough information to decide whether REST or SOAP is right for your current and future web services.

Support/Community

REST is still young compared to SOAP, resulting in less tools and support. Although REST is young, it is growing fast and there are still many frameworks and tools that support REST.  Many new web services coming out are RESTful, but SOAP and REST are both currently used by many leading companies offering web services.  Companies like Amazon and ebay use SOAP.  Google, Yahoo, Amazon, and ebay use REST.  It is interesting to note, that Google has discontinued their search SOAP API.  Some companies provide both SOAP and REST APIs for their web services, like Amazon.  However, given the choice of using the SOAP or REST API, 85% of the requests made to Amazon are through their REST API

Another aspect of this is the fact that RESTful web services rely almost entirely on  the features of HTTP.  HTTP is the protocol of the web, and as such it has a lot of support, frameworks, and tools.

Performance

The use of a verbose XML format and a required SOAP envelope for each request and response results in larger messages and more bandwidth when using SOAP.  Also there is more overhead in constructing request and reading responses when using SOAP.  Shorter request and responses make REST a great option for developing web services where bandwidth is an important factor, such as mobile devices.  REST has better performance.  According to Amazon, querying Amazon using REST is six times faster than using SOAP.  REST supports caching because it makes use of GET requests, which gives better performance and allows for scalability. SOAP on the other hand uses only POST, which means it cannot cache information on the server side.

Security

Almost all web services desire some level of security beyond simply anonymous HTTP requests.  Both SOAP and RESTful services have robust security options.

SOAP has the WS-Security extension from the WS-* family of extensions.  WS-Security can provide authentication and encryption, and allows for a lot of flexibility in the algorithms/technologies that you can use for each.  The biggest problem with WS-Security is performance.  It has been found to be significantly slower than Transport Layer Security (TLS) and Secure Socket Layer (SSL).

Both SOAP and RESTful services can easily take advantage of SSL/TLS.  Anytime you send a request over HTTPS you're doing just that.  The standard one-way SSL/TLS can be used to encrypt your communications and authenticate the server.  This is the most common form of security on the web.  However, almost all services will also require client authentication, which is lacking from standard SSL/TLS.  It is possible to do two way authentication with SSL/TLS, however it typically isn't practical because every client has to have a certificate signed by a trusted authority.

So how does a RESTful web service authenticate clients.  Well, there are a lot of home grown methods, but the fast growing standard is OAuth.  OAuth is an open standard that allows services to share private resources.  OAuth allows services to hand out tokens instead of usernames and passwords to their resources. Each token grants access to a specific site, for specific resources (e.g. just videos from a specific album) and for a defined duration (e.g. the next 2 hours).  Almost all major service providers are either using or moving towards OAuth.

Clients

It's easier to build a SOAP client.  There are many tools and IDEs that automatically generate a client to consume a SOAP web service using the supplied WSDL.  With REST there isn't an easy way to generate a client, but there are new efforts under way to make it easier to generate REST clients, which will be discussed in a future post (a great example is the Ruby on Rails ActiveResource).  REST clients tend thinner and simpler.  With REST you only need a HTTP client library, but SOAP usually requires extra third party libraries.  REST makes it easier for clients because a resource can be presented in any format you want (ex JSON, XML, HTML, text, etc) and many REST services provide multiple presentations of the same resource.  

SOAP uses endpoints and REST uses URIs.  An endpoint cannot be changed without breaking clients.  URIs can be changed with redirects, which in turn reduces client-server coupling.  When using SOAP XML serialization is usually built in, where as with REST external libraries are required to do XML or JSON serialization.  REST is asynchronous and SOAP is synchronous.  Asynchronous allows for better user experience and performance with clients and also allows clients to handle server errors better.

Development

REST takes full advantage of the features of HTTP, SOAP does not.  REST use of the full features of HTTP gives developers more flexibility and power when building a web service.  REST is easier to test and debug, partly because responses are human readable.  With REST it might be hard to fit some operations on a resource, but in these instances a REST-RPC style service can be used.

The table below shows a summary of the comparison of REST and SOAP and which style of web services it best in certain areas:

	REST	SOAP
Frameworks/Tools		X
Technology Trend	X
Performance	X
Security	X
Flexibility	X
Clients		X
Maintainability	X
HTTP Standards	X

Conclusion

As you can see there are pros and cons for both SOAP and REST.  At BTI we think that REST is best for implementing web services.  That doesn't mean that REST is always the best choice, but for many web services it is.  As with building any software, choose the implementation that best fits your requirements and needs when building a web service.