HTTP

o HTTP stands for HyperText Transfer Protocol.

o It is a protocol used to access the data on the World Wide Web (www).

o The HTTP protocol can be used to transfer the data in the form of plain text,
hypertext, audio, video, and so on.

Basically, HTTP is a TCP/IP based communication protocol, that is used to deliver data
(HTML files, image files, query results, etc.) on the World Wide Web. The default port is TCP
80, but other ports can be used as well. It provides a standardized way for computers to
communicate with each other. HTTP specification specifies how clients' request data will be
constructed and sent to the server, and how the servers respond to these requests.

Features of HTTP:

o Connectionless protocol: HTTP is a connectionless protocol. HTTP client

initiates a request and waits for a response from the server. When the server
receives the request, the server processes the request and sends back the
response to the HTTP client after which the client disconnects the connection.
The connection between client and server exist only during the current
request and response time only.

o Media independent: HTTP protocol is a media independent as data can be

sent as long as both the client and server know how to handle the data
content. It is required for both the client and server to specify the content
type in MIME-type header.

o Stateless: HTTP is a stateless protocol as both the client and server know
each other only during the current request. Due to this nature of the protocol,
both the client and server do not retain the information between various
requests of the web pages.
o HTTP is a "stateless" protocol which means each time a client
retrieves a Webpage, the client opens a separate connection
to the Web server and the server automatically does not keep
any record of previous client request.
o Maintaining Session Between Web Client And Server
o Let us now discuss a few options to maintain the session between the Web
Client and the Web Server −
o Cookies
o A webserver can assign a unique session ID as a cookie to each web client
and for subsequent requests from the client they can be recognized using the
received cookie.
o This may not be an effective way as the browser at times does not support a
cookie. It is not recommended to use this procedure to maintain the sessions.
o Hidden Form Fields
o A web server can send a hidden HTML form field along with a unique session
ID as follows −
o <input type = "hidden" name = "sessionid" value = "12345">

o This entry means that, when the form is submitted, the specified name and
value are automatically included in the GET or the POST data. Each time the
web browser sends the request back, the session_id value can be used to
keep the track of different web browsers.
o This can be an effective way of keeping track of the session but clicking on a
regular (<A HREF...>) hypertext link does not result in a form submission, so
hidden form fields also cannot support general session tracking.
o URL Rewriting
o You can append some extra data at the end of each URL. This data identifies
the session; the server can associate that session identifier with the data it
has stored about that session.
o For example, with http://tutorialspoint.com/file.htm;sessionid=12345, the
session identifier is attached as sessionid = 12345 which can be accessed at
the web server to identify the client.
o URL rewriting is a better way to maintain sessions and works for the browsers
when they don't support cookies. The drawback here is that you will have to
generate every URL dynamically to assign a session ID though page is a
simple static HTML page.
HTTP Transactions

The above figure shows the HTTP transaction between client and server. The client
initiates a transaction by sending a request message to the server. The server
replies to the request message by sending a response message.

Messages
HTTP messages are of two types: request and response. Both the message types
follow the same message format.
Request Message: The request message is sent by the client that consists of a
request line, headers, and sometimes a body.

The HTTP client sends a request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request modifiers, client
information, and possible body content over a TCP/IP connection.

Response Message: The response message is sent by the server to the client that
consists of a status line, headers, and sometimes a body.
Server
The HTTP server responds with a status line, including the message's protocol
version and a success or error code, followed by a MIME-like message containing
server information, entity meta information, and possible entity-body content.

HTTP - Messages

HTTP is based on the client-server architecture model and a stateless

request/response protocol that operates by exchanging messages across a reliable
TCP/IP connection.
An HTTP "client" is a program (Web browser or any other client) that establishes a
connection to a server for the purpose of sending one or more HTTP request
messages. An HTTP "server" is a program ( generally a web server like Apache
Web Server or Internet Information Services IIS, etc. ) that accepts connections in
order to serve HTTP requests by sending HTTP response messages.
HTTP makes use of the Uniform Resource Identifier (URI) to identify a given
resource and to establish a connection. Once the connection is established, HTTP
messages are passed in a format similar to that used by the Internet mail
[RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045].
These messages include requests from client to server and responses from server
to client which will have the following format:

