Web Services: SOAP vs.

REST
<author name>
(Student number: <number>)

November 17, 2006

Abstract
It is unanimously believed that Web services will move the Web to its next level by facilitating
application to application interaction over the Internet. However, there is no consensus on how
Web services should be implemented. Software vendors promote involved tool-chains that are
based on SOAP, a W3C standard, as the ideal technology, while a few, but vocal practitioners
claim that a simpler approach, called REST, is often more appropriate.
In this paper, we investigate the fundamental underpinnings of SOAP and REST. Furthermore,
we discuss the applicability of SOAP and REST in different domains.

1 Introduction
To realize the full potential of the nowadays ubiquitous infrastructure of the Web, it is necessary to
extend the scope of the Web beyond human-oriented browsing to include application to application
interactions, which are enabled by programmatic interfaces. These programmatic interfaces are re-
ferred to as Web services [44]. How these programmatic interfaces should be realized is a matter for,
sometimes heated, debates [17]: the debate of SOAP versus REST.
SOAP, a W3C standard, which is backed by all majors vendors (including BEA Systems, IBM,
Microsoft, and SUN), allows the exchange of information between peers in a decentralized, distributed
environment. Moreover, a huge and growing number of protocols [47] enhance SOAP with advanced
features such as reliability, security, and transaction support; or standardize application-oriented pro-
cedures for complex interactions among businesses.
REST, in contrast, is neither a standard nor is it promoted by any vendor. REST, which stands for
Representational State Transfer, has been first described in Roy Fielding’s PhD thesis as an “architec-
tural style for distributed hypermedia systems” [13, p. 4]. Fielding, co-founder of the Apache HTTP
Server project and one principal author of the Hypertext Transfer Protocol [14], attributes the ability
of the Web to sustain its exponential growth to the principles of the REST architectural style [15].
Hence, it is enticing to apply the same principles to building Web services.

2 Representational State Transfer (REST)

2.1 REST as an Architectural Style
Strictly speaking, REST refers to the architectural style that is described by Fielding’s PhD thesis [13].
However, the term is also loosely used to differentiate Web services with sophisticated, SOAP-based
programming interfaces from Web services that simply utilize HTTP and XML (or an equivalent

1
technology) to provide their programming interface; in this sense, the term REST is used [46] even if
those Web services do not fully adhere to the architectural style defined by Fielding. In the following,
we will use the term REST according to the definition given in Fielding’s PhD thesis:

REST provides a set of architectural constraints that, when applied as a whole, em-
phasizes scalability of component interactions, generality of interfaces, independent de-
ployment of components, and intermediary components to reduce interaction latency,
enforce security, and encapsulate legacy systems. [13, p. 75]

The architectural principles defined by REST have been used by Fielding [15] to guide the design and
evolution of the Hypertext Transfer Protocol (HTTP) [14] and Uniform Resource Identifiers (URI) [2]
. Moreover, those principles have become an important part of the general architecture of Web [22].
The principles of the REST architectural style consists of [13, section 5.1]:

• a layered, stateless client/server design with caching of requests;

• a uniform interface between components; and

• optionally: code-on-demand support.

To illustrate above principles and some of their implications that are mentioned in [13, chapter 3
and 5], we describe them in the context of Web applications.

Layered, stateless client/server design and caching

Web applications are partitioned in a client component and a server component where the server
component provides services to the client component. The client component, for example, could be a
Web browser and the server component a Java Servlet running in a Web server, which communicates
with the client over the stateless HTTP protocol.
REST principles mandate that the server is stateless. Therefore, the server cannot hold any session
state, and client requests necessarily contain all information needed to understand a request in isola-
tion; hence, a request can be understood without referring to earlier requests. Furthermore, the server’s
stateless design simplifies its implementation and improves server scalability because the server can
release resources after each request.
REST allows to insert additional layers between client and server in form of intermediary compo-
nents, which relay messages and may provide additional services. As a constraint, layers are visible
only to their immediate neighbours, thus layers behind the immediate neighbours of a component
remain hidden to the component. Consequently, layers are decoupled from each other, and the flex-
ibility to deploy and evolve components is increased. Reverse-proxy servers are an example of an
intermediary component. A reverse-proxy server can be installed in front of a cluster of Web servers
to provide load-balancing or to the secure communication to the client by SSL encryption.
Furthermore, intermediary components may cache the result of requests if staleness of data is not
an issue. Thus by placing a caching component near the client, the latency perceived by the client can
be vastly reduced. An example of a caching component is a (caching) Web proxy.

