API Basic Contents and 15 SOAP UI Interview Questions & Answers

API Contents and 15 SOAP UI Interview Questions & Answers:

Introduction to APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is a Web Application? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Google Is an Example of a Web Application . . . . . . . . . . . . . . . . . . . . . 

What Is an API? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is an HTTP Request? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is a URL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Are HTTP Verbs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is an HTTP Response? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is an HTTP Status Code? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Are Payloads? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is JSON? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is XML? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Are HTTP Headers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is Authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Is REST? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

What Tools Are Used for Accessing an API? . . . . . . . . . . . . . . . . . . . . . 

Example APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  

Introduction to APIs:

The term “API” stands for Application Programming Interface. If you break that down word by word, you can get a pretty good idea of what it means. An API is an interface that can be used to program 

software that interacts with an existing application. In practice, an API is “a set of functions and 

procedures” that allow you to access and build upon the data and functionality of an existing 

application.

So in this topic will provide an introduction to the concept of an API (Application Programming

Interface) and concentrates on Web or Internet accessible APIs. I will explain most of the

concepts that you need to understand and I will start from the very basics. Most of this chapter will 

be written common sense understanding rather than to provide formal computer science definitions or 

terminology.

You can probably skip this topic if you are familiar with Web Services, URI /URL,

HTTP, HTTP Status Codes, JSON and XML.

Also, because this chapter covers a lot of definition, feel free to skip it if you want to get

stuck in to the practical aspects. You can always come back to this chapter later if you don’t

understand some basic terminology.

First I’ll start by saying that we are going to learn how to test Web Applications. i.e.

Applications that you can access over a network or the internet without installing them on

your machine.

The Web Application we will test has an API, which is a way of accessing the application

without using a Web Browser or mobile browser or the application’s Graphical User Interface (GUI).

What Is a Web Application?

A Web Application is a software application that is deployed to a Web Server. This means the

application is installed onto a computer and users access the application via a Web Browser.

Let's take one Google Is an Example of a Web Application https://google.com is an example of a Web 

Application. A user visits google.com in a Browser and the application’s Graphical User Interface (GUI) is displayed in the Browser. The GUI consists of a search input field which the user fills in and then clicks a button to search the Web.

When the user clicks the search button, the Browser makes a request to the Web Application

on the Web Server to have the Google Search Application make the search and return the

results to the user in the form of a web page with clickable links.

Basically,Introduction to APIs 6

• Web Browser -> Sends a Request to -> Web Application

• Web Application -> Processes Request and Sends a Web Page as Response to -> Web

Browser.

The requests that the Browser sends to the Web Server are HTTP requests. HTTP requests

are a way of sending messages between machines over the Internet. Think of HTTP as the

format of the message that Browser and Web Server send to each other and they understand easily.

When we first visit Google in a Browser we type in the URL or address for Google. i.e.

https://google.com The Browser then sends a type of HTTP request to Google called a GET request to 

‘get’, or retrieve, the main search form. Google Web Application receives the request and replies with

an HTTP response containing the HTML of the search page. HTML is the specification for

the Web Page so the Browser knows how to display it to the user in proper GUI format.

When the user types in a search term and presses the search button. The Browser sends a

POST request to Google. The POST request is different from the GET request because it contains

the details of the search term that the user wants the Google Web Application to search for.

The Google Web Application then responds with an HTTP response that contains the HTML

containing all the search results matching the User’s search term.

Google is an example of a Web Application with a GUI, and because the user accesses the

Web Application through a Browser they are often unaware of the HTTP requests, or that

different types of HTTP requests are being made.

When we test HTTP APIs we have to understand the details of HTTP requests.

What Is an API?

An API is an Application Programming Interface. This is an interface to an application

designed for other computer systems to use. As opposed to a Graphical User Interface (GUI)

which is designed for humans to use.

APIs come in many different forms with and technical implementations but this we will

concentrates on HTTP API or Web APIs or Web services.*

An HTTP based API is often called a *Web API since they are used to access Web Applications

which are deployed to Servers accessible over the Internet.

Applications which are accessed via HTTP APIs are often called *Web Services.

APIs have been described as the glue holding the Internet together.

