Web services can be implemented in various ways. Web services can be
classified as “Big” web services and “RESTful” web services.
Big web services are based on SOAP standard and often contain a WSDL to
describe the interface that the web service offers. The details of the contract
may include messages, operations, bindings, and the location of the web
service.
Big web services includes architecture to address complex non-functional
requirements like transactions, security, addressing, trust, coordination, and
also handles asynchronous processing and invocation.
The SOAP message format and the WSDL interface definition language have
gained widespread adoption in traditional enterprises.
SOAP based Web
Services is a great solution when you need,
§ Asynchronous
processing
§ Reliability
§ Stateful operations
– If the application needs contextual information and conversational state
management then SOAP 1.2 has the additional specification in the WS* structure
to support those things (Security, Transactions, Coordination, etc).
RESTful web
services are based on the way how our web works. Our very own world wide web
(www) – the largest distributed application – is based on an architectural
style called REST – Representational State Transfer. REST is neither a
standard nor a protocol. It is just an architectural style like say for example
client-server architecture (client-server is neither a standard nor a
protocol). Web services following this architectural style are said to be
RESTful Web services.
So what is this REST? According to Roy Fielding who coined this term,
“Representational State Transfer is intended to evoke an image of how a
well-designed Web application behaves: Presented with a network of web pages (a
virtual state-machine), the user progresses through an application by selecting
links (state transitions), resulting in the next page (representing the next
state of the application) being transferred to the user and rendered for their
use.”
In the web, everything is identified by resources. When we type a URL in
the browser we are actually requesting a resource present on the server. A
representation of the resource (normally a page) is returned to the user which
depicts the state of the application. On clicking any other link, the
application transfers state with the new representation of the resource. Hence
the name Representational State Transfer.
REST-style architecture follows this concept and consists of clients and
servers. Clients initiate requests to servers; servers process requests and
return appropriate responses. Requests and responses are built around the
transfer of representations of resources which are identified by URI (Uniform
Resource Identifier).
RESTful web services are based on HTTP protocol and its methods mainly
PUT, GET, POST, and DELETE. These web services are better integrated with HTTP
than SOAP-based services are, and as such do not require XML SOAP messages or
WSDL service definitions.
Because RESTful web services use existing well-known standards (HTTP,
XML, URI, MIME) and have a lightweight infrastructure that allows services to
be built with minimal tooling, developing RESTful web services is inexpensive
and thus has a very low barrier for adoption.
RESTful Web Service
HTTP methods
A RESTful web services
is a collection of resources. For example, consider an office has deployed a
web services to get a list of employees and to get
individual employee data for use with other departments. The web
service makes available a URL to a ‘list of employees’ resource. For example, a
client would use this URL to get the employee list:
http://www.example.com/myoffice/employees
On sending a request to that particular URL, the client would receive
the following document.
<employees xmlns:xlink="http://www.w3.org/1999/xlink">
<employee
xlink:href="http://www.example.com/myoffice/employee/234">234</employee>
<employee
xlink:href="http://www.example.com/myoffice/employee/235">235</employee>
<employee
xlink:href="http://www.example.com/myoffice/employee/236">236</employee>
<employee
xlink:href="http://www.example.com/myoffice/employee/237">237</employee>
</employees>
The above document contains the links to get detailed info about each
employee. This is a key feature of REST. The client transfers from one state to
the next by examining and choosing from among the alternative URLs in the
response document.
To get individual employee information, the web service makes available
a URL to each employee resource. For example, to get employee information whose
id is 237, the client may send a request to the following URL:
http://www.example.com/myoffice/employee/237
And the response document containing the employee information may be as
follows:
<employee xmlns:xlink="http://www.w3.org/1999/xlink">
<id>237</id>
<firstname>xyz</firstname>
<lastname>abc</lastname>
<address>123 ABC St</address>
<salary>3344.56</salary>
</employee>
We have seen the use of HTTP GET method to get the information. In the
same way, we can use the other HTTP methods like POST, PUT and DELETE.
The logical meaning of these HTTP methods for the URL
http://www.example.com/myoffice/employees is as follows,
§ When a HTTP
POST request is sent to the above URL with an employee data, the data
will be added to the employee list.
§ When a HTTP
PUT request is sent to the above URL with a list of employees then the
original list will be modified with this employee list.
§ When a HTTP
DELETE request is sent to the above URL then the entire list of
employees will be deleted.
Similarly for the URL http://www.example.com/myoffice/employee/237 the
actions may be interpreted as follows,
§ When a HTTP
POST request is sent to the above URL, treat the addressed member as a
collection in its own right and create a new entry in it.
o For example
consider a situation where the employee works in a particular department and
the URL http://www.example.com/myoffice/dept/A1205 represents the list of
employees working in department A1205. So a POST request to this URL with
employee data will add an employee data to that particular department.
§ When a HTTP
PUT request is sent to the above URL then modify that particular
employee with the new request data or create if employee does not exist.
§ When a HTTP
DELETE request is sent to the above URL then delete that particular
employee.
In this REST form of communication, the service producer and service
consumer should have a mutual understanding of the context and content (XML)
being passed along. Because there is no WSDL to describe the web services
interface, both parties must agree on the schemas that describe the data being
exchanged and on ways to process it meaningfully.
A RESTful design
may be appropriate when,
§ The web services
are completely stateless.
§ The data that the
web service returns is not dynamically generated and can be cached.
o The caching
infrastructure that web servers provide can be leveraged to improve
performance. However, the developer must take care because such caches are
limited to HTTP GET method for most servers.
§ The service
producer and service consumer have a mutual understanding of the context and
content being passed along.
§ Bandwidth is
particularly important and needs to be limited.
o REST is
particularly useful for limited-profile devices, such as PDAs and mobile
phones, for which the overhead of headers and additional layers of SOAP
elements on the XML payload must be restricted.
§ Web service
delivery or aggregation into existing web sites is to be enabled.