Uniform interface
Fielding emphasizes that a uniform interface between components is the key principle that differen-
tiates REST from other network-based architectures. To attain a uniform interface, REST defines

2
four constraints: “[...] identification of resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of application state.” [13, p. 82].
We discuss these principles in the following: Any kind of information that is offered by a REST
interface is represented as a resource. Each resource is addressable by a (global) resource identifier.
Furthermore, a resource need not refer to a physical resource, but it can also represent an abstract
concept which, for example, refers to different physical resources over time such as the latest version
of a document.
Components manipulate resources by applying a generic set of operations on the representation
of a resource. Representations consist of data (that is, a sequence of bytes) and meta data. If a
resource has multiple representations such as a document that is available in multiple formats, the
server delivers the representation that best fits the client component.
Exchanged messages must be self-descriptive. Self-descriptive means that a message can be pro-
cessed without referring to previous messages or to data that is transferred outside of the message (for
example, data contained only in the underlying transport protocol).
Finally, REST applications use hypermedia to change application state: A client accesses re-
sources by their representation, which may contain links to (representations of) other resources. By
following those links, the application state is transferred from one state to the next. In other words,
application state is transferred by following links from one representation to another representation:
hence, the name Representational State Transfer.
In the context of a Web application, aforementioned constraints can be illustrated as follows:
Every resource of the Web application is addressable by a Uniform Resource Identifier (URI) [2]. By
issuing a URI together with a (generic) HTTP method, for example GET or POST, a client obtains
the resource’s representation or manipulates a resource. For instance, a client could send the server an
HTTP GET request to retrieve a journal article as an HTML document and an HTTP POST request
to add a comment to the article. Furthermore, the HTML document that represents the article could
contain a list of links to other articles; by following one of those links, the client moves to another
state.

Code-on-demand
Code-on-demand support allows adding functionality to clients as needed; hence, the amount of func-
tionality that must be “hard-wired” in each client can be reduced. This style can be implemented, for
example by the inclusion of ECMAScript or Java applets in a Web page. It is, however, an optional
constraint of REST because code-on-demand support is not always feasible. For instance, download-
ing Java applets may be prevented for security reasons at organizational boundaries by firewalls.

2.2 REST Web Services

REST does not prescribe how Web services should be implemented: In Fielding’s PhD thesis [13],
REST is merely considered as an architectural style that optimizes the characteristics of Internet-scale,
distributed hypermedia systems. Yet, numerous articles on the Web [18, 20, 28, 31] provide guidelines
for building Web services with REST. To illustrate the REST approach to Web services, we present a
conversation between a service consumer and a simple on-line flight booking system that provides a
REST-compliant Web service.

3
Example of a REST Web service
In this example, the service consumer of a flight booking system searches for a flight, books a flight,
modifies the previously made booking, and finally cancels the booking.
To search for flights, the service consumer sends an HTTP GET request where the search criteria
are supplied as a query string. The actual HTTP request is shown below:
GET /flights?departure=London&arrival=Berlin&date=2006-11-13 HTTP/1.1
Host: www.flyhigh.com
The server replies to the HTTP request with a list of matching flights, which is represented by an XML doc-
ument. The response could be in any format; however, XML is usually preferred as it is a wide-spread format
for representing information in human and machine readable manner.
HTTP/1.1 200 OK

<?xml version="1.0"?>
<flight_list xmlns:xlink="http://www.w3.org/1999/xlink">
<flight no="47" time="12:30" xlink:href="http://www.flyhigh.com/flights/47"/>
<flight no="64" time="19:30" xlink:href="http://www.flyhigh.com/flights/64"/>
</flight_list>
The service consumer could follow a link in response to retrieve further details of a flight. However,
we assume that the service consumer directly creates a new booking. To create a new booking the service
consumer sends a POST request to www.flyhigh.com/bookings that carries the flight number and the name
of the customer in the request body:
POST /bookings HTTP/1.1
Host: www.flyhigh.com

<?xml version="1.0"?>
<booking>
<flightno>47</flightno>
<customer>John Do</customer>
</booking>
The server adds the booking to the system’s database and returns the URI of the created resource. Assuming
that the URI of the created booking is www.flyhigh.com/booking/2043, the service consumer sends the
following PUT request to the server in order to correct the spelling of the customer name.
PUT /bookings/2043 HTTP/1.1
Host: www.flyhigh.com

<?xml version="1.0"?>
<updated_elements>
<new_content select="/booking/customer[0]">
<customer>John Doe</customer>
</new_content>
</updated_elements>
Updating resources with REST can be tricky as the expressiveness of a PUT request by itself is limited.
Replacing the complete booking with the body of the PUT request is a simple approach; however, it requires that
the service consumer is able to construct a complete representation of the resource. In general, this constraint
is unacceptable considering that some elements of a representation may be hidden from the service consumer,
or that, the service consumer does not keep track of some elements (for example, the service consumer may
consider the flight number an irrelevant implementation detail).

4
 The problem could be solved by breaking up the resource such that the service consumer is able to provide
complete representations. This solution, however, complicates the service interface; moreover, if elements of
n resources should be updated, n PUT requests must be issued. To avoid those drawbacks, we recommend
to describe the modifications in a particular message type and issue this message as a PUT request. Recog-
nizing the particular message type, the service implementation can apply the modifications to the resource’s
representation.
In the previously shown PUT request, the <updated_elements> element indicates that only parts of the
booking should be updated. The parts that should be updated are determined by an XPath expression. Hence,
this approach allows generically to update any resource that is represented as an XML-document.
When the server receives the PUT request, it updates the customer’s name in system’s database and indi-
cates the successful update by replying with status 204 (No Content) (’No Content’ indicates that the HTTP
response has no message body).
Finally, to cancel the previously modified booking, the service consumer sends a DELETE request to
www.flyhigh.com/booking/2043). The server responds by deleting the booking from the system’s database
and replies with status 204 (No Content) to signal the successful deletion of the booking.

Key traits of REST Web services

The previous example illustrates three key traits of REST-compliant Web services: resource-oriented, stateless
interaction; manipulation of resources by a set of generic operations; and simplicity by leveraging existing Web
standards.
REST Web services are inherently resource-oriented: every entity instance that can be retrieved or manip-
ulated is represented by a resource. Moreover, resources are not hidden from service consumers. Resources
are identified by Uniform Resource Identifiers (URI), which allow service consumers to address each resource.
Additionally, a URI implies the state of a service consumer. Because service providers do not maintain state of
service consumers, the state of a service consumer can be restored by simply applying a previously saved URI.
Service consumers manipulate resources by a set of generic operations consisting of the four HTTP meth-
ods: POST, GET, PUT, and DELETE. These operations are often equated with the Create, Read, Update,
and Delete (CRUD) functions that manipulate records in database systems. The meaning of GET (=read) and
DELETE (=delete) is obvious, the meaning of POST (=create) and PUT (=update), however, is more subtle as
both HTTP methods can create or update resources.
The crucial difference between the two methods is that PUT requests must be idempotent (that means side-
effects must not occur as a request is processed more than one time) while POST requests are non-idempotent
[14]. Thus, a PUT request may create a previously non-existing resource, but if the same request is issued again,
the existing resource must be replaced with the content of the PUT request. The POST method, in contrast,
allows to add new resources with each repeated request. Finally, complying with the semantical constraints
for HTTP methods as defined in the HTTP specification allows network elements to handle caching and partial
network failures intelligently.
REST Web services not only comply with Web standards and the Web’s general architecture [45], they
make deliberate use of existing Web technologies. For example, REST Web services make use of HTTP meth-
ods, HTTP status codes (to signal success or failure of the service provider), HTTP access authentication (to
authenticate service consumers), TLS/SSL (to ensure confidentiality and integrity of representations), XML (to
represent information) and so forth. In summary, REST Web services utilize the existing infrastructure of the
Web to gain simplicity and efficiency.

Limitations of the REST Approach to Web Services

From a practical point of view, the biggest drawback of REST is that it is not even close of becoming a standard
for building Web services. Furthermore, REST completely relies on existing Web standards, which, however,
were originally designed for interactive web applications and thus lack more advanced features, such as reliable
communication or support for distributed transactions; however, these features are, in some cases, indispensable
for automated, batch-oriented systems.

5
 Furthermore, REST provides no formal means to specify REST interfaces, which makes it difficult for
tools to semi-automatically interact with REST Web services or to generate stub code for accessing REST Web
services.
Finally, the restriction that the service interface must expressed in terms of resources and a limited set of
operations (POST, GET, PUT, and DELETE) bears some drawbacks. First, it is difficult to express the interfaces
of activity-oriented applications because an activity-oriented view does not match with the resource-oriented
design of REST [36]. Furthermore, the resource-oriented design of REST interfaces implies that REST Web
services expose a plethora of resources by URIs. We expect that managing those URIs proves difficult for rich
interfaces. Finally, the expressiveness of the PUT request by itself is not sufficient for updating resources as
show by our sample application on page 4.