Message Start-Line
A start-line will have the following generic syntax:
start-line = Request-Line | Status-Line
We will discuss Request-Line and Status-Line while discussing HTTP Request and
HTTP Response messages respectively. For now, let's see the examples of start
line in case of request and response:
GET /hello.htm HTTP/1.1 (This is Request-Line sent by the
client)

HTTP/1.1 200 OK (This is Status-Line sent by the

server)

HTTP – Requests
Request-Line
The Request-Line begins with a method token, followed by the Request-URI and
the protocol version, and ending with CRLF. The elements are separated by space
SP characters.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Message Body
The message body part is optional for an HTTP message but if it is available, then it
is used to carry the entity-body associated with the request or response. If entity
body is associated, then usually Content-Type and Content-Length headers lines
specify the nature of the body associated.
A message body is the one which carries the actual HTTP request data (including
form data and uploaded, etc.) and HTTP response data from the server ( including
files, images, etc.). Shown below is the simple content of a message body:
<html>
<body>

<h1>Hello, World!</h1>

</body>
</html>
//--------------------------------------------------------------------------------------------------------------------------------//

What is idempotency in HTTP

methods?
Idempotency is a property of HTTP methods.

A request method is considered idempotent if the intended effect on the

server of multiple identical requests with that method is the same as
the effect for a single such request. And it's worthwhile to mention that
idempotency is about the effect produced on the state of the resource on the
server and not about the response status code received by the client.

To illustrate this, consider the DELETE method, which is defined as

idempotent. Now consider a client performs a DELETE request to delete a
resource from the server. The server processes the request, the resource
gets deleted and the server returns 204. Then the client repeats the
same DELETE request and, as the resource has already been deleted, the
server returns 404.

Despite the different status code received by the client, the effect produced
by a single DELETE request is the same effect of multiple DELETE requests to
the same URI.

Finally, requests with idempotent methods can be repeated automatically if a

communication failure occurs before the client is able to read the server's
response. The client knows that repeating the request will have the same
intended effect, even if the original request succeeded, though the response
might be different.

Idempotency has nothing to do with the result (=Server Response), but with
the server-state after one or multiple calls.

Let's say you want to delete a resource on the server by calling

DELETE /resource/123
The call may return with a HTTP-Response 200 OK and the deleted resource as
payload in the first place. In a second call, the Response will be 204
NO_CONTENT as the resource has already been deleted by the first call.

After each request the server-state is the same, therefore idempotency is

fulfilled. The HTTP/1.1 says nothing about the response
Request Header Fields
We will study General-header and Entity-header in a separate chapter when we will
learn HTTP header fields. For now, let's check what Request header fields are.
The request-header fields allow the client to pass additional information about the
request, and about the client itself, to the server. These fields act as request
modifiers.Here is a list of some important Request-header fields that can be used
based on the requirement:
 Accept-Charset
 Accept-Encoding
 Accept-Language
 Authorization
 Expect
 From
 Host
 If-Match
 If-Modified-Since
 If-None-Match
 If-Range
 If-Unmodified-Since
 Max-Forwards
 Proxy-Authorization
 Range
 Referer
 TE
 User-Agent
You can introduce your custom fields in case you are going to write your own
custom Client and Web Server.

Examples of Request Message

Now let's put it all together to form an HTTP request to fetch hello.htm page from
the web server running on tutorialspoint.com
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Here we are not sending any request data to the server because we are fetching a
plain HTML page from the server. Connection is a general-header, and the rest of
the headers are request headers. The following example shows how to send form
data to the server using request message body:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string
Here the given URL /cgi-bin/process.cgi will be used to process the passed data
and accordingly, a response will be returned. Here content-type tells the server
that the passed data is a simple web form data and length will be the actual length
of the data put in the message body. The following example shows how you can
pass plain XML to your web server:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>

<string xmlns="http://clearforest.com/">string</string>

HTTP - Responses