Mobile Applications often use Web Services and REST APIs to communicate with servers

to implement their functionality. The Mobile Application processes the message returned

from the Web Service and displays it to the User in the application GUI. So again, the user is

unaware that HTTP requests are being made, or of the format of the requests and responses.

How API Born?

APIs have been around for a very long time. Pretty soon after the first computer application was 

created, clever developers realized that you could get a lot more out of distinct applications by 

linking them together — and so the API was born.

Nowadays, when we’re talking about APIs we’re typically referring to web APIs, which expose an 

application’s data and functionality over the internet. If you look closely, you’ll see that web APIs 

power our everyday lives:

When you log into a website using your Facebook profile.

When you switch on Netflix and see dozens of new movies flood the screen.

When you look for flights on Google.

… and the list goes on and on

Technically speaking, web APIs usually send data back and forth using HTTP requests. These requests 

often return textual data in the form of a JSON or XML response.

What Is an HTTP Request?

HTTP stands for Hypertext Transfer Protocol and is a way of sending messages to software

on another computer over the Internet or over a Network.

An HTTP request is sent to a specific URL like (google url) and consists of:

• a VERB specifying the type of request e.g. GET, POST, PUT, DELETE

• A set of HTTP Headers. The headers specify information such as the type of Browser,

type of content in the message, and what type of response is accepted in return.

• A body, or payload in the request, representing the information sent to, or from, the

Web Application. Not all HTTP messages can have payloads: POST and PUT can have

payloads, GET and DELETE can not.

HTTP requests are text based messages and over the course of this Case Study you will learn

to read them e.g.

GET http://google.co.uk/apps/test/projectsjson.php HTTP/1.1

Host: google.co.uk

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

AppleWebKit/537.36 (KHTML, like Gecko)

Chrome/59.0.3071.115 Safari/537.36

Accept: text/html,application/xhtml+xml,

application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

The above HTTP request is a GET request, which is a READ request:

• to read the page from the URL

– http://google.co.uk/apps/test/projectsjson.php

• request is made from the Chrome Browser version 59. You can see this in the ‘User-

Agent’ header. Yes, the header also mentions ‘Safari’, ‘AppleWebKit’ and ‘Mozilla’, this

is for various reasons of backwards compatibility, but it was sent from Chrome version

59. For more information on User-Agent visit useragentstring.com.

What Is a URL?

URL is a Uniform Resource Locator and is the address we use to access websites and web applications.

When working with APIs you will often see this referred to as a URI (Uniform Resource Identifier).

Think of a URI as the generic name for a URL.

When we want to call an HTTP API we need the URL for the endpoint we want to call e.g

http://google.co.uk/apps/test/projectsjson.php

This is the locator that says “I want to call the apps/test/projectsjson.php resource

located at google.co.uk using the http protocol”.

For the purposes of this topic I will use the phrase URL, but you might see URI mentioned

in some of the source code. I use URL because the locator contains the protocol or scheme

required to access it (http).

The above URL can be broken down into the form:

*scheme://host/resource*

• scheme - http

• host - google.co.uk

• resource - apps/test/projectsjson.php

A larger form for a URL is:

scheme://host:port/resource?query#fragment

I didn’t use a port in the URL, for some applications you might need to.

By default http uses port 80, so I could have used:

http://google.co.uk:80/apps/test/projectsjson.php

Also I haven’t used a query because this endpoint doesn’t need one.

The query is a way of passing parameters in the URL to the endpoint e.g. 

Google uses queryparameters to define the search term and the page:

https://www.google.co.uk/?q=test&start=10#q=test

Introduction to APIs 10

• scheme - https

• host - www.google.co.uk

• query - q=test&start=10

• fragment - q=test

The query is the set of parameters which are key, value pairs delimited by ‘&’ e.g. q=test

and start=10 (“start” is a key, and “10” is the value for that key).

When working with APIs it is mainly the scheme, host, port and query that you will use.

What Are HTTP Verbs?

A Web Browser will usually make GET requests and POST requests.

• GET requests ask to read information from the server e.g. clicking on a link.

• POST requests supply information to the server e.g. submitting a form.

GET requests do not have a body, and just consist of the Verb, URL and the Headers.