3 SOAP
3.1 SOAP/WSDL
Introduction
The Simple Object Access Protocol (SOAP) provides an XML-based messaging framework to exchange data
between peers in a decentralized, distributed environment. SOAP Version 1.1 became widely known in 2000
when the W3C published it as a W3C Note [5]. In 2003, SOAP Version 1.2 [42], an updated version which
incorporates modifications that make SOAP more compatible to the general architecture of the Web [23], be-
came a W3C Recommendation. However, SOAP Version 1.1 has remained the most widely adopted version as
indicated by the pending inclusion of SOAP Version 1.2 in the interoperability specifications [48] of WS-I, an
industry organization that fosters Web services interoperability.
While SOAP defines a general framework for message exchange, it is not sufficient for building Web
services. A complementary specification, the Web Services Description Language (WSDL) [9], is needed to
describe precisely the interface of Web services. Don Box, an originators of SOAP, once pointed out that SOAP
would not make sense without WSDL (or some equivalent specification) [4]. A practitioner report from the
finance industry [49] confirms this view. Unsurprisingly, the term SOAP often implies SOAP plus WSDL. In
this paper, the term SOAP generally implies usage of SOAP Version 1.1 with WSDL Version 1.1.

Basics of SOAP
SOAP Version 1.1 defines [5]: the general structure for packaging payload data; rules for representing data types
that are commonly found in programming languages as XML; conventions for modeling Remote Procedure
Calls (RPC) as XML-based messages; and a binding that specifies how SOAP messages should be exchanged
over HTTP.
A soap message is a well-formed XML document. As shown in Figure 1, a SOAP message consists of an
envelope element, zero or more header elements, and a body element, which encloses the payload data. These
elements make up the general structure of SOAP messages.
Header elements carry data that may be processed by SOAP intermediaries, that is, applications that reside
along the message path between the initial sender and the ultimate receiver of a message. For example, a SOAP
intermediary could encrypt the payload of the SOAP message and add a header that informs the receiver of the
used encryption algorithm.
To facilitate the exchange of data between applications, SOAP Version 1.1 defines rules for representing
data types that are commonly found in programming languages as XML (simple types, compound types, and
arrays). However, because XML is a verbose data format, SOAP Version 1.2 substitutes XML by the XML Info
Set [43], an abstract data set for XML documents allowing for more efficient, binary representations.
Aforementioned rules describe how to build messages that applications exchange in order to interact. Be-
sides this message-oriented style, SOAP also supports an RPC-oriented style by providing conventions for
mapping a function and its parameters to a message, and exchanging this message to effect a Remote Procedure
Call(RPC).

6
 Figure 1: Structure of a SOAP message.

Messages may be exchanged over any communication protocol; however, HTTP is the only protocol for
which SOAP defines a binding. A binding specifies how the communication protocol should be employed
to exchange messages. SOAP Version 1.1 always transfers messages by the HTTP POST method even if a
request is free of side-effects. Because HTTP intermediaries must assume that POST requests, may have side-
effects, HTTP intermediaries are unable to cache SOAP requests. To better accommodate for the needs of
HTTP intermediaries, SOAP Version 1.2 introduces the “SOAP Web Method Feature” [41, section 6.4 and 7],
which allows using the HTTP GET method for side-effect free requests. This feature is, however, limited as
the request of a HTTP GET method cannot carry a SOAP message; therefore, the specification only defines the
response to a request but not the request itself. Furthermore, the usage of the HTTP PUT and DELETE methods
are not specified by SOAP.
Above parts of the SOAP specification are described abstractly and orthogonally to allow for independent
evolution of each part. Moreover, the SOAP specification allows implementors to substitute those parts by
other means where appropriate. The only mandatory part of the SOAP specification is the part that specifies the
general structure for packaging payload data as SOAP messages (that is, the SOAP envelope).

Basics of WSDL
The Web Service Description Language (WSDL) [9] is a de-facto standard for describing service interfaces in
XML. To describe a service interface, the provided operations and the messages that are associated with those
operations are detailed in a WSDL document. The elements of a WSDL document are described in Table 1.
The Types, Message, Operation, and Port Type elements describe the logical properties of a service in-
terface by specifying the set of operations and the structure of the messages that may be exchanged between
a service consumer and a service provider when operations are invoked. The deployment details of a service
are indicated by the Binding, Port, and Service element. Deployment details are, for example, the URL of the
service and the wire format of messages. The wire format of messages is determined by the binding of service.
The WSDL specification provides bindings for various protocols including SOAP.
A WSDL document describes the syntactic properties of a Web service interface in a machine-readable
manner, which allows tools to generate code for Web service invokation. In particular, WSDL allows tools
(such Apache Axis, or Sun’s JAX-RPC implementation) to map operations of a Web service to methods in
object-oriented programming languages.