Message Status-Line
A Status-Line consists of the protocol version followed by a numeric status code
and its associated textual phrase. The elements are separated by space SP
characters.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP Version
A server supporting HTTP version 1.1 will return the following version information:
HTTP-Version = HTTP/1.1
Status Code
The Status-Code element is a 3-digit integer where first digit of the Status-Code
defines the class of response and the last two digits do not have any categorization
role. There are 5 values for the first digit:

S.N. Code and Description

1 1xx: Informational

It means the request was received and the process is continuing.

2 2xx: Success

It means the action was successfully received, understood, and accepted.

3 3xx: Redirection

It means further action must be taken in order to complete the request.

4 4xx: Client Error

It means the request contains incorrect syntax or cannot be fulfilled.

5 5xx: Server Error

It means the server failed to fulfill an apparently valid request.

HTTP - Methods
GET Method
A GET request retrieves data from a web server by specifying parameters in the
URL portion of the request. This is the main method used for document retrieval.
The following example makes use of GET method to fetch hello.htm:
GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
The server response against the above HEAD request will be as follows:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEAD Method
The HEAD method is functionally similar to GET, except that the server replies with
a response line and headers, but no entity-body. The following example makes use
of HEAD method to fetch header information about hello.htm:
HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
The server response against the above HEAD request will be as follows:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
You can notice that here server the does not send any data after header.

POST Method
The POST method is used when you want to send some data to the server, for
example, file update, form data, etc. The following example makes use of POST
method to send a form data to the server, which will be processed by a process.cgi
and finally a response will be returned:
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

The server side script process.cgi processes the passed data and sends the
following response:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>
PUT Method
The PUT method is used to request the server to store the included entity-body at a
location specified by the given URL. The following example requests the server to
save the given entity-body in hello.htm at the root of the server:
PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

The server will store the given entity-body in hello.htm file and will send the
following response back to the client:
HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>The file was created.</h1>
</body>
</html>
DELETE Method
The DELETE method is used to request the server to delete a file at a location
specified by the given URL. The following example requests the server to delete the
given file hello.htm at the root of the server:
DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
The server will delete the mentioned file hello.htm and will send the following
response back to the client:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

The Status-Code element in a server response, is a 3-digit integer where the first digit of the
Status-Code defines the class of response and the last two digits do not have any
categorization role. There are 5 values for the first digit:

S.N. Code and Description

1 1xx: Informational

It means the request has been received and the process is continuing.

2 2xx: Success

It means the action was successfully received, understood, and accepted.

3 3xx: Redirection

It means further action must be taken in order to complete the request.

4 4xx: Client Error

 It means the request contains incorrect syntax or cannot be fulfilled.

5 5xx: Server Error

It means the server failed to fulfill an apparently valid request.

HTTP status codes are extensible and HTTP applications are not required to understand the
meaning of all the registered status codes. Given below is a list of all the status codes.

1xx: Information
Message Description

100 Continue Only a part of the request has been received by the server, but as long as it has not been
rejected, the client should continue with the request.

(The HTTP 100 Continue informational status response code indicates that
everything so far is OK and that the client should continue with the request or ignore
it if it is already finished)

101 Switching The server switches protocol.

