Web Services are the key point of Integration for different applications belonging to different Platforms, Languages, systems. It wouldn’t be wrong if you call Web-services as the “Rendezvous point of the Business”.
I’ve been using HTTP and SOAP since several years new. REST is rather new. SOAP revolutionized RPC and loose coupling beyond the restrictions posed by earlier protocols. However off late I have been giving APIs and interfaces considerable thought and am leaning a lot more towards simple HTTP based APIs with an XML or JSON response format as opposed to SOAP. Let’s try to discuss all the aspects one by one.
Before we start, Let’s do a basic terminology headsup - SOAP refers to Simple Object Access Protocol HTTP based APIs refer to APIs that are exposed as one or more HTTP URIs and typical responses are in XML / JSON. Response schemas are custom per object REST on the other hand adds an element of using standrdized URIs, and also giving importance to the HTTP verb used (ie GET / POST / PUT etc)Although, in alst ffew years we saw growth of large no. of Web Services, despite that the hype surrounding the SOAP has barely reduced. Internet architects have come up with a surprisingly good argument for pushing SOAP aside: there’s a better method for building Web services in the form of Representational State Transfer (REST).
REST is more of an old philosophy than a new technology. But a realization that came later in technology. Whereas SOAP looks to jump-start the next phase of Internet development with a host of new specifications, the REST philosophy espouses that the existing principles and protocols of the Web are enough to create robust Web services. This means that developers who understand HTTP and XML can start building Web services right away, without needing any toolkits beyond what they normally use for Internet application development.
In a RESTful architecture, the key resources are identified — Can be entities, collections, or anything else the designer seems worthy of having its own URI. The standard methods — in this case, the HTTP verbs — are mapped to resource-specific semantics. All resources implement the same uniform interface. The dimension of content-types, which allows for different representations of resources (e.g. in both XML, HTML, and plain text), as well as the possibility of links to resources in resource representations. Use your imagination — e.g. the GET on /customer/4711 would return a document that contains a link to a specific /order/xyz.
I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and put some light on what REST is.
What is a REST Web Service
Representational State Transfer or REST basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this).
How Popular is REST?
All of the major webservices on the Internet now use REST: Twitter, Yahoo’s web services use REST, others include Flickr, del.icio.us, pubsub, bloglines, technorati, and several others. Both eBay and Amazon have web services for both REST and SOAP.
and SOAP?
SOAP is mostly used for Enterprise applications to integrate wide types and no. of applications and another trend is to integrate with legacy systems, etc. On the Internet side of things — Google is consistent in implementing their web services using SOAP, with the exception of Blogger, which uses XML-RPC.
REST vs SOAP
The companies that use REST APIs haven’t been around for very long, and their APIs came out this year or last year mostly. So REST is definitely In-Vogue for creating a web service. But, lets face it — Use SOAP to wash, and you REST when your tired). The main advantages of REST web services are:
SOAP also has some advantages:
Is SOAP Simple Object access really that simple ? I guess a misnomer! Let’s discuss all the point of comparisons –
API Flexibility & Simplicity
The key to the REST methodology is to write Web services using an interface that is already well known and widely used: the URI. For example, exposing a currency converter service, in which a user enters a currency quote symbol to return a real-time target currency price, could be as simple as making a script accessible on a Web server via the following URI:
http://www.ExampleCurrencyBrokerage.com/convert?=us-dollar&value=100&target=pound
Any client or server application with HTTP support could easily call that service with an HTTP GET command. Depending on how the service provider wrote the script, the resulting HTTP response might be as simple as some standard headers and a text string containing the current price for the given ticker symbol. Or, it might be an XML document.
This interface method has significant benefits over SOAP-based services. Any developer can figure out how to create and modify a URI to access different Web resources. SOAP, on the other hand, requires specific knowledge of a new XML specification, and most developers will need a SOAP toolkit to form requests and parse the results.
Bandwidth Usage – REST is Lighter
Another benefit of the RESTful interface is that requests and responses can be short. SOAP requires an XML wrapper around every request and response. Once namespaces and typing are declared, a four- or five-digit stock quote in a SOAP response could require more than 10 times as many bytes as would the same response in REST.
SOAP proponents argue that strong typing is a necessary feature for distributed applications. In practice, though, both the requesting application and the service know the data types ahead of time; thus, transferring that information in the requests and responses is gratuitous.
How does one know the data types—and their locations in the response—ahead of time? Like SOAP, REST still needs a corresponding document that outlines input parameters and output data. The good part is that REST is flexible enough that developers could write WSDL files for their services if such a formal declaration was necessary. Otherwise, the declaration could be as simple as a human-readable Web page that says, “Give this service an input of some stock ticker symbol, in the format q=symbol, and it will return the current price of one share of stock as a text string.”
Security
Probably the most interesting aspect of the REST vs. SOAP debate is the security perspective. Although the SOAP camp insists that sending remote procedure calls (RPC) through standard HTTP ports is a good way to ensure Web services support across organizational boundaries. However, REST followers argue that the practice is a major design flaw that compromises network safety. REST calls also go over HTTP or HTTPS, but with REST the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request. For example, a GET request can always be considered safe because it can’t, by definition, modify any data. It can only query data.
A typical SOAP request, on the other hand, will use POST to communicate with a given service. And without looking into the SOAP envelope—a task that is both resource-consuming and not built into most firewalls—there’s no way to know whether that request simply wants to query data or delete entire tables from the database.
As for authentication and authorization, SOAP places the burden in the hands of the application developer. The REST methodology instead takes into account the fact that Web servers already have support for these tasks. Through the use of industry-standard certificates and a common identity management system, such as an LDAP server, developers can make the network layer do all the heavy lifting.
This is not only helpful to developers, but it eases the burden on administrators, who can use something as simple as ACL files to manage their Web services the same way they would any other URI.
REST ain’t Perfect
To be wise, REST ain’t perfect. It isn’t the best solution for every Web service. Data that needs to be secure should never be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders (POs), can quickly become cumbersome or even out of bounds within a URI.
And when It comes to attachments, SOAP is a solid winner. SOAP can transport your all text adn BINaries without a glitch. In such cases, SOAP is indeed a solid solution. But it’s important to try REST first and resort to SOAP only when necessary. This helps keep application development simple and accessible.
Fortunately, the REST philosophy is catching on with developers of Web services. The latest version of the SOAP specification now allows certain types services to be exposed through URIs (although the response is still a SOAP message). Similarly, users of Microsoft .NET platform can publish services so that they use GET requests. All this signifies a shift in thinking about how best to interface Web services.
Developers need to understand that sending and receiving a SOAP message isn’t always the best way for applications to communicate. Sometimes a simple REST interface and a plain text response does the trick—and saves time and resources in the process.
Type Handling
SOAP provides relatively stronger typing since it has a fixed set of supported data types. It therefore guarantees that a return value will be available directly in the corresponding native type in a particular platform. Incase of HTTP based APIs the return value needs to be de-serialized from XML, and then type-casted. This may not represent much effort, especially for dynamic languages. Infact, even incase of copmlex objects, traversing an object is very similar to traversing an XML tree, so there is no definitive advantage in terms of ease of client-side coding.
Client-side Complexity (Thinner Clients)
Making calls to an HTTP API is significantly easier than making calls to a SOAP API. The latter requires a client library, a stub and a learning curve. The former is native to all programming languages and simply involves constructing an HTTP request with appropriate parameters appended to it. Even psychologically the former seems like much less effort.
Testing and Troubleshooting
It is also easy to test and troubleshoot an HTTP API since one can construct a call with nothing more than a browser and check the response inside the browser window itself. No troubleshooting tools are required to generate a request / response cycle. In this lies the primary power of HTTP based APIs
Server-side Complexity
Most Programming languages make it extremely easy to expose a method using SOAP. The serialization and deserialization is handled by the SOAP Server library. To expose an object’s methods as an HTTP API can be relatively more challenging since it may require serialization of output to XML. Making the API Rest-y involves additional work to map URI paths to specific handlers and to import the meaning of the HTTP request in the scheme of things. Offcourse many frameworks exist to make this task easier. Nevertheless, as of today, it is still easier to expose a set of methods using SOAP than it is to expose them using regular HTTP.
Caching
Since HTTP based / Rest-ful APIs can be consumed using simple GET requests, intermediate proxy servers / reverse-proxies can cache their response very easily. On the other hand, SOAP requests use POST and require a complex XML request to be created which makes response-caching difficult
VERDICT
In the end I believe SOAP isn’t that simple, it requires greater implementation effort and understanding on the client side while HTTP based or REST based APIs require greater implementation effort on the server side. API adoption can increase considerably if a HTTP based interface is provided. Infact, an HTTP-based API with XML/JSON responses represents the best of both breeds and is easy to implement on the server as well as easy to consume from a client.