POST requests can have a payload body 

For e.g.

POST http://www.google.co.uk/apps/test/reflect.php HTTP/1.1

Host: www.google.co.uk

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

AppleWebKit/537.36 (KHTML, like Gecko)

Chrome/59.0.3071.115 Safari/537.36

Accept: text/html,application/xhtml+xml,

application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

{"action":"post"}

When working with a Web Application or HTTP API the typical HTTP Verbs used are:

• GET, to read information.

7https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

Introduction to APIs 11

• POST, to create information.

• PUT, to amend or create information.

• DELETE, to delete information, this is rarely used for Browser accessed applications,

but often used for HTTP APIs.

Note : POST and PUT requests would usually have a message body. GET and DELETE would not.

HTTP Verbs are described in the W3c Standard and IETF standard.

What Is an HTTP Response?

When you issue an HTTP Request to the server you receive an HTTP Response.

The response from the server tells you if your request was successful, or if there was a

problem.

*HTTP/1.1 200 OK*

Date: Fri, 30 Jun 2020 13:50:11 GMT

Connection: close

Content-Type: application/json

{

"projects": {

"project": [

{

"id": 1,

"name": "A New Project",

"position": 0,

"description": "",

"state": "active",

"created-at": "2020-06-27T12:25:26+01:00",

"updated-at": "2020-06-27T12:25:26+01:00"

}

]

}

}

The above response has:

• A status code of 200, which means that the request was successful.

• A Content-Type header of application/json which means that the body is a JSON

response.

• A body which contains the actual payload response from the server.

What Is an HTTP Status Code?

Web Services and HTTP APIs use HTTP Status Codes to tell us what happened when the

server processed the request.

The simple grouping for HTTP Status Codes is:

• 1xx - Informational

• 2xx - Success e.g. 200 Success

• 3xx - Redirection e.g. 302 Temporary Redirect

• 4xx - Client Error e.g. 400 Bad Request, 404 Not Found

• 5xx - Server Error e.g. 500 Internal Server Error

The type of status code you receive depends on the application you are interacting with.

Usually a 4xx error means that you have done something wrong and a 5xx error means that

something has gone wrong with the application server you are interacting with.

What Are Payloads?

A Payload is the body of the HTTP request or response.

When browsing the Web, the Browser usually receives an HTML12 payload. This is the web

page that you see rendered in the Browser.

Typically when working with an HTTP API we will send and receive JSON or XML payloads.

What Is JSON?

JSON stands for JavaScript Object Notation and is a text representation that is also valid

JavaScript code.

{

"projects": {

"project": [

{

"id": 1,

"name": "A New Projectaniheeiadtatd",

"position": 0,

"description": "",

"state": "active",

"created-at": "2017-06-27T12:25:26+01:00",

"updated-at": "2017-06-27T12:25:26+01:00"

}

]

}

}

JSON can be thought of as a hierarchical set of key/value pairs where the value can be:

• Object - delimited by { and }.

• Array - delimited by [ and ].

• String - delimited by " and ".

• Integer

An array is a list of objects or key/value pairs.

The keys are String values e.g. “projects”, “project”, “id”, etc.

What Is XML?

XML stands for Extensible Markup Language.

HTML is a variant of XML.

Introduction to APIs 14

<?xml version="1.0" encoding="UTF-8"?>

<projects type="array">

<project>

<id type="integer">1</id>

<name>A New Projectaniheeiadtatd</name>

<position type="integer">0</position>

<description nil="true"/>

<state>active</state>

<created-at type="dateTime">2017-06-27T12:25:26+01:00

</created-at>

<updated-at type="dateTime">2017-06-27T12:25:26+01:00

</updated-at>

<default-context-id type="integer" nil="true"/>

<completed-at type="dateTime" nil="true"/>

<default-tags nil="true"/>

<last-reviewed type="dateTime" nil="true"/>

</project>

</projects>

XML is constructed from nested elements

• An element has an opening and closing tag e.g. <state> and </state>.

– The tag has a name i.e. state.

– The opening tag begins with < and ends with > e.g. <state>.

– The closing tag begins with </ and ends with > e.g. </state>.

• An element has a value, which is the text between the tags e.g. the state element has

a value of active.