7
 Table 1: Elements of a WSDL document.
WSDL Element Description
Logical service interface:
Types Types is a container element where the data types that occur in the
WSDL are defined as XML Schema types.
Message A message consists of list of named parts; the part’s structure is specified
by a type that is declared in the Types element.
Operation Similar to methods in programming languages, operations define the
actions that a Web service can perform. The Operation element specifies
what messages are send to and received from a Web service when the
operation is invoked.
Port Type Similar to modules in programming languages, a port type groups a set
of related operations.
Mechanics of the service interface:
Binding A binding specifies the protocol for invoking the operations of a spe-
cific port type (module). For example, a binding could declare that op-
erations are invoked in a document-oriented style according to SOAP
Version 1.1.
Port A port defines an endpoint to a port type by adding an address, for ex-
ample a URL, to a binding.
Service A service groups a set of related ports. In other words, it groups a set of
concrete implementations of a port type (module).

3.2 The Web Service Stack

SOAP enables communication among Web services, and WSDL provides the means to describe formally Web
services. These standards form the foundation of Web services; a further standard, Universal Description,
Discovery, and Integration (UDDI), which is published by the OASIS consortium, is also considered to be
essential to Web services [11].
UDDI allows to set up public Web services directories, which allow service providers to publish their Web
services. Service consumers can discover Web services; retrieve their interface description in the WSDL format;
and finally invoke the Web services. This process is illustrated by Figure 2.

Figure 2: Web services roles, operations and artifacts. Source: [26, p. 7]

8
 In addition to the Web service core protocols (SOAP, WSDL, and UDDI), a whole stack of protocols has
been proposed in order to extend the realm of Web services [7, 40, 47]. Figure 3 shows a logical view of the
Web service stack. The layers of the Web service stack address issues such as security, reliable messaging,
transaction support, and business process orchestration. Additionally, researchers are currently working on
the concept of semantic Web services [12, 21], which will (hopefully) allow autonomous agents to interact
intelligently with Web services.

Figure 3: Web services stack. Source: [35, p. 2]

3.3 Limitations of the SOAP Approach to Web Services

SOAP and WSDL do not depend on any other standard except for the XML Infoset, as they make no assump-
tions about the implementations of Web services. Moreover, other standards can customize SOAP/WSDL and
add further services. Hence, SOAP/WSDL seems to have limitless potential.
However, the extensibility of SOAP/WSDL also makes these technologies inherently complex and pro-
vokes a proliferation of overlapping extensions. The perception that SOAP Web services suffer from too many
standards and bear too much complexity is wide-spread [27, 35, 38, 40]. Referring to SOAP Web services,
Mockford reported:
“For some, the apparent lack of stability and coherence in the specifications even raises the
question of the real long-term viability and value of the technology.” [29, p. 1]
Finally, in terms of performance, SOAP cannot compete [25] with efficient middleware technologies such
as CORBA; hence, SOAP is less suitable for high performance, distributed applications.

4 Applicability of SOAP Web Services and REST Web Services

Practical differences
For building simple Web services, the greatest practical difference between SOAP and REST is the level of
toolkit-support and backing by vendors and standardization bodies. Very few tools exists for REST; however,
this is not necessarily a weakness as existing tools are deemed sufficient [28]. In contrast, building SOAP
Web services sans tool-support is impractical because WSDL documents are meant to be processed by software
tools rather than humans [6, p. 7] and because writing code to construct SOAP messages would be tedious
and error prone. Anderson [1] reports that one architect of the SOAP specification admitted to him that it was
the objective of SOAP’s sponsor to ensure that SOAP becomes so complex that it can only be understood and
modified by tools.
Unsurprisingly, a great number of Open-source and commercial tools [37] are offered to develop SOAP-
based Web services. However, whether tools can counter SOAP’s innate complexity is debatable. Dealing with
the complexities of Web services remains a challenge for implementors. To build software solutions that are

9
based on Web services, software developers not only need a general understanding of a plethora of technologies,
they also need to know their intricacies [39].
We believe that differences between SOAP and REST stem from the fact that they target different, though
overlapping domains.

