How to access Web Services? Perhaps the two answers you will get are SOAP and REST. Before digging deep of SOAP and REST lets look at first on web service.
What is Web Service?
Web services are part of the Services Oriented Architecture. Web services are used as the model for process decomposition and assembly. I have been involved in discussion where there were some misconception between web services and web API.
The W3C defines a Web Service generally as:
A software system designed to support interoperable machine-to-machine interaction over a network.
Web API also known as Server-Side Web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via the web – most commonly by means of an HTTP-based web server.
Web Service Architecture: SOAP and REST
There are currently two schools of thought in developing Web Services – one being the standards-based traditional approach [ SOAP ] and the other, simpler school of thought [ REST ].
SOAP (Simple Object Access Protocol) and REST (Representation State Transfer) are popular with developers working on system integration based projects. Software architects will design the application from various perspectives and also decides, based on various reasons, which approach to take to expose new API to third party applications.
SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.
REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.
Overview of SOAP and REST along Comparison
SOAP is definitely the heavyweight choice for Web service access. Its characteristicrs are :
- Language, platform, and transport independent
- Mainly a protocol
- It requires significant tooling/middleware support
- Works well in distributed enterprise environments
- SOAP defines its own security.So, its reliable.
- Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP
- Provides significant pre-build extensibility in the form of the WS* standards
- SOAP uses services interfaces to expose the business logic.
- Built-in error handling
- Automation when used with certain language products
- It defines standards to be strictly followed.
- It requires more bandwidth and resource than REST.
- It permits XML data format only.
- SOAP can’t use REST because it is a protocol.
REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:
- No expensive tools require to interact with the Web service
- It is an architectural style
- Minimal tooling/middleware is necessary. Only HTTP support is required
- Smaller learning curve
- Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries
- RESTful web services inherits security measures from the underlying transport. HTTP DELETE can return OK status even if a resource is not deleted. So, not reliable much
- Better suited for point-to-point or where the intermediary does not play a significant role
- REST uses URI to expose business logic.
- Tied to the HTTP transport model
- REST does not define too much standards like SOAP.
- It requires less bandwidth and resource than SOAP.
- Closer to other Web technologies in design philosophy
- It permits different data format such as Plain text, HTML, XML, JSON etc.
- It can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
Deciding Between SOAP and REST
Before spending hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both.
I have found a question on an article regarding choosing between SOAP and REST. The author replied something like this:
“The general rule of thumb I’ve always heard is ‘Unless you have a definitive reason to use SOAP use REST”
Here are a few reasons why REST is almost always the right answer.
Since REST uses standard HTTP it is much simpler in just about ever way. Creating clients, developing APIs, the documentation is much easier to understand and there aren’t very many things that REST doesn’t do easier/better than SOAP.
REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.
REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
It’s a bad argument (by authority), but it’s worth mentioning that Yahoo uses REST for all their services including Flickr and del.ici.ous. Amazon and Ebay provide both though Amazon’s internal usage is nearly all REST source. Google used to provide only SOAP for all their services, but in 2006 they deprecated in favor of REST source. It’s interesting how there has been an internal battle between rest vs soap at amazon. For the most part REST dominates their architecture for web services.
Here are a few reasons you may want to use SOAP.
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services have no need for, in fact they are really only needed in a few “enterprise” scenarios.
Need ACID Transactions over a service, you’re going to need SOAP. While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. Fortunately ACID transactions almost never make sense over the internet. REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps generally don’t need this level of transactional reliability, enterprise apps sometimes do.
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
In summary, The majority of the public services listed offer REST interfaces with some offering both REST and SOAP and very few offer just SOAP. Even though REST seems to be in favor now I believe there are still plenty of areas where SOAP makes sense when you have resources to devote to feeding and caring for it.