Web services can be implemented in various ways. Web services can be classified as “Big” web services and “RESTful” web services.
Big 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
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.
- 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.
- 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.
- 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.