Applicability
REST is intended for Internet-scale, hypermedia systems. Hence, REST is not designed to 1) abstract from
existing technologies; 2) provide rich object-oriented interfaces; or, 3) reduce the application development
effort. Consequently, REST is most appealing for Web applications.
SOAP, in contrast, seems to be less popular for large-scale e-commerce applications [30]. Rather, it demon-
strates potential for sophisticated Business-to-Business (B2B) interactions [50], and it has proved its value as a
technology for Enterprise Application Integration (EAI) [8, 39, 49]. SOAP’s broad scope inherently increases
its complexity as SOAP must account for varied environments with different requirements.
E-commerce and B2B applications are distinguished from EAI applications in that transactions are between
non-trusted parties, which are performed over high-latency networks and occur less frequently [3]. Specifically,
e-commerce applications demand scalability and low-barrier of entry in order to attain a large user-base. REST
Web services can draw from a large share of (Web) developers because REST is easy to understand and can
be used with any development tool alike. Hence, REST satisfies the demands of e-commerce applications very
well.
However, REST is less suited for sophisticated B2B interactions that involve multi-step business trans-
actions between cooperating yet untrusting parties. REST provides no standards to coordinate long-running
multi-step transactions between trading partners; indeed, it even lacks the technical foundations to establish
such standards because it only provides point-to-point communication over HTTP, but does not enable end-to-
end connectivity over multiple hops, which may employ different transfer protocols. Hence, REST is limited.set
of the Web service stack that is build on top of SOAP.
Evidently, SOAP is most appropriate for EAI applications, which typically demand: 1) support for trans-
actions, reliably, and asynchronous communication; 2) longevity by standards backup, vendor backup, and
maximum platform-independence; 3) maintainability due to encapsulation (in form of object-orientation); and
4) rapid development by tools facilitating the development process. These demands are clearly not meet by
REST. Moreover, REST’s strengths, Internet-scalability and simplicity, are less important for EAI solutions
than for Web applications. In particular, the steep learning-curve to master SOAP’s complex tool-set hardly
diminishes its viability as long as the long-term goals of EAI solutions are realized.
Finally, SOAP and REST are not considered to be mutually exclusive [19, 32–34]. With the introduction
of the SOAP Web Method Feature in version 1.2, REST principles can be applied to SOAP Web services .
However, it remains to be seen when (or if) SOAP toolkits will allow for a more REST style implementation of
SOAP Web services.

5 Related Work
In [16], Fielding describes the abstract model of the World Wide Web’s architecture and the principles of REST,
which he developed earlier in his PhD thesis. Interestingly, the paper does not propose REST as a solution for
building Web services.
[24] presents ARRESTED as an extension of REST. ARRESTED includes additional features, for example
asynchronous events and message routing, to accommodate to the needs of decentralized environments.
[51] investigates the driving forces that effect standards adoption and the social dimensions that cause
standards proliferation. Furthermore, they examine the technical difference of SOAP and REST in the context
of Business-to-Business interactions. In contrast, we have assessed the technical differences of SOAP and
REST with a focus on the lowest layer of the Web services stack.
[32] explains, from the viewpoint of a REST proponent, the philosophical differences between the SOAP
and REST approach to Web services. Furthermore, the paper analyses the technical merits of SOAP and REST.

10
 [10] presents web-calculus, a generic messaging model that enhances REST with a capability-based secu-
rity model. Web-calculus allows, for example, confidentiality by URL obfusication.

6 Conclusion
In this paper, we illustrated the fundamentals of REST and SOAP. We clarified the term REST in the meaning
of an architectural style and in the meaning of a simple approach for building Web services using HTTP and
XML. Furthermore, we explained SOAP in terms of a specification for message exchange, but we argued that
SOAP commonly implies SOAP plus WSDL or even the whole stack of Web service protocols.
We showed that REST’s key strengths, Internet scalability and simplicity, makes it particularly appropriate
for e-commerce applications. For Business to business scenarios, REST is suitable if those scenarios are simple.
Solutions for involved scenarios mandate the use of SOAP because those solutions demand the application-
level protocols provided by the Web service stack. Finally, we argued that SOAP is most suited for Enterprise
Application Integration (EAI).

References
[1] Tim Anderson. Ws-* vs the rest, 2006.

