REST vs XML-RPC vs SOAP – pros and cons

What is web services?

Web Services are the key point of Integration for different applications belonging to different Platforms, Languages, systems.

Web services are set of platform independent exposed APIs(functions) which can be used used from remote server over the Internet. There are basically two parties involved in this, one which provides a set of exposed APIs and the another one ,commonly know as web services consumers,is the party which uses the functionality and services provided by web services providing party.

There are different method for providing web services but the most common are SOAP, XML-RPC and REST .

Who’s using REST?

All of Yahoo’s web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.

Who’s using SOAP?

Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.

RPC

Within the world of XML there are two main ways to implement a Remote Procedure Call (RPC) – XML-RPC and SOAP.

XML-RPC

XML-RPC is
“…a spec (http://www.xmlrpc.com/spec) and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.

It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.” – xmlrpc.com

“SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.” – the SOAP spec.

XML-RPC vs. SOAP

Compared to the articture of SOAP, XML-RPC has simpler architecture.

REST

REST is an architectural *style*. RESTful is another term to define REST web services.

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).

It is not necessary to use XML as a data interchange format in REST. The format of information(representation) returned can be in XML, JSON, plain text or even in HTML format.

REST architecture is basically focused on two things : Resources and Interface.

Resources are application’s state and functionality which is represented by a unique URL. The resources share a uniform interface to transfer the state between the client and server.

For example the URL, http://example.com/product/11 can be a resource.Suppose, GET method is used to retrieve product detail from that URL, POST method is used to modify the production information and DELETE method can be used to delete the product from the same URL. Here, the HTTP methods works as a interface to access the resources. All resources implement the same uniform interface. The standard methods — in this case, the HTTP verbs — are mapped to resource-specific semantics.

REST vs SOAP

The main advantages of REST web services are:

• Lightweight – not a lot of extra xml markup
• Human Readable Results
• Easy to build – no toolkits required

SOAP also has some advantages:

• Easy to consume – sometimes
• Rigid – type checking, adheres to a contract
• Development tools

Standards

While REST has its advantages, certainly, standard-less development can, in the long-run, be much more expensive to maintain and manage than standards-focused competing architectures.

REST is standard-less in terms of integration and implementation. There’s no standard that describes even the format of data being exchanged via REST, unlike SOAP. SOAP requires XML, REST is ambivalent – you can do what you want.

When you interact with a SOAP service you know what to expect – it’s always the same: WSDL, XML, SOAP envelopes/headers.

When you interact with a REST service it’s another story. POST? GET? Query string? Data formatted in … what? JSON? XML? TEXT?

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. In case of HTTP based APIs the return value needs to be deserialized from XML, and then type-casted. This may not represent much effort, especially for dynamic languages. In fact, even in case of complex 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.

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.

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.

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.

For consuming web services, its sometimes a toss up between which is easier. For instance Google’s AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon’s REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.

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

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

Read more:

* REST vs. SOAP – The Right WebService – http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/#ixzz1PDKEB98H

* XML-RPC vs. SOAP – http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm

* Web Services and PHP – SOAP vs XML-RPC vs REST – http://roshanbh.com.np/2008/07/web-services-php-soap-vs-xml-rpc-vs-rest.html