• An element can have attributes, these are always within the opening tag e.g. the

id element (<id type="integer">) has an attribute named type with a value of

"integer".

• Elements can contain other Elements. These are called Nested Elements. e.g. the

projects element has a nested element called project.

For XML to be valid, it must be well formed, meaning that every opening tag must have a

corresponding closing tag, and strings must have an opening and closing quote.

Some elements do not have a closing tag, these are self closing. The opening tag, instead of

ending with > actually ends with /> you can see this in the <description nil="true"/>

element.

What Are HTTP Headers?

HTTP messages have the Verb and URL, followed by a set of headers, and then the optional

payload.

POST http://www. google.co.uk/apps/test/reflect.php HTTP/1.1

Host: www.google.co.uk

Content-Type: application/json

Accept: application/json

{"action":"post"}

The headers are a set of meta data for the message.

Headers are a name, followed by :, followed by the value of the header.

The above HTTP message example has three headers:

• Host

• Content-Type

• Accept

The Host header defines the destination server domain name.

The Content-Type header tells the server that the content of this message is JSON.

The Accept header tells the server that the client (application sending the message) will only

accept response payloads represented in JSON.

There are many headers available13 for configuring the Authentication details, length of

message, custom meta data, cookies etc.

What Is Authentication?

When we send a message to a server we might need to be authenticated i.e. authorised to

send a message and receive a response.

For many Web Applications you authenticate yourself in the application by logging in with

a username and password. The same is true for Web Services or HTTP APIs.

If you are not authenticated and try to send a message to a server then you are likely to

receive a response from the server with a 4xx status code e.g.

• 401 Unauthorized

• 403 Forbidden

There are many ways to authenticate HTTP requests for HTTP APIs.

Some common approaches you might encounter are:

• Custom Headers

• Basic Authentication Headers

• Session Cookies

Some HTTP APIs require Custom Headers e.g.

POST http://www.google.co.uk/apps/test/reflect.php HTTP/1.1

X-APPLICATION_KEY: asds-234j-werw

Here the X-APPLICATION-KEY header has a secret value which authenticates the request.

Basic Authentication Headers are a standard approach for simple login details:

POST http://www.compendiumdev.co.uk/apps/mocktracks/reflect.php HTTP/1.1

Authorization: Basic Ym9iOmRvYmJz

The Authorization header specifies Basic authentication and is followed by a base6414

encoded string.

• “Ym9iOmRvYmJz” is the base64 encoded version of the string “bob:dobbs”

• In Basic Authentication the string represents username:password

Session Cookies15 are set by a server in a response message and are represented in a Cookies:

header.

What Is REST?

REST stands for Representational State Transfer, and while it has a formal definition, which

you can read in Roy Fielding’s PHd thesis16, it very often means that the API will respond to

HTTP verbs as commands.

e.g.

• GET, to read information.

• POST, to create information.

• PUT, to amend information.

• DELETE, to delete information.

The documentation for the particular system you are testing will describe how the API has

interpreted REST if they have described their API as a REST API.

What Tools Are Used for Accessing an API?

Since API stands for Application Programming Interface, we might expect all interaction

with the API to be performed via program code. But it really implies that the interface is

well documented and does not change very often.

Also that the input and output from the API are designed for creation and consumption by

code - hence the use of formats like JSON and XML.

We can issue API requests from a command line with tools like cURL, which you will see

later in this topic.

Also GUI tools like Postman, which we cover in a later chapter, allow humans to easily

interact with APIs.

When writing application code to interface with an API we are generally able to use a library

for the specific programming language that we are working with.

In this topic we are using Java and will use the REST Assured library.

Example APIs:

If you want a very simple API to experiment with at the moment, then I recommend the Star

Wars API Web Application.

• swapi.co

This is a very simple API that mainly uses GET requests and returns information about Star

Wars characters and planets.

The API is well documented and has an online GUI that you can use to experiment with the

API.

Top 15 SoapUI Interview Questions & Answers:

1) Explain what is SOAP UI?

SOAP UI is a free, open source cross-platform functional Testing solution.  It enables you to rapidly 

and easily create and execute automated regression, compliance, functional and load tests. Its used for 

Web Services Testing

2) Explain what is the role of XML, SOAP, WSDL and UDDI in web services?

Web services are a medium through which web based application can be integrated or communicated over an internet protocol backbone. Web based application can be integrated using XML, SOAP, UDDI and WSDL. 

SOAP is used for transmitting the data; WSDL is used for describing or relating the services, UDDI is 

used for listing what services are accessible, XML is used to tag the data.

3) Mention what SoapUI can do?

SoapUI can-

It can do automated testing like load tests, scenario-based tests and data driven tests

It has got built-in reporting abilities

It has got unique ability to impersonate Web services and run functional and load test against them 

even before they are executed

4) Mention how SoapUI is used to structure functional tests?

SOAP UI uses three levels to structure functional tests

TestSuite: It is a pool of test cases used for combining functional tests into logical units

TestCase: It is a group of test steps that are bring together to test some specific aspect of your 

services. You can augment any number of testcases to test suites

TestSteps: They are “building blocks” of functional tests in SOAPUI. They together makes TestCase and 

determines the flow of execution of the service to be tested.

5) Mention what is the difference between REST and SOAP?

SOAP: Soap stands for Simple Object Access Protocol and it is a protocol used for receiving and sending data over HTTP as XML

REST: It is a way of designing a web services.

6) Explain what is the properties in SoapUI?

Properties in SOAPUI is used to retrieve and store data.  The data is stored as key, value or format.

7) Explain where you use properties in SoapUI?

We can read the property values into test step endpoint, username, header values, password, domain, 

POST, PUT, GET and DELETE method properties.

8) Mention what languages does SoapUI use?

SOAP UI supports two language, Groovy, and JavaScript.

9) Mention what are the default properties in SOAPUI?

By default, SOAPUI has properties at three levels

Project level default or custom properties: User can append any number of properties at project level 

and it can be opened from any test steps from any test cases under any test suites

Test suite level default or custom properties: User can append any number properties at test suite 

level and it can be used from any test steps from any test cases under this test suite

Test case level default or custom properties: At Test Case level users can add any number properties at 

test case level and it can be used from any test steps from this test case.

10) Explain how you can parameterize the endpoints in SOAP UI?

To parameterize the endpoints in SOAP UI is most important as it is the first step in Automation 

Testing.  It is more time consuming for changing endpoints manually.  In order to do that

Define a project property holding the endpoint

Change the endpoint to use this property via property expansion

Ensure that your requests are availing the configured endpoint

When a request is run, the property will inevitably be with its current value. To use a different value 

just configure the endpoint in the UI, you can use the P option from the command line.

11) Mention what is the general format for reading the custom or default property value?

The general format for reading the custom or default property value is ${#levelname#key}

12) Inside the SOAPUI where groovy script can be used?

Inside the SOAPUI groovy script can be used in two places Groovy script test step

Script Assertion- within test step

13) Mention some important functionalities of SOAP UI?

Some important functionalities of SOAP UI are:

It creates a new project using only the web service WSDL link; it will get the information of all 

methods and import them automatically

It creates test cases directly from the web method request

It tests web methods in combination or separately. It has a very useful capability which allows datas 

and parameters to be passed from one method to another.  It enables you to save data in variables so 

other methods can access it It enables creating validations on the web method results through assertions; the assertion can be created either in X-path or X-query

It helps in creating other types of validations like schema compliance, soap fault, response time etc.

It enables organizing the test cases in test suites

It enables running all test cases from a test suite and getting fail/pass results for each test case

It enables parameterization of the test cases request fields so that a test case can avail different values from a table or database

Using groovy it enables creating complex validation scripts

It has some support for web service Load Testing

It has some support for testing coverage and requirements management

14) Explain what assertion is in Soap UI is and give some example of assertion possible in SOAPUI?

In SOAP UI assertion functionality is used to validate the response of request received by the Test 

Steps at the time of execution.  It is used to compare a part of message to some expected value.

Assertion types in SOAPUI includes

Simple contains

Schema compliance

Simple not contains

Soap Faults

Response SLA

XPath Match

XQuery Match

WS security status

Script Assertion

WS- Addressing Request or Response Assertion

15) Does SoapUI support SSL Authentication

Yes