[2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform resource identifiers (URI): Generic syntax. Tech-
nical report, 1998. URL http://www.ietf.org/rfc/rfc2396.txt. RFC 2396.

[3] Tim Berners-Lee. Web architecture from 50,000 feet, 1998. URL http://www.w3.org/DesignIssues/
Architecture.html.

[4] Don Box. A brief history of SOAP, 2001. URL http://webservices.xml.com/pub/a/ws/2001/04/

04/soap.html.

[5] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk
Nielsen, Satish Thatte, and Dave Winer. Simple object access protocol (SOAP) 1.1. Technical report,
W3C, 2000. URL http://www.w3.org/TR/2000/NOTE-SOAP-20000508. W3C Note 08 May 2000.

[6] Jan Christian Bryne, , and Anders Lanzen Computational Biology Unit. Web services tutorial, 2006. URL
www.csc.fi/molbio/opetus/embrace/presentations/WS/Compendium.pdf.

[7] Luis Felipe Cabrera, Christopher Kurt, and Don Box. An introduction to the web services architec-
ture and its specifications, 2004. URL http://msdn2.microsoft.com/en-us/library/ms996441(d=
printer).aspx.

[8] Timothy M. Chester. Cross-platform integration with XML and SOAP. IT Professional, 3(5):26–34, 2001.
ISSN 1520-9202.

[9] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web services de-
scription language (WSDL) 1.1. Technical report, 2001. URL http://www.w3.org/TR/2000/
NOTE-SOAP-20000508. W3C Note 15 March 2001.

[10] Tyler Close. web-calculus, 2005. URL http://www.waterken.com/dev/Web/Calculus/.

[11] Francisco Curbera, Matthew Duftler, Rania Khalaf, William Nagy, Nirmal Mukhi, and Sanjiva Weer-
awarana. Unraveling the web services web: An introduction to SOAP, WSDL, and UDDI. IEEE Internet
Computing, 6(2):86–93, 2002.

[12] N. J. Davies, D. Fensel, and M. Richardson. The future of web services. BT Technology Journal, 22(1):
118–130, 2004. ISSN 1358-3948.

11
[13] R. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis,
University of Califormia, Irvine, USA, 2000.