Protocols
(The HTTP 101 Switching Protocols response code indicates the protocol
the server is switching to as requested by a client which sent the message including
the Upgrade request header.

Switching protocols might be used with WebSockets.

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

2xx: Successful
Message Description
200 OK The request is OK.

(The HTTP 200 OK success status response code indicates that the
request has succeeded. A 200 response is cacheable by default.

The meaning of a success depends on the HTTP request method:

 GET:
The resource has been fetched and is transmitted in the
message body.
 HEAD: The representation headers are included in the response
without any message body
 POST: The resource describing the result of the action is transmitted
in the message body
 TRACE: The message body contains the request message as
received by the server.
The successful result of a PUT or a DELETE is often not a 200 OK but a 204 No
Content (or a 201 Created when the resource is uploaded for the first time).

201 Created The request is complete, and a new resource is created .( 201 Created success
status response code indicates that the request has succeeded and has led to the
creation of a resource. The new resource is effectively created before this
response is sent back and the new resource is returned in the body of the
message, its location being either the URL of the request, or the content of
the Location header.)

202 Accepted The request is accepted for processing, but the processing is not complete.

203 Non- The information in the entity header is from a local or third-party copy, not from the
authoritative original server.
Information

204 No Content A status code and a header are given in the response, but there is no entity-body in
the reply. (The HTTP 204 No Content success status response code
indicates that a request has succeeded, but that the client doesn't need to
navigate away from its current page.

This might be used, for example, when implementing "save and continue
editing" functionality for a wiki site. In this case a PUT request would be
used to save the page, and the 204 No Content response would be sent to
indicate that the editor should not be replaced by some other page.)
205 Reset The browser should clear the form used for this transaction for additional input.
Content

206 Partial The server is returning partial data of the size requested. Used in response to a request
Content specifying a Range header. The server must specify the range included in the response
with the Content-Range header.

3xx: Redirection
Message Description

300 Multiple A link list. The user can select a link and go to that location. Maximum five addresses .
Choices

301 Moved The requested page has moved to a new url .

Permanently

302 Found The requested page has moved temporarily to a new url .

303 See Other The requested page can be found under a different url .

304 Not Modified This is the response code to an If-Modified-Since or If-None-Match header, where the
URL has not been modified since the specified date.

305 Use Proxy The requested URL must be accessed through the proxy mentioned in
the Location header.

306 Unused This code was used in a previous version. It is no longer used, but the code is
reserved.

307 Temporary The requested page has moved temporarily to a new url.
Redirect
4xx: Client Error
Message Description

400 Bad Request The server did not understand the request.( 400 Bad Request response
status code indicates that the server cannot or will not process the request due
to something that is perceived to be a client error (e.g., malformed request
syntax)

401 Unauthorized The requested page needs a username and a password.( The HTTP 401
Unauthorized client error status response code indicates that the
request has not been applied because it lacks valid authentication
credentials for the target resource.

This status is sent with a WWW-Authenticate header that contains

information on how to authorize correctly.)

402 Payment You can not use this code yet.

Required

403 Forbidden Access is forbidden to the requested page.( The HTTP 403 Forbidden client
error status response code indicates that the server understood the
request but refuses to authorize it.

This status is similar to 401, but in this case, re-authenticating will make
no difference. The access is permanently forbidden and tied to the
application logic, such as insufficient rights to a resource.)

404 Not Found The server can not find the requested page. (The HTTP 404 Not Found client
error response code indicates that the server can't find the requested
resource. Links that lead to a 404 page are often called broken or dead
links and can be subject to link rot.

A 404 status code does not indicate whether the resource is temporarily
or permanently missing. But if a resource is permanently removed,
a 410 (Gone) should be used instead of a 404 status)
405 Method Not The method specified in the request is not allowed.
Allowed

406 Not Acceptable The server can only generate a response that is not accepted by the client.

407 Proxy You must authenticate with a proxy server before this request can be served.
Authentication
Required

408 Request The request took longer than the server was prepared to wait.
Timeout

409 Conflict The request could not be completed because of a conflict.

(Conflicts are most likely to occur in response to a PUT request. For example,
you may get a 409 response when uploading a file which is older than the one
already on the server resulting in a version control conflict)

410 Gone The requested page is no longer available .

411 Length The "Content-Length" is not defined. The server will not accept the request without
Required it .

412 Precondition The pre condition given in the request evaluated to false by the server.
Failed

413 Request Entity The server will not accept the request, because the request entity is too large.
Too Large

414 Request-url The server will not accept the request, because the url is too long. Occurs when you
Too Long convert a "post" request to a "get" request with a long query information .

415 Unsupported The server will not accept the request, because the mediatype is not supported .
Media Type
 416 Requested The requested byte range is not available and is out of bounds.
Range Not
Satisfiable

417 Expectation The expectation given in an Expect request-header field could not be met by this
Failed server.

5xx: Server Error

Message Description

500 Internal Server The request was not completed. The server met an unexpected condition.
Error
(The server has encountered a situation it doesn't know how to handle.)

501 Not The request was not completed. The server did not support the functionality
Implemented required.

(The request method is not supported by the server and cannot be handled.
The only methods that servers are required to support (and therefore that must
not return this code) are GET and HEAD.)

502 Bad Gateway The request was not completed. The server received an invalid response from the
upstream server.

503 Service The request was not completed. The server is temporarily overloading or down.
Unavailable

504 Gateway The gateway has timed out.

Timeout

505 HTTP Version The server does not support the "http protocol" version.
Not Supported

Previous Page Print Page

Next Page

Advertisements
WEBSERVICES

A Web Service is can be defined by following ways:

o It is a client-server application or application component for

communication.
o The method of communication between two devices over the
network.
o It is a software system for the interoperable machine to machine
communication.
o It is a collection of standards or protocols for exchanging
information between two devices or application.
o Let's understand it by the figure given below:

o As you can see in the figure, Java, .net, and PHP applications can
communicate with other applications through web service over the
network. For example, the Java application can interact with
Java, .Net, and PHP applications. So web service is a language
independent way of communication.
  A web service is any piece of software that makes itself available over the
internet and uses a standardized XML messaging system. XML is used to
encode all communications to a web service. For example, a client invokes a
web service by sending an XML message, then waits for a corresponding
XML response. As all communication is in XML, web services are not tied to
any one operating system or programming language—Java can talk with
Perl; Windows applications can talk with Unix applications.
 Web services are XML-based information exchange systems that use the
Internet for direct application-to-application interaction. These systems can
include programs, objects, messages, or documents.
 A web service is a collection of open protocols and standards used for
exchanging data between applications or systems. Software applications
written in various programming languages and running on various platforms
can use web services to exchange data over computer networks like the
Internet in a manner similar to inter-process communication on a single
computer. This interoperability (e.g., between Java and Python, or Windows
and Linux applications) is due to the use of open standards.

How Does a Web Service Work?

A web service enables communication among various applications by using open
standards such as HTML, XML, WSDL, and SOAP. A web service takes the help of
−
 XML to tag the data
 SOAP to transfer a message
 WSDL to describe the availability of service.
You can build a Java-based web service on Solaris that is accessible from your
Visual Basic program that runs on Windows.
You can also use C# to build new web services on Windows that can be invoked
from your web application that is based on JavaServer Pages (JSP) and runs on
Linux.

 The client program bundles the account registration information into a SOAP
message.
 This SOAP message is sent to the web service as the body of an HTTP
POST request.
 The web service unpacks the SOAP request and converts it into a command
that the application can understand.
 The application processes the information as required and responds with a
new unique account number for that customer.
  Next, the web service packages the response into another SOAP message,
which it sends back to the client program in response to its HTTP request.
 The client program unpacks the SOAP message to obtain the results of the
account registration process.

Why Web Services?

Exposing the Existing Function on the network

Interoperability
Standardized Protocol
Low Cost Communication

KEY DIFFERENCE
 SOAP stands for Simple Object Access Protocol whereas REST
stands for Representational State Transfer.
 SOAP is a protocol whereas REST is an architectural pattern.
 SOAP uses service interfaces to expose its functionality to client
applications while REST uses Uniform Service locators to access to
the components on the hardware device.
 SOAP needs more bandwidth for its usage whereas REST doesn’t
need much bandwidth.
 Comparing SOAP vs REST API, SOAP only works with XML formats
whereas REST work with plain text, XML, HTML and JSON.
 SOAP cannot make use of REST whereas REST can make use of
SOAP.

SOAP Introduction
Exchanging data between applications is crucial in today's networked
world. But data exchange between these heterogeneous applications
would be complex. So will be the complexity of the code to accomplish this
data exchange.
One of the methods used to combat this complexity is to use XML
(Extensible Markup Language) as the intermediate language for
exchanging data between applications.

Every programming language can understand the XML markup language.

Hence, XML was used as the underlying medium for data exchange.

But there are no standard specifications on use of XML across all

programming languages for data exchange. That is where SOAP software
comes in.

SOAP was designed to work with XML over HTTP and have some sort of
specification which could be used across all applications.

Advantages of SOAP
SOAP is the protocol used for data interchange between applications.
Below are some of the reasons as to why SOAP is used.

 When developing SOAP based Web services, you need to have

some of language which can be used for web services to talk with
client applications. SOAP is the perfect medium which was
developed in order to achieve this purpose. This protocol is also
recommended by the W3C consortium which is the governing body
for all web standards.
 SOAP is a light-weight protocol that is used for data interchange
between applications. Note the keyword 'light.' Since SOAP
programming is based on the XML language, which itself is a light
weight data interchange language, hence SOAP as a protocol that
also falls in the same category.
 SOAP is designed to be platform independent and is also designed
to be operating system independent. So the SOAP protocol can work
any programming language based applications on both Windows
and Linux platform.
 It works on the HTTP protocol –SOAP works on the HTTP protocol,
which is the default protocol used by all web applications. Hence,
there is no sort of customization which is required to run the web
services built on the SOAP protocol to work on the World Wide Web.
SOAP Building Blocks
The SOAP specification defines something known as a "SOAP message"
which is what is sent to the web service and the client application.

The SOAP message is nothing but a mere XML document which has the
below components.

 An Envelope element that identifies the XML document as a SOAP

message – This is the containing part of the SOAP message and is
used to encapsulate all the details in the SOAP message. This is the
root element in the SOAP message.
 A Header element that contains header information – The header
element can contain information such as authentication credentials
which can be used by the calling application. It can also contain the
definition of complex types which could be used in the SOAP
message. By default, the SOAP message can contain parameters
which could be of simple types such as strings and numbers, but can
also be a complex object type.
 RESTful Web Services Tutorial

RESTful Web Services are basically REST Architecture based Web Services. In
REST Architecture everything is a resource. RESTful web services are light weight,
highly scalable and maintainable and are very commonly used to create APIs for
web-based applications. This tutorial will teach you the basics of RESTful Web
Services and contains chapters discussing all the basic components of RESTful
Web Services with suitable examples.

What is REST architecture?

REST stands for REpresentational State Transfer. REST is web standards based
architecture and uses HTTP Protocol. It revolves around resource where every component is
a resource and a resource is accessed by a common interface using HTTP standard
methods.

In REST architecture, a REST Server simply provides access to resources and

REST client accesses and modifies the resources. Here each resource is identified
by URIs/ global IDs. REST uses various representation to represent a resource like
text, JSON, XML. JSON is the most popular one.
HTTP methods
Following four HTTP methods are commonly used in REST based architecture.
 GET − Provides a read only access to a resource.
 POST − Used to create a new resource.
 DELETE − Used to remove a resource.
 PUT − Used to update a existing resource or create a new resource.

62
Although REST is stateless, it has state transfer in its name. It's a little bit
confusing to everyone.

Stateless

When you open a web page in the browser, you will act as a service
consumer and the www server will act as a service provider to serve you with
a webpage. If it is a normal connection, the client and the server will both
perform a handshake and initiate a session (called a TCP connection).

After that, based on the server's and client's behavior, the state will change
to either ESTABLISHED, IDLE, TIMEOUT, etc. But in REST, we are using the
HTTP protocol which is a stateless, meaning the server will not store any
session information about the client. The client is responsible for sending all
of the details required by the server to get serviced, meaning when we
invoke the URI http://somedomain:8080/senthil/services/page1 from the server, it
has enough details about the client to serve page1 fully.

State Transfer

Using the same example, when you open a web page using some URL to view
an image file (RESOURCE) on the server,the www server will show you (the
client) the image in some format i.e a REPRESENTATION of the RESOURCE
(image file).

During this process, the constant resource state of the server (i.e. the state
of the image file which is stored in the server database) will be represented
to client in an understandable format i.e. application state of the client. So,
the resource state will remain constant in respect to clients, and only the
representation of the resource will change, which in turn would change the
application state.

Finally, the representation of the resource (how the image is displayed to the
client), which implicitly changes the state of both the server and the client is
called REST.