Comparison between SOAP and REST

• Dickriven Chellemboyee

Table of Contents (Jump to)

Abstract

Introduction to Software Architecture

Service-Oriented Architecture

Resource-Oriented Architecture

Web service

SOAP

REST

RESTful

Features

SOAP

WS-*

REST

Description Language

WSDL

WADL

Message Format

XML

JavaScript Object Notation

Pros and Cons

Pros of SOAP over REST

Cons of SOAP over REST

Statistics

Real Life Scenario

Conclusion

References

List of Figures

Figure 1: Basic web service

Figure 2: Comparison of web services usage in 2006 and in 2011

Figure 3: Web service with JSON support

Figure 4: New web service with JSON support only

Figure 5: Web service with XML support

Abstract

The main aim of this document is to describe the two common software architectures mostly used in distributed system namely Service-Oriented Architecture and Resource-Oriented Architecture.

The document provides a high-level descriptions of the two software architectures and implementation of those software architectures in the form of web services. Web services allow interaction between applications. Web services are compared and contrasted. The document describes and compares the differences between two types of web services namely SOAP-based web service and REST-based web services.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

Introduction to Software Architecture

Service-Oriented Architecture

Service-Oriented Architecture is a concept aims to improve flexibility by organizing and utilizing nodes of a network [1]. SOA enables the realization of business functionalities by allowing interactions between service providers and service consumers [2]. SOA turn application functions into services which can be consume by other applications over a network. A service describes the business function, self-contained and developed independently. It is defined by a verb, for example: validate user [3]. Services are simply a collection of service with independent methods.

Resource-Oriented Architecture

Resource-oriented architecture is based on the concept of resource. It involves retrieving particular resource instance and it has operations for resource lifecycle management that is to create, read, update and delete resource. Requests are stateless, one request has no connection with the next one. Resources are identified by some address and data included within the request [4].

Web service

A web service is a node of a network accessible interface to application functionalities that is a set of specifications to support interoperable machine-to-machine interaction [2] [5]. The protocol and the format that are used for specific services are defined in those specifications.

Figure 1 shows a basic web service where communication is done between two machines with different operation systems (Windows and Linux) and built with different programming language (Perl and Java).

Figure 1: Basic web service

SOAP

SOAP originally Simple Object Access Protocol, is a set of rules for transferring organised information by the use of web services. SOAP uses XML based for transferring of information in a distributed computing style. SOAP is independent of transport protocol that is it can use any transport protocol for example HTTP, FTP, TCP, UDP, etc. [6]. SOAP has been developed by Microsoft to replace older technologies like CORBA and DCOM

SOAP has an RPC architecture, all web service are message-oriented as HTTP itself is message-oriented, SOAP uses a second envelope inside the HTTP one, that contains XML data which is a description of a RPC call similarly as XML-RPC. This is how SOAP is used to call a remote function or what the return value from a function.

Soap message contains data, the action to perform, the headers and the error details in the case of failure [6]. It uses interfaces and named operations to expose the business logic. It makes use of WSDL to describe the services for client to use and UUDI to advertise their existence [6].

REST

Representational State Transfer is a set of software architectural style for distributed computing system like the World Wide Web. REST is not a protocol. The REST term originated by Roy Fielding in his doctoral dissertation. Roy Fielding is one of the main author of the HTTP protocol specification. The REST term has quickly come in practise in the network community [7]. REST tries to fix the problems with SOAP and provides a truly method of using web services [8]. REST do not require to add another messaging layer to make the transfer to message as oppose to SOAP, REST transfer its message in the HTTP request. It concretes on design rules for making stateless services.

Request and response are built by the transfer of representational of resources. A resource can be essentially the data (object) that may be addressed [6]. Rest recognizes everything as a resource (e.g. User). Each resource has a standard uniform interface, usually an HTTP interface, resources have a name and addresses (URIs). Each resource serves a unique resource since each URL are unique. The different types of operations that can be performed on the resource are done by the different HTTP operations also known as HTTP verbs which are GET, PUT, POST and DELETE. Each resource has one or more representation (JSON, XML, CSV, text, etc.) and the resource representations are transferred across the network [6]. REST allows the creation of ROA but it can be used for both ROA and SOA [3].

RESTful

A RESTful web service is the implementation of REST principles.

HTTP Methods

• GET – getUser – retrieve user information
• DELETE – deleteUser – delete user
• PUT – createUser– create user
• HEAD – getInformation – get meta information
• POST – updateUser – modify user information

Features

SOAP

• Independent of transport protocol (http, ftp, tcp, udp , or named pipes) [6]
• It can perform asynchronous processing and invocation (e.g. JAX-WS)
• It caters for complex operations which require conversional state and contextual information to be maintained.

WS-*

SOAP has a different set of XML “stickers” for its SOAP envelope to provide enhance features to transport its message. These specifications are analogous to HTTP headers. Some of these specifications are described below:

WS-Security

Enterprise security features are provided by the WS-Security standards. It supports identity through intermediaries, also provides the implementation of data integrity and data privacy [9].

WS-ReliableMessaging

Provides reliable messaging that is a successful/retry process built in and provides reliability through soap intermediaries [6]. REST don’t have such feature therefore it should deal with failures by retrying the request.

WS-Trust

Enables issue, renew and validate security tokens.

WS-AtomicTransaction

ACID transactions over a service, REST is not ACID compliant. [9]

REST

