What is REST & SOAP?

Imagine if every PhD dissertation resulted in

REST API something that changed the world?

Sadly, most end up with a copy on the shelf

at the university library, maybe one in the
author’s office, and little more.

But one, about 16 years ago, led to the

foundation of that thing we spend our lives
on — the Web. Back in 2000, Roy Fielding
presented his doctoral dissertation at
University of California-Irvine on the
representational state transfer.
 Representational state transfer or “REST”
is the software architectural style
designed for distributed systems and,
particularly, the World Wide Web.
REST API
Throughout this REST API tutorial, you will
find the same refrain: REST is not a
protocol or standard.

REST architecture is simply following

certain guidelines for how a well-
designed Web app behaves, in a logical
organization that involves a series of
links — or state transitions — that then
result in the next page —representing
the next state of the application — for
the user.
 REST architecture is inherently simple because it
is based
on seven descriptive properties:
REST API
● Performance - how components interact affects
performance
● Scalability - able to support large numbers of
components
● Simplicity - between interacting interfaces
● Modifiability - of components to meet changing
needs
● Visibility - clear communication between
components
● Portability - of the data-filled code
● Reliability - or resistance to fail at system level
REST API
 Now, with only these limited operations, REST
simply focuses on interactions between data
REST API elements and on what roles components play,
rather than focusing on details like language
and implementations.

REST became the basis on which HTTP

standards and URIs were designed, which were
also developed by Fielding in parallel.

Bringing all three things altogether and REST

easily became the prevailing and accepted
software architectural style for the World Wide
Web — not too shabby for a PhD dissertation!
REST vs SOAP:
Understand The Differences
REST vs SOAP

The age old question: what is the difference

between SOAP and REST APIs, and which one is
right for my project?
REST vs SOAP
The term web API generally refers to both sides
of computer systems communicating over a
network: the API services offered by a server,
as well as the API offered by the client such as a
web browser.
REST vs SOAP
There are several design models for web
services, but the two most dominant are SOAP
and REST.
REST vs SOAP
 Uses Cases SOAP: Uses Cases REST:
REST
- Financial Services
vs - E-commerce payments - A social media profile
- Photos online
- Telecommunication
SOAP - Reading data submitted
online
- Submitting data online
- Reading information
from a server or
database
- Ordering information
 SOAP – Simple Object Access Protocol – is probably
the better known of the two models.

SOAP relies heavily on XML, and together with

schemas, defines a very strongly typed messaging
framework.

Every operation the service provides is explicitly

SOAP defined, along with the XML structure of the request
and response for that operation.

Each input parameter is similarly defined and bound

to a type: for example an integer, a string, or some
other complex object.

All of this is codified in the WSDL. The WSDL is often

explained as a contract between the provider and
the consumer of the service. In programming terms
the WSDL can be thought of as a method signature
for the web service.
 Example:
A sample message exchange looks like the following.

A REQUEST from the client:

SOAP
 Example:
The RESPONSE from the service:

SOAP
 From this example we can see the message was sent
over HTTP. SOAP is actually agnostic of the underlying
transport protocol and can be sent over almost any
protocol such as HTTP, SMTP, TCP, or JMS.

SOAP As was already mentioned, the SOAP message itself

must be XML-formatted. As is normal for any XML
document, there must be one root element: the
Envelope in this case.

This contains two required elements: the Header and

the Body. The rest of the elements in this message
are described by the WSDL.
 The accompanying WSDL that defines the above service looks
like this (the details are not important, but the entire document
is shown here for completeness):

SOAP
 WSDL talks about client features. For example: add, delete,
subtract, etc.

When we go to a restaurant, we see the menu items, this is

WSDL.

Each WSDL document can be broken down into the following

logical parts:

SOAP definition of data types (types) - definition of the type of XML

messages sent and received by the service
data elements (message) - messages used by the web service
abstract operations (portType) - a list of operations that can
be performed with messages
service binding (binding) - the way the message will be
delivered

It is a common misconception that the WSDL is a requirement

for a SOAP service.

SOAP was designed before the WSDL, and therefore the WSDL
is optional. Although it doesn’t have a WSDL.
 REST stands for Representational State Transfer. It
is a stateless communications protocol, most
commonly, HTTP protocol.
REST REST structures in XML, YAML, or REST follows the
object-oriented programming paradigm of noun-
verb.

REST is very data-driven, compared to SOAP, which

is strongly function-driven.
 Your basic REST HTTP requests are: POST, GET, PUT,
and DELETE. Let’s look at an example from the
Swagger Pet Store API:

Sending a GET request to /pet/{petId} would

REST retrieve pets with a specified ID from the database.

Sending a POST request to

/pet/{petId}/uploadImage would add a new image of
the pet.

Sending a PUT request to /pet/{petId} would update

the attributes of an existing pet, identified by a
specified id.

Sending a DELETE request to /pet/{petId} would

delete a specified pet.
 So in a nutshell here is what each of
these request types map to:
REST
(CRUD)
 Example:
A sample message exchange could contain as little
as this -

REST
(CRUD)
 A REST service also has a schema in what is called a WADL –
Web Application Description Language.

The WADL for the above call would look like this:

REST
(CRUD)
REST vs SOAP
RESULTS