[14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. Hypertext transfer protocol – HTTP/1.1.
RFC 2068, Internet Engineering Task Force, January 1997. URL http://www.ietf.org/rfc/rfc2616.
txt.

[15] Roy T. Fielding and Richard N. Taylor. Principled design of the modern web architecture. In ICSE ’00:
Proceedings of the 22nd international conference on Software engineering, pages 407–416, New York,
NY, USA, 2000. ACM Press. ISBN 1-58113-206-9.

[16] Roy T. Fielding and Richard N. Taylor. Principled design of the modern web architecture. ACM Trans.
Inter. Tech., 2(2):115–150, 2002. ISSN 1533-5399.

[17] Greg Goth. Critics say web services need a REST. IEEE Distributed Systems Online, 5(12), 2004.

[18] Joe Gregorio. How to create a REST protocol, 2004. URL http://www.xml.com/pub/a/2004/12/01/
restful-web.html.

[19] Hugo Haas. Reconciling web services and REST services. In 2005 IEEE European Conference on Web
Services (ECOWS 2005), 2005. URL http://www.w3.org/2005/Talks/1115-hh-k-ecows/. Keynote.

[20] Hao He. Implementing REST web services: Best practices and guidelines, 2004. URL http://www.
xml.com/pub/a/2004/08/11/rest.html.

[21] Michael N. Huhns. Software agents: The future of web services. In Agent Technologies, Infrastructures,
Tools, and Applications for E-Services, volume 2592 of Lecture Notes in Computer Science, pages 1–18.
Springer, 2002.

[22] Ian Jacobs and Norman Walsh. Architecture of the world wide web, volume one. W3C recommendation,
W3C, 2004. URL http://www.w3.org/TR/2004/REC-webarch-20041215/.

[23] Mario Jeckle and Erik Wilde. Identical principles, higher layers: Modeling web services as proto-
col stack, May 25 2004. URL http://citeseer.ist.psu.edu/658108.html;http://dret.net/
netdret/docs/wilde-xmleurope2004.pdf.

[24] Rohit Khare and Richard N. Taylor. Extending the representational state transfer (REST) architectural
style for decentralized systems. In ICSE, pages 428–437. IEEE Computer Society, 2004.

[25] Christopher Kohlhoff, Ben Boyd Rd, Neutral Bay, and Robert Steele. Evaluating SOAP for high per-
formance business applications: Real-time trading systems. In the 12th World Wide Web Conference
(alternate track), pages 872–880, April 01 2003.

[26] Heather Kreger. Web services conceptual architecture, 2001. URL www.ibm.com/software/
solutions/webservices/pdf/WSCA.pdf.

[27] Joe McKendrick. Web services standards: 60 and counting, 2006. URL http://blogs.zdnet.com/
service-oriented/?p=553.

[28] Robert McMillan. A RESTful approach to web services, 2003. URL http://www.networkworld.com/
ee/2003/eerest.html?page=1.

[29] K Mockford. Web services architecture. BT Technology Journal, 22(1):19–26, 2004.

[30] Tim O’Reilly. REST vs. SOAP at Amazon, 2003. URL http://www.oreillynet.com/lpt/wlg/3005.

[31] Paul Prescod. REST and the real world, 2002. URL http://www.xml.com/pub/a/ws/2002/02/20/
rest.html.

12
[32] Paul Prescod. Roots of the REST/SOAP debate. In Extreme Markup Languages 2002,
2003. URL www.idealliance.org/papers/extreme/Proceedings/xslfo-pdf/2002/Prescod01/
EML2002Prescod01.pdf.

[33] Sam Ruby. Rest + soap, 2002. URL http://radio.weblogs.com/0101679/stories/2002/07/20/

restSoap.html.

[34] Xuan Shi. Sharing service semantics using SOAP-based and REST web services. IT Professional, 8(2):
18–24, 2006. ISSN 1520-9202.

[35] Flavio Oliveira Silva and Pedro Frosi Rosa. The quest for the web services stack: a fast trip. In ICWE
’06: Proceedings of the 6th international conference on Web engineering, pages 93–94, New York, NY,
USA, 2006. ACM Press. ISBN 1-59593-352-2.

[36] James Snel. Resource-oriented vs. activity-oriented web services, 2004. URL http://www-128.ibm.
com/developerworks/library/ws-restvsoap/.

[37] Soaprpc.com. Web service implementations, 2006. URL http://www.soaprpc.com/ws_

implementations.html.

[38] Pal Takacsi-Nagy. Illuminating the dark side of web services — BEA’s view, 2003.

[39] S. Tilley, J. Gerdes, T. Hamilton, S. Huang, H. Mueller, D. Smith, and K. Wong. On the business value
and technical challenges of adopting web services. J. Softw. Maint. Evol., 16(1-2):31–50, 2004. ISSN
1532-060X.

[40] Steve Vinoski. WS-nonexistent standards. IEEE Internet Computing, 8(6):94–96, 2004.

[41] W3C. SOAP version 1.2 part 2: Adjuncts. Technical report, 2003. URL http://www.w3.org/TR/2003/
REC-soap12-part2-20030624/. W3C Recommendation 24 June 2003.

[42] W3C. SOAP version 1.2 part 0: Primer. Technical report, 2003. URL http://www.w3.org/TR/2003/
REC-soap12-part0-20030624/. W3C Recommendation 24 June 2003.

[43] W3C. XML information set (second edition). Technical report, 2004. URL http://www.w3.org/TR/
xml-infoset/. W3C Recommendation 4 February 2004.

[44] W3C. Web services activity, 2006. URL http://www.w3.org/2002/ws/.

[45] Norman Walsh and Ian Jacobs. Architecture of the world wide web, volume one. W3C recommendation,
W3C, December 2004. http://www.w3.org/TR/2004/REC-webarch-20041215/.

[46] Wikipedia. Representational state transfer — Wikipedia, the free encyclopedia, 2006. URL http:
//en.wikipedia.org/w/index.php?title=Representational_State_Transfer&direction=
prev&oldid=86781002.

[47] Lawrence Wilkes. The web services protocol stack, 2005. URL http://roadmap.cbdiforum.com/
reports/protocols/index.php.

[48] The Web Services-Interoperability Organization (WS-I). WS-I basic profile version 1.2. Technical report,
2006. URL http://www.ws-i.org/Profiles/BasicProfile-1.2.html. Working Group Draft 2006-
10-03.

[49] Olaf Zimmermann, Sven Milinski, Michael Craes, and Frank Oellermann. Second generation web
services-oriented architecture in production in the finance industry. In OOPSLA ’04: Companion to
the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and
applications, pages 283–289, New York, NY, USA, 2004. ACM Press. ISBN 1-58113-833-4.

13
[50] Olaf Zimmermann, Vadim Doubrovski, Jonas Grundler, and Kerard Hogg. Service-oriented architecture
and business process choreography in an order management scenario: rationale, concepts, lessons learned.
In OOPSLA ’05: Companion to the 20th annual ACM SIGPLAN conference on Object-oriented program-
ming, systems, languages, and applications, pages 301–312, New York, NY, USA, 2005. ACM Press.
ISBN 1-59593-193-7.

[51] Michael zur Muehlen, Jeffrey V. Nickerson, and Keith D. Swenson. Developing web services choreogra-
phy standards - the case of REST vs. SOAP. Decision Support Systems, 40(1):9–29, 2005.

14