WEBSERVICES; SOAP AND REST- A Simple Introduction

In general terms, web services are applications that allow for communication between devices over the internet and are usually independent of the technology or language the devices are built on as they use standardised eXtensible Markup Language (XML) for information exchange. A client or user is able to invoke a web service by sending an XML message and then in turn gets back and XML response message.

There are a number of communication protocols for web services that use the XML format such as Web Services Flow Language(WSFL), Blocks Extensible Exchange Protocol(BEEP) among others. Simple Object Access Protocol(SOAP) and Representational State Transfer (REST) are by far the most used options for accessing web services, however they are not directly comparable as they vary in the sense that SOAP is a communications protocol while REST is a set of architectural principles for data transmission.

This blog post explores SOAP and REST, what they consist of and how they are used. Also it gives guidance on what to look out for when making a decision on which to use in order to meet requirement.

SOAP

SOAP is a messaging protocol for exchanging information between two computers based on XML over the internet. SOAP messages are purely written in XML which is why they are platform and language independent.

A SOAP message contains:

• An Envelope that indicates the start and end of the message
• A Header that includes attributes used to process the message and is an optional element
• A Body that holds the XML data that is to be sent and it cannot be left out
• A Fault which provides error messages when processing and it is an optional element.

Working with SOAP requests and responses could get very complex. Some languages make efficient use of the SOAP shortcuts to reduce the level of complexity and the .Net platform for example hides the XML to a large extent. This is made possible due to the Web Service Definition Language (WSDL). WSDL is an XML file that defines and describes the services that are available in the web service of interest. It describes the naming of services, the specifications and structure of the response sent back. The services in the WSDL are described as a compilation of network ports/endpoints. With the WSDL, the .Net platform is able to auto-generate the proxy classes and functions which can be called from the application.

• The types describe the datatypes the web service use.
• The message defines each operation’s data element
• The portType describes what operations can be done and the messages involved in this operation. This could be one of four types: One way (receives messages but no response), Request-Response (receives request and responds), Solicit-Response (sends request and waits for response) or Notification (sends request, does not require response
• Binding tells the format of data for the type of each port and the protocol.

REST

REST is a web standard architecture that achieves data communication using a standard interface such as HTTP or other transfer protocols that use standard Uniform Resource Identifier (URI). The design is such that each component in a RESTful web service is a resource that can be accessed using standard HTTP methods (if the chosen protocol is HTTP). Resources which can be thought of as objects in the concept of Object oriented programming (OOP) are identified by URIs and the resources are represented in several ways such as JSON, XML, Text etc. though JSON is currently the more favoured choice.

RESTful services have the following properties: Representations, Messages, URIs, Uniform interface, Stateless, Links between resources and caching. A quick look into these properties below using HTTP

1. Representation- resources are represented in different formats as earlier stated and should be a complete representation of the resource.
2. Messages- This is how the client and server interact. Along with the data, messages contain metadata bout the message. When accessing a RESTful resource using HTTP, the commonly used methods are GET (reads a resource), PUT (creates a resource), DELETE (removes a resource) and POST (updates an existing resource)

The figures below show the request and response message formats

The Response Header and Body hold similar information to the request, only that the information is different as it is the server response

1. URIs – Each resource needs at least one URI to identify a resource(s) and the operation is determined by the HTTP verb/action. Hence a URI can be called with different actions.
2. Stateless- Restful web services are stateless and any session state is held on the client not server. This ensures that every client to server request has the necessary information to understand the request and handles each request independently.
3. Links Between Resources- the representation of a resource can have links to other resources.
4. Caching- the data produced when a request is made the first time is stored and used the next time in order to stop regenerating same information for the same request and improves performance. The HTTP headers help to control caching such as age which tracks how long ago the data was fetched from the server, expires date and time the resource representation expires etc.

The above gives an oversight of the six properties of REST and it is important to remember that:

• REST is not coupled to HTTP and is actually protocol independent. It is simply not a mapping of CRUD to the HTTP methods.
• REST makes it relatively easy to integrate with websites and are exposed using XML (one of many ways) for easy consumption

Which is more favourable?

REST was designed to be a more straightforward and easy to implement alternative to heavyweight SOAP for web service access. SOAP functions well in distributed environments where REST assumes a direct point to point communication. Also, SOAP allows for services to describe themselves to clients and in some languages allows for automation. On the other hand, REST is fast as less processing is required, uses less bandwidth and is closer to technologies used in web design.

The choice on which to use is totally dependent on what the requirement. For example, SOAP is a better choice for applications that have complex API so as to describe the services and methods, where formal contracts are agreed for the exchange format, where a guaranteed level of security is required etc. REST will be preferred when limiting bandwidth and resources, when operations are can be stateless and the information can be cached.