This Tutorial Explains SOAP and REST Services on Parasoft. You will Learn Stateless vs Stateful, Security of SOAP over REST, Why REST is Faster Than SOAP, etc.:
We have also covered sample requests and the response of SOAP and REST in the XML and JSON format respectively.
Towards the end of this tutorial, you will be able to write your JSON programs which have been explained with different example programs along with the JSON Path or JSON Evaluator and Document Keys concept of Parasoft.
=> Check out the complete SOATest Tutorial Series here.
This tutorial also describes the different verbs that are used in Parasoft or SOAtest Automation Tool along with the programming examples and their respective HTTP response code and usages. You will be able to understand how to build your SOAtest Suites in a better way which will be covered in detail in our upcoming tutorial.
You can also try answering the questions that are listed at the bottom once you have gone through this tutorial.
What You Will Learn:
What is SOAP Service?
SOAP stands for Simple Object Access Protocol. Protocols are nothing but a set of rules which you define for a Test. It is a “state-full” protocol, unlike REST which involves the use of WSDL (Web Services Description Language) to describe web services.
All the requests and responses in SOAP are done in XML (Extensible Markup Language). SOAP is more secure when compared to its counterpart. It does not provide any independent processing for different methods and that is the reason why it is called a “state-full” protocol.
Why is SOAP More Secure?
Although SOAP and REST both support SSL (Secure Socket Layer) for data protection, while making the request, SOAP supports Web Services Security (also known as WS- Security or WSS) for enterprise-level protection which is absent in REST Services. Web Services Security (WS-Security, WSS) is an extension to SOAP to apply security to Web services.
A Sample Request Body of SOAP
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getItemByIdResponse xmlns:ns2="http://bookstore.Parasoft.com/"> <book>Parasoft</book> <environment>TUP</environment> <result>true</result> </getItemByIdResponse> </soap:Body> </soap:Envelope>
We have an XML which will be used as a payload to form the request body of the SOAP. Any XML language consists of the version that should be defined on top of the script. You don’t have to worry about the tags, as all XML files let you create your tags, unlike HTML.
If you are trying to generate the tokens through a SOAP request, then you just have to provide the necessary parameters like user id and password along with the URL that you are hitting in the request body or the XML under your customized tags.
Given below is the screenshot of the traffic viewer of the Parasoft (a component which lets you see the result).
[image source]
Prominent Features of SOAP
Enlisted below are some of the prominent features of SOAP:
#1) Any SOAP envelope can be used in REST services like generated token but not vice versa. This means that if you have created a token using SOAP then that token can be used in REST (under HTTP header manager section => Authorization). But you can not use REST envelopes in a SOAP request.
#2) SOAP is more secure than REST as it uses WS-Security for transmission along with Secure Socket Layer.
#3) SOAP only uses XML for request and response. It does not use plain text or other.
#4) SOAP is state-full (not stateless) as it takes the entire request as a whole, unlike REST which provides independent processing of different methods. No independent processing is there in SOAP.
What is REST Service?
REST stands for Representational State Transfer. REST is a “stateless” architecture that involves multiple methods or verbs while dealing with requests and responses.
All the requests and responses in REST are done in XML, JSON (JavaScript Object Notation) or Plain Text. REST is faster than SOAP because of the involvement of JSON (which is light-weight) in the request/payload of REST.
Each method is processed independently in REST which is the reason why it is called “stateless” architecture.
Why is REST Faster?
The statelessness nature of REST makes it faster than a SOAP. Each verb is processed independently and it makes use of JSON Object which is much faster when traversing to any particular field in a document containing more than a million records.
Before we start about methods that are used in REST, we need to know about JSON and JSON path as it is the most common format of transmitting data in REST.
Whats is JSON?
JSON stands for JavaScript Object Notation. It is a format that is commonly used in the REST client.
It is self-describing and easy to understand as well. You just have to pass your JSON in the payload section of the REST method. It is a light-weight data interchange format that lets REST services to be much faster even if it is dealing with one million records.
Programming with JSON
Below is a sample program with only one document called “phone”.
[image source]
This is my sample JSON program in which I have to fetch the value of my phone type. In such a scenario, you can use two techniques to get through that field. One is by JSON Path and the other one is by document key.
#1) While dealing with JSON path, you can use two methods:
$.phone[:1].type $['phone'][':1']['type']
#2) As Parasoft does not allow the JSON path, we can use the document key which is a bit simple when traversing. Just pass the document key along with the URL in the resource tab as
phone.type
You just have to click on the add button in the below screenshot and enter phone.type and you are done.
In the below example, you have to traverse through the last element of the location field which is an array. Thus, try writing a JSON Path for it.
As you can see in line numbers 37 and 39 (above), two different JSON paths have been written for the same traversing to the last element of the location field. In the same way, you can create your JSON (a complex nested document) and try writing the JSON path for practice purposes.
RESULT:
[“Helsingborg”]
You can try as many JSON as you want, in an open website called JSON online Evaluator
Methods/Verbs in Restful Services
REST services provide a wide range of methods which are also known as verbs for a different type of requests. These mainly include POST, PUT, PATCH, GET, DELETE, CUSTOM.
POST
This method is responsible for creating the record. Upon successful execution, the HTTP response code is 201.
Below is the sample JSON illustrating the POST.
{
“Test”: {
“Tester Name”: “Saket Saurav”, “Designation”: “QA”,
“Test2”: {
“Testing”: “Nested Document”, “Platform”: “Windows”
}
}
}
When we pass this JSON as a request body then it will create the document with a 201 response code.
GET
This is another method or verb which is used to retrieve the document or record. Upon successful execution of GET, the response code will be 200. This does not contain any request body or payload.
All you have to do is just hit the same URL using the GET method in the resource tab of the Parasoft using the document key as “Test”. Even if you don’t pass any document key, it will fetch the entire document.
Let’s say we pass the document key as “Test.Test2”, then it will fetch me the following record.
{
“Test”: {
“Test2”: {
“Testing”: “Nested Document”, “Platform”: “Windows”
}
}
}
PUT
This method is used to update the document and it has a 200 response code after successful execution.
Although POST and PUT do not differ much and it all depends on the developer as to how they want to code. Mostly, developers use the PUT method when they want to update some field value.
For Example: If we want to change some value in the above JSON document inserted by POST, then we will pass the entire request body with the updated value using the PUT method.
{
“Test”: {
“Tester Name”: “Saket Saurav”, “Designation”: “QA”,
“Test2”: {
“Testing”: “Nested Document”, “Platform”: “Updated Windows”
}
}
}
When we see the response in the traffic viewer, then the field value will be updated as
“Platform”: “Updated Windows”
PATCH (CUSTOM)
This is another method that is solely used for updating the record. Most developers prefer this method over the PUT method as it makes the best use of the resources. If you want to update some field value in your document, all you have to do is to pass only that field with the updated value of the record.
Let’s say, If we want to update the POST record, then we will only use the following request body while using PATCH.
{“Test”: {
“Test2”: {
“Testing”: “Nested Document”, “Platform”: “Updated Windows”
}
}
}
As you noticed, here we did not pass the field values of “Test”, unlike the PUT method. Successful execution will give you a 200 or 201 response code.
DELETE
As the name itself suggests, it will delete the record also known as preferences. This does not contain any request body like GET and often has the response code as 203 (No Content). If we need to delete the entire document then in the above JSON, then we will just pass the document key as.
Test
This will delete the entire document. If we do not pass the document key at all, then also it will delete the entire document.
Interviewer’s Traps
Q #1) Most of the interviewers try to confuse when they ask you that they got a successful delete operation response code as 200 instead of 204. In this sort of situation, what should I do? Should I report it as a bug?
Answer: The answer to the above question is simple. You don’t have to raise a bug. Instead, you can talk to the developer or try to observe the other delete operation response. A response code 200 always denotes the successful operation and 204 is specific for DELETE. There might be a chance that the developers used 200 for all successful operations.
Q #2) How do I check if the particular field values are correct or not without using a database in a JSON request of 1 million lines of code?
Answer: The answer is by sending the document key in the GET operation. The sample URL will look as shown below:
https://resource-name.com/context-key/document-key
In the above URL, your context key will uniquely fetch that particular JSON of 1 million records and the document key will fetch the particular field-value in that record.
Q #3) If I do not specify any document name on top of my JSON, what should I pass as a document key to fetch the entire document?
Answer: You can pass anything. Yes, exactly. If you do not have any document name specified and if there are only fields and values that are present in your document, then you can pass any string value. That string will be treated as your document key automatically.
Summary
By now, you should have a fair idea about SOAP and REST web services, their structure, major differences between them, their features and usage.
Moreover, in this tutorial, we have covered the most common/important methods (also known as verbs) that are used in REST services along with JSON programming and JSON path for evaluation purposes.