Software testing is almost the "last line of defense" in the software lifecycle between the software vendor and the customer. Testing is the phase that completely validates your architecture, design, and development. If not done properly, testing can carry bugs that can directly impact an organization's revenue. So huge stakes hinge on this part of the lifecycle.

Web Services have now become a mainstream technology, and are steadily reaching maturity as a technology. The proliferation of Web Service technologies can be gauged from the amount of commercial and enterprise implementations that are currently taking place.

The certificate of adoption of Web Services can be gauged from the fact that two of the leading open system technologies, i.e., J2EE and the .NET Framework have now included Web Services in their standard offerings.

With all the attention that Web Services have been getting in the past year, there are remarkably few sources of information about testing Web Services, in particular REST-based Web Services. We'll try to provide some insight into the techniques and strategies for testing REST-based Web Services.

Web Services Styles (SOAP versus REST)
The most popular Web Service implementation styles for most projects would boil down to deciding between SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). Enterprise architect communities have people backing both styles pulling the enterprise projects in one direction or another. The essence of both implementation styles is basically passing XML messages over the wire generally using the HTTP protocol. However, the internal workings of both styles are vastly different from each other.

SOAP-based Web Services
SOAP-based Web Services are based on a set of standard specifications backed by the World Wide Web (W3C) and OASIS consortia. This is the primary reason for the success of this implementation style. It has all the technology vendors agreeing to the basic set of standards that allows technologies to become interoperable. There are also other reasonably mature standards like WS-Security that address the non-functional aspects.

SOAP-based Web Service implementations are based on three important constituents.

The Simple Object Access Protocol
SOAP is a stateless, lightweight, XML-based, one-way message exchange protocol. It basically acts as the medium of communication between the service consumer and the service producer. SOAP specifications define an extensible framework by which application specific information can be exchanged.

SOAP isn't specifically tied to a particular protocol but it's been widely used with HTTP. One of the biggest advantages of SOAP is its ability to handle high levels of complexities. It can deal with basic data types, structs, even arrays.

SOAP doesn't address the semantics of the application-specific messages used for communication between the service consumer and the provider. The SOAP skeleton contains a SOAP envelope with an optional SOAP header element and a compulsory SOAP body element. Any processing error is sent as a SOAP fault in the SOAP message.

The SOAP header element is optional. However it's used to send authentication and session information. Although this doesn't lie within the SOAP protocol, it does provide the flexibility that's exploited by standards like WS-Security. The header element is meant to encapsulate extensions to the message format without having to couple them to the payload or modify the fundamental structure of SOAP.

The SOAP body element is mandatory and contains the application specific information that has to be exchanged between the consumer and the provider. This payload could be a remote procedure call, a XML document that's interchanged.

Web Services Description Language (WSDL)
The Web Service Description Language is an XML-based interface definition and description format used to describe and publish Web Services in a standard manner. The WSDL definition lets consumers identify the location of the service, the request messages that the service requires, and the corresponding output message format that the consumer will get.

WSDL lets service providers expose only their interfaces describing the location and the message formats and completely hiding the underlying implementation. So as long as the service interaction is on the basis of the defined WSDL as the interface, the service provider can keep changing the implementations without it affecting the consumer.

Universal Description Discovery and Integration (UDDI)
The UDDI specifications let businesses publish their services in private and public registries so businesses and people can find and transact with one another easily and dynamically. UDDI lets a business:

• Describe its business and its services
• Discover other businesses that offer desired services
• Integrate with these other businesses.

The three elements are:

• A "white pages" - This contains the basic contact information for each Web Service listing. It generally includes basic information about the company, as well as how to make contact.
• A "yellow pages" - This has more details about the company and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes, and the like to make it easier for companies to search through the listings and find exactly what they want.
• A "green pages" This is what allows someone to bind to a Web Service after it's been found. It includes the various interfaces, URL locations, discovery information, and similar data required to find and run the Web Service.