REST vs SOAP
Today i read about REST & SOAP technology .Finally i get some interesting data regarding both technology.
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 (Simple Object Access Protocol) 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:
• 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
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
REST & SOAP both technologies are very viable in today’s market. Both REST and SOAP can solve a huge number of web problems and challenges, and in many cases each can be made to do the developers bidding, which means they can work across the domain.
But the untold story is that both technologies can be mixed and matched. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.
So this means areas that REST works really well for are:
Limited bandwidth and resources; remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
Totally stateless operations; if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.
That covers a lot of solutions in the above three. So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:
Asynchronous processing and invocation; if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
Stateful operations; if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.
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 (Simple Object Access Protocol) 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:
• 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
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
REST & SOAP both technologies are very viable in today’s market. Both REST and SOAP can solve a huge number of web problems and challenges, and in many cases each can be made to do the developers bidding, which means they can work across the domain.
But the untold story is that both technologies can be mixed and matched. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.
So this means areas that REST works really well for are:
Limited bandwidth and resources; remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
Totally stateless operations; if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.
That covers a lot of solutions in the above three. So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:
Asynchronous processing and invocation; if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
Stateful operations; if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.
No comments:
Post a Comment