• Does not enforce message format as XML or JSON or etc.
• It has a good caching infrastructure which greatly improve performance when the data is not altered often or is not dynamic
• Security is provided by the transport mechanism (SSL), it does not have dedicated concepts for each, it relies predominantly on HTTPS

Description Language

WSDL

The Web Service Description Language is used to describe SOAP interface in XML format. A client can read the file and know exactly which methods it can call and the signatures of the methods. The client can discover services automatically and generate useable client proxy from the WSDL. Most SOAP web services would be very cumbersome to use without it. The WSDL is a machine-readable file that is an application can parse it and knows how to make a service call.

When a service method is called, a POST request is made to the endpoint of the SOAP service which is a single URL for all API call and only POST requests can be made. The signature details are found in the WSDL document.

WSDL version 2 caters for HTTP verbs and it can be useful for documenting RESTful system but it will still very verbose [6].

WADL

The Web Application Description Language is used to describe RESTful web services using XML grammar. A client can load the WADL file and access the functionality of the RESTful web services directly. A WADL is normally less verbose than a WSDL [6]. However since RESTful web services have simpler interfaces, the WADL is not mandatory as opposed to WSDL is to SOAP-based web services.

Message Format

XML

A client requires an XML parser in order to get the information from the XML document. The parsing of XML has to go through different stages (character conversion, lexical analysis and syntactic analysis) before machine can interpret it. The parsing of XML document can take a lot of time since XML is a very verbose document and as the XML document gets longer much more time is taken to parse it.

By replacing XML document with a remote call, there will be a great performance improvement if both sides of the application uses the same binary logic [10].

JavaScript Object Notation

XML is mainly used by most web services for request and response messages but a growing number of web services are using simple data structures (such as numbers, array) serialized as JSON-formatted strings. JSON is expected to be used by a JavaScript call; it is much easier to get a JavaScript data structure from JSON than from XML document. Web browsers don’t have a standard JavaScript interface for XML parser as every browser has a different interface for treating XML document. JSON is normally just a string with some constraints with JavaScript so we can say that JSON string is interoperable on all web browsers. JSON is not attached to JavaScript but an alternative data serialisation to XML. JSON is a simple language-independent method of formatting complex data structures (e.g. array, object, etc.) as string. [11]

Pros and Cons

Pros of SOAP over REST

• Some programming languages provides some shortcuts, reducing the effort needed to build a request and parse the response. For example with .NET technology, the XML is invisible in the user codes [8].
• SOAP has more mature tool support as compare to REST, but this is likely to change in the future [12].
• No native support for SOAP in mobile, even though there are third-party libraries to bring SOAP support, out of the box SOAP support is not available. [13]
• SOAP has a lot of rules thus make it restrictive as compared to REST in the implementation

Cons of SOAP over REST

• It is much simpler to implement REST as compared to SOAP
• The learning curve for REST is smaller than SOAP

• The difficulty lies greatly in the chosen programming language to develop it since some IDE automate the process of generate or referencing the WSDL
• Has support for error handling and the error reporting provides a standard error codes which can be very useful to handle the request and response in the application consuming it.
• SOAP is sometimes considered to be slower than legacy system such as CORBA or ICE because of being too verbose [14]
• While some programming language provides some shortcut to SOAP services, it can be very cumbersome in some others such as JavaScript since an XML structure needs to be created each time a request should be made.
• Distributed environments is best suited for SOAP whereas REST assumes an end-to-end communication
• Has strict set of rules for every stage of implementation while REST provides a concept and less restrictive with the implementation
• Uses strongly type messages, which is a problem for loosely coupled systems. If type signature of an operation is changed, all the clients that was using it will failed [15].
• REST is flexible for data representation, it is easier to understand as they add an element of using standardized URIs and give importance to HTTP verb used. They are lightweight as they don’t need extra XML mark-up [6]. SOAP uses XML structure which make it slow as compare

Statistics

A comparison of web services protocol, styles in 2006 and in 2011 from more than 2000 web services are shown below. It clearly demonstrate that most developers have moved from SOAP to REST. The interest in REST is growing very rapidly whose those in SOAP is declining [16].

Figure 2: Comparison of web services usage in 2006 and in 2011 Figure 3: Web service with JSON support

Figure 4: New web service with JSON support only Figure 5: Web service with XML support

Real Life Scenario

Amazon has SOAP and REST based web services and around 85% of their usage is from the REST-based web service [17]. Although all the beautiful name with SOAP, it is an evidence that developers like the simpler one, that is the REST one [18].

Google has deprecated its SOAP services in favour of a RESTful, resource –oriented service [11]

Nelson Minar, used SOAP-based web service to design Google API for Google search and AdWord, he stated to be wrong for choosing SOAP [15].

Conclusion

SOAP is more useful for complex web service or when there is critical data involve such as banking transaction where retrying the same request can be very critical. If one need a web service up-and-running quickly, it is better to start with REST rather than SOAP. REST is a good option for web service which are meant to be simple, lightweight and fast. However after using one of the web service, it can be almost impossible to change it to the other one. It would be cheaper to re-build the web service.

When making your decision on which type of web service to use, the decision should be which one best meets the requirements with the chosen programming language and in which environment it will be used.

Even though SOAP is meant to be flexible to change, add new features, expanding it. It is not the case in practise by the use of strongly-type as it can make existing client to stop working just by changing the type of method signature.

References

1