REST vs. SOAP: Comparison and Practical SOAtest Examples

This section of the tutorial is dedicated to exploring the fundamentals of REST and SOAP web services, along with an in-depth comparison between the two. It provides guidance on how to effectively work with these protocols within Parasoft SOAtest. Whether you’re a newcomer looking to understand the basics or an experienced user seeking to optimize your testing processes, this tutorial equips you with the knowledge and practical skills needed to navigate REST and SOAP services within the SOAtest environment.

Please note that although this tutorial focuses on REST and SOAP-based services only, Parasoft SOAtest offers the most extensive message format and protocol support on the market, including GraphQL, gRPC, and MQ messaging. For a full list of supported technologies, refer to the Parasoft website (https://www.parasoft.com/products/parasoft-soatest/technical-specs/).

=> Check out the complete SOATest Tutorial Series here.

REST

What Is REST Service?

REST, an abbreviation for representational state transfer, is a “stateless” architectural style that employs various methods or HTTP verbs to manage requests and responses.

In REST, requests and responses are typically exchanged in multiple formats, including JSON (JavaScript Object Notation), XML or plain text. REST often exhibits superior performance compared to SOAP, largely due to the lightweight nature of JSON used in REST request payloads.

One of the key characteristics of REST is its statelessness. Each method or request is processed independently, without relying on prior interactions or retaining session state. This statelessness is a defining feature of REST architecture.

Key Features of REST Architecture:

1. Simplicity: REST services are simple to understand and implement, using standard HTTP methods.
2. Statelessness: Each request is independent and there’s no server side session state, improving scalability.
3. Resource-oriented: REST models resources as core abstractions with unique URLs for identification.
4. Flexible data formats: REST allows flexible data formats, such as JSON or XML, negotiated via content headers.
5. Platform and language agnostic: REST is compatible with any platform and programming language, offering versatility in integration.

What Is JSON?

JSON, an acronym for JavaScript Object Notation, serves as a widely employed format within REST clients. It boasts self-descriptive properties, ensuring simplicity and comprehension. To utilize JSON, you simply include it in the payload section of the REST method. As a lightweight data interchange format, JSON enables REST services to maintain high-speed performance, even when handling huge datasets.

SOAP

What Is SOAP Service?

SOAP, or Simple Object Access Protocol, is a protocol used in web services. Protocols in this context are sets of predefined rules governing the behavior of communication between software components. Unlike REST, SOAP is considered a “stateful” protocol. It employs WSDL (Web Services Description Language) for describing web services.

In SOAP, all requests and responses are formatted using XML (Extensible Markup Language). SOAP is recognized for its robust security features compared to alternative protocols. One key distinction is that SOAP does not inherently handle different methods independently, which contributes to its classification as a “stateful” protocol.

Key Features of SOAP

1) Interoperability: SOAP envelopes generated in SOAP services can be used in REST services (e.g., for token creation), but the reverse is not true. This means that tokens created using SOAP can be utilized in REST services, typically via the HTTP header manager section’s Authorization field. However, REST envelopes cannot be used in SOAP requests.

2) Enhanced Security: SOAP is known for its robust security features, leveraging WS-Security for message transmission, in addition to Secure Socket Layer (SSL) for data encryption. This combination makes SOAP a secure choice for sensitive data transfer.

3) XML-Exclusive: SOAP exclusively uses XML for both request and response formats. It does not employ plain text or other data formats, ensuring a standardized data structure.

4) Stateful Operation: SOAP is considered a stateful protocol as it processes the entire request as a whole without independent processing of different methods. In contrast, REST offers more independence in processing various HTTP methods, making it a stateless architecture.

REST vs. SOAP Performance

The inherent statelessness of REST results in greater speed compared to SOAP. Each action is handled separately, and it utilizes JSON Objects, which exhibit superior performance when navigating through documents with huge number of records, ensuring swifter access to specific fields.

REST vs. SOAP Security

The security of SOAP versus REST is not a simple matter of one being inherently more secure than the other. Both SOAP and REST can be secured effectively, but they have different mechanisms and considerations.

SOAP’s security features are more standardized and comprehensive due to specifications like WS-Security, which provides a wide range of security options, including message encryption, digital signatures, and authentication. These features make SOAP a solid choice for scenarios that require stringent security measures, especially in enterprise-level applications.

REST, on the other hand, relies on the underlying transport security (e.g., SSL/TLS) for data encryption and typically uses various authentication methods (e.g., OAuth, API keys) for access control. The security mechanisms in REST are often more flexible and can be tailored to specific application needs.

Working with REST Services in SOAtest

Creating Tests From an OpenAPI/Swagger Definition

SOAtest can automatically create a .tst based on the endpoints found in an OpenAPI/Swagger description. Each .tst generated using the OpenAPI/Swagger wizard will contain REST Clients for all of the defined endpoints.  

To automatically create a test suite from a valid OpenAPI/Swagger definition:

1. Right-click the Examples project in the Test Case Explorer and choose Add New > Test (.tst)… .
2. Enter RESTexample as a name for the file and click Next. 
3. Choose the REST > OpenAPI/Swagger option and click Next.
4. Enter http://localhost:8002/parabank/services/bank/swagger.json in the address tab and click Finish.
5. Notice that a new Test Suite has been created with subtest suites and REST Client tools corresponding to the services provided by the OpenAPI/Swagger file.

Running a Sample REST Client From the Test Suite

1. Double-click the new REST Client tool that was created under Test Suite: /parabank/services/bank/swagger.json => Test Suite: /customers/{customerId}. All of the Path Parameters have been automatically propagated. However, to retrieve a valid result from ParaBank, we must provide a valid customer ID.
2. Provide a valid customer ID by going to the Path table, then enter 12212 under customerId.Note that 12212 is now appended to the URL. Save the changes.

1. Right-click Test 1: /customer/{customerId} – GET in the Test Case Explorer and select Test Using “Example Configuration” to send request to the service with our REST Client.
2. Double-click Traffic Object -> Traffic Viewer and select Response tab to review the response received from the service.

Working With SOAP Services in SOAtest

Creating Tests From WSDL Definition

1. Right-click the Examples project in the Test Case Explorer and choose Add New > Test (.tst)… .
2. Enter WSDLexample as a name for the file and click Next. 
3. Choose the SOA > WSDL option and click Next.
4. Enter http://localhost:8002/parabank/services/store-01?wsdl in the address tab. Ensure that Create Functional Tests from the WSDL is enabled and click Next.
5. Click Next to accept the default settings until you reach the Layout dialog.
6. Enable Organize as Positive and Negative Unit Tests.

1. Click Finish. The newly created test suite appears in the Test Case Explorer.

Running a Sample SOAP Client From the Test Suite

1. Expand the Functional Tests test suite to show the Test Suite: CartServicePort node, which includes seven other test suites that test each operation of the WSDL.

1. Right-click the Test Suite: CartServicePort node and choose Expand All. This will show all seven test suites, as well as every test within each test suite.
   Each of the seven test suites contain both a positive and negative test for each operation. Why create both positive and negative tests? Because it is important to test situations where we send expected data as well as unexpected data to the server.
2. Double-click the Test Suite: getItemByTitle Positive Test > Test 1: getItemByTitle node to open the test configuration panel.
3. Choose the Request > SOAP Body tab in the test configuration panel.
4. Enable the option in the titleKeyword entry field and choose Fixed from the drop-down menu.
5. Enter Linux in the empty field and save the file. We will be searching for books with keyword Linux.

1. Select the Test 1: getItemByTitle node and click the Run Tests tool bar button. The getItemByTitle operation is invoked with the parameter Linux.

1. Expand the Test 1: getItemByTitle node and double-click the Traffic Object-> Traffic Viewer node underneath.The Traffic View opens and displays the traffic that was logged from the test run.

We now have a functional test that tests the getItemByTitle operation of our web service with a single input value. The same sequence of actions can be done to create functional tests for the other operations defined within the WSDL.

Summary

In this section of the tutorial, you’ve gained an understanding of REST and SOAP web services, as well as a comparison between the two. You’ve also learned how to effectively work with these protocols in Parasoft SOAtest. Whether you’re new to the concepts or seeking to enhance your testing skills, you now have the knowledge and practical expertise required to navigate REST and SOAP services within the SOAtest environment.

PREV Tutorial | NEXT Tutorial