Comparison between SOAP and REST
✅ Paper Type: Free Essay | ✅ Subject: Computer Science |
✅ Wordcount: 3937 words | ✅ Published: 12th Mar 2018 |
- Dickriven Chellemboyee
Table of Contents (Jump to)
Introduction to Software Architecture
Resource-Oriented Architecture
List of Figures
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).
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] |
OASIS, 7 February 2006. [Online]. Available: https://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf. [Accessed 29 September 2014]. |
[2] |
N. M. Josuttis, SOA in Practise, The Art of Distributed System Design, O’Reilly, 2007. |
[3] |
B. Lublinsky, “Is REST the future for SOA?,” InfoQueue, 11 August 2011. [Online]. Available: http://www.infoq.com/articles/RESTSOAFuture. [Accessed 1 October 2014]. |
[4] |
M. M. Roberto Lucchi, 2008. [Online]. Available: http://inspire.ec.europa.eu/reports/ImplementingRules/network/Resource_orientated_architecture_and_REST.pdf. [Accessed 1 October 2014]. |
[5] |
W3C Working Group Note, “Web Services Glossary,” W3C, 2 February 2004. [Online]. [Accessed 2 October 2014]. |
[6] |
M. Chhabra, “REST and SOAP – Web services analogy,” 21 April 2013. [Online]. Available: http://blog.manishchhabra.com/2013/04/rest-and-soap-web-services-analogy/. [Accessed 2014 September 29]. |
[7] |
R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” 2000. [Online]. Available: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf. [Accessed 2014 September 29]. |
[8] |
J. Mueller, “Understanding SOAP and REST Basics,” Software Quality Matters Blog, 8 January 2013. [Online]. Available: http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/. [Accessed 2 October 2014]. |
[9] |
S. Francia, “REST Vs SOAP, The Difference Between Soap And Rest,” Hacking Management, 15 January 2010. [Online]. Available: http://spf13.com/post/soap-vs-rest. [Accessed 1 October 2014]. |
[10] |
M. Fowler, Patterns of Entreprise Application Architecture, Addison-Wesley , 2003. |
[11] |
L. Richardson and S. Ruby, RESTful Web Services, Web services for the real world, O’Reilly, 2007. |
[12] |
D. M. Elkstein, “ROA vs. SOA, REST vs. SOAP,” Learn REST: A Tutorial, 12 February 2008. [Online]. Available: http://rest.elkstein.org/2008/02/roa-vs-soa-rest-vs-soap.html. [Accessed 2014 October 3]. |
[13] |
T. Biske, “REST or SOAP: Which offers the most benefits for mobile applications,” SearchSOA, 23 April 2013. [Online]. Available: http://searchsoa.techtarget.com/answer/REST-or-SOAP-Which-offers-the-most-benefits-for-mobile-applications. [Accessed 1 October 2014]. |
[14] |
S. Dhingra, “REST vs. SOAP: How to choose the best Web service,” SearchSOA, 8 April 2013. [Online]. Available: http://searchsoa.techtarget.com/tip/REST-vs-SOAP-How-to-choose-the-best-Web-service. [Accessed 25 September 2014]. |
[15] |
N. Minar, “Why SOAP sucks,” Some Bits: Nelson’s weblog, 17 November 2006. [Online]. Available: http://www.somebits.com/weblog/tech/bad/whySoapSucks.html. [Accessed 2 October 2014]. |
[16] |
Pingdom, “REST in peace, SOAP,” Pingdom, 15 October 2010. [Online]. Available: http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/. [Accessed 1 October 2014]. |
[17] |
J. Barr, “REST vs. SOAP,” Amazon Web Services, 13 February 2006. [Online]. Available: http://aws.amazon.com/blogs/aws/rest_vs_soap/. [Accessed 2014 Septempber 29]. |
[18] |
T. O’Reilly, “REST vs. SOAP at Amazon,” O’Reilly, 3 April 2003. [Online]. Available: http://www.oreillynet.com/pub/wlg/3005. [Accessed 2014 September 29]. |
[19] |
J. Kulandai, “REST vs SOAP,” Javapapers, 13 November 2012. [Online]. Available: http://javapapers.com/web-service/rest-vs-soap/. [Accessed 2014 September 27]. |
1
Cite This Work
To export a reference to this article please select a referencing stye below:
Related Services
View allDMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: