SOAP stands for Simple Object Access
Protocol. Here the messages are exchanged based based on Xml format. It’s the
format of the data which is sent over the wire in communication.
SOAP message typically looks like:
<?xml
version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/12/soap-envelope">
<soap:Header></soap:Header>
<soap:Body>
<GetOrders xmlns: “http://tempuri.org/” >
<OrderBY>CustomerId</
OrderBY >
</GetOrders>
<soap:Fault> </soap:Fault>
</soap:Body>
</soap:Envelope>
SOAP has been standard protocol for exchanging
message across the systems, technologies and operating systems.
It is quite verbose to send as simple message as
getting Orders for a given person. It uses POST operation for things as simple
as getting orders by customer Id. This could be done with GET operation with
REST which takes less traffic and is faster.
It
stands for Representational State Transfer. This was the term by Roy Thomas in
his Phd dissertation. REST is essentially client server architecture with
following constraints.
In understand REST we need to first
understand the following terms:
Resource:
Resource is anything that can be represented,
called from or to by computer. Essentially the request, response of interaction
of client and server machine is the resources.
Representation:
The way the resources are presented. It can be HTML, XML, JSON or any other
serialized format.
State:
All the information which goes back
and forth between client and server.
Transfer:
Movement of State from client and server and vice versa.
Clients and server can be developed and evolve
independent of each other and they need not be dependent on internal structure
of the system. This means client and server can be replaced by other. Server is
more scalable because it can be designed independent of Client state and
interface.
REST uses
the HTTP verbs for the communication between client and server.
|
HTTP Verb
|
Purpose
|
|
GET
|
Used to
fetch the representation from a resource. The Example showed in section # 1
uses SOAP which is verbose. Using REST and GET verb we can simplify this. See
below table.
|
|
HEAD
|
Does not return the
representation of resource but the headers like content length, date
modified.
|
|
PUT
|
Creates or
update an existing resource like upload of a file to server.
|
|
POST
|
Similar to PUT when creating
the data on server but here server is in control of creating the data. It is
also used in scenario where server needs to initiate any action.
|
|
DELETE
|
It can be
used for deleting a resource from the server.
|
Normally
with RPC or SOAP style of programming we stress more on methods or services
which can be consumed by the client like GetOrdersForCustomer(string
customerId), GetCustomers()
But if the
same URL is with different HTTP verb, it implies different operations with the
server.
If we leverage HTTP verbs
the interfaces can be simplified using:
|
SOAP/RPC Style method
|
REST style Method
|
HTTP Verb used
|
Comment
|
|
PlaceOrder
|
Order/768
|
PUT
|
New order
with # 768
|
|
GetOrders
|
Order/768
|
GET
|
Fetch
order with # 768
|
|
GetOrdersForCustomer
|
Order/Customer/27
|
GET
|
Fetch order
for customer # 27
|
|
GetCustomers
|
Customer
|
GET
|
Fetch all
the customers
|
|
CancelOrder
|
Order/767
|
DELETE
|
Removes
order # 767
|
Here we can
see that variety of operations could be simplified and made less verbose using
REST.
Interaction between client and server is stateless
that means the interaction is highly scalable. Any session specific data is
stored in client which is responsible for passing the data to server on
required request.
HTTP by design supports the cacheability for all the
GET operations. This can also be explicitly or implicitly set on different
browsers using the “Cache-control” header in the response for a given request.
This cacheability helps in reducing the traffic between client and server.
This behavior of the system in which an
operation is called for one or more time, the state of the system does not
change.
Let us go with examples:
2.1.5.1GET:
If we call GET operation for the URL:
http://localhost/ Order/768 more than 1 time it does not change the state of
server.
2.1.5.2PUT:
Though PUT may not look idempotent, but it is also
idempotent. Say we upload a file with
PUT many a times. The state will remain the same as if we had uploaded the file
only once.
2.1.5.3DELETE:
This is
similar to PUT behavior. Say we deleted
some resource using DELETE verb and call it again. On repeated call server may
give an error but the state of system do not change after repeated calls.
2.1.5.4POST:
By design POST is not Idempotent. Here some extra
plumbing work is required on the server side to make sure repeated calls do not
affect the system.
What next? The Service Oriented Architecture
(SOA) has been doing good job but its own limitations. Once we apply REST
principles to SOA we essentially solve many of the problems of SOA. SOA created with REST principles lead to
Resource oriented architecture.
As discussed above we get improvement in
terms of interoperability, scalability, greater availability of bandwidth with
less traffic.