What is API/Web Service Testing?
Application Programming Interface (API) is a set of rules and mechanisms by which one application or component interacts with another. API can return data in a convenient format such as JSON, XML, etc. APIs for web applications are often referred as Web services.
Testing these APIs directly as part of integration testing to determine if they meet the expectations for functionality, reliability, performance, and security is known as API Testing. API Testing can be performed manually and also with automation tools. Automated API testing is crucial for implementing testing in Continuous Integration/Continuous Deployment (CI/CD) environment.
API testing is performed at the business layer and can validate application logic. This is different than browser based Graphical User Interface (GUI) testing.
What are RESTful services?
Representational Stage Transfer (REST) is an approach and an architectural style that defines a set of constraints to be used for creating Web services. The word “Representational” means that a representation of the resources is transferred i.e. when a client request a resource, the server do not sent the actual resource, but rather a representation of that resource in a format that is readable by the client. The resources can be a list of users, pictures, documents, videos, posts, web pages, etc. that can be transferred through web. REST relies on a stateless communications protocol, most commonly, Hypertext Transfer Protocol (HTTP). REST can structure data in HTML, XML or YAML formats; however JSON is the most widely used data structure in RESTful services.
The web services that implement REST architecture are typically referred as RESTful services.
What does RESTful web services do?
RESTful services performs 4 basic operations through HTTP protocol:
- Retrieving data – Retrieve data from the given URI
- Create new data – Create a new entry in the database
- Update data – Update existing entities in the server
- Delete data – Delete a given resource at the specified URI
These operations are also called as CRUD (Create, Read, Update and Delete).
In REST architecture, the client makes HTTP request to the server in order to retrieve or modify data. A HTTP request generally consists of:
- A HTTP request method, which defines what kind of operation to perform.
- A HTTP header, that allows the client to pass additional information about the request.
- A request target. This is usually a Uniform Resource Locator (URL) of the resource.
- An optional request body containing data to be sent to the server. The request body is a structured data such as XML, YAML or JSON. GET and DELETE request methods usually don’t need a message body.
HTTP request methods
The request method indicates the operation to be performed on the resource identified by the given request URI. The method should always be given in uppercase. The HTTP request methods are generally called HTTP verbs.
GET – GET method is used to retrieve data from server at the specified resource/URI. GET should only extract data and should have no other effect on the data.
POST – POST method is used to create new entity. It can also be used to send data to the web server to create or update a resource (e.g. customer information, file upload, etc. using HTML forms). The POST request requires a URI, header and a message body.
PUT – PUT method is used to send data to the API to create or update resource. The difference is that PUT requests are idempotent, meaning calling the same PUT request multiple times will always produce the same result. The PUT request requires a URI, header and the message body.
DELETE – DELETE method is used to delete the resource at the specified URI.
When a client sends a valid HTTP request to the server, the server sends back the HTTP response relates to that request. The aim of the response is to inform the client that its request has been processed; or else inform the client that an error occurred in processing its request.
An HTTP response contains:
- Status code
- HTTP headers
- A response body
The HTTP response from the server contain status code to inform the client about the status of its request. There are many status codes available which are grouped in five categories:
|1xx: informational||Communicates transfer protocol-level information||100 continue|
|2xx: Success||Indicates that the client’s request was processed successfully||200 OK |
204 No Content
|3xx: Redirection||Indicates that the client must take some additional action in order to complete their request||300 Multiple choice 302 Found|
| 4xx: |
|Indicates that there is an error in the request from the client||400 Bad Request |
| 5xx: |
|Indicates that there is a problem at the server side||500 Internal Server Error |
501 Not Implemented 502 Bad Gateway
The response from the server contain different types of HTTP headers. The headers contains information that a client can use to find out more about the response, and about the server that sent it. These headers also contains information about the response body such as ‘Content-type’, ‘Content-length’, ‘Date’, etc.
For a response to a successful request, the response body contains the resource requested by the client (like content of an HTML form or a document, etc.) or some information about the status of the request. Not all responses have a body. The ‘content type’ and ‘content length’ of the body are specified in the HTTP header of the response.
For a response to an unsuccessful request, the response body might provide further information about the reasons for the error.
How to test REST API?
API testing is sending different requests to the API server and verifying the responses from the server. This is different from browser based User Interface (UI) testing. API testing requires a tool/framework that can send requests to the API and display the response from server.
There are number of open-source and commercial tools available for API testing. Postman, SoapUI, Katalon Studio and Advanced REST client are the popular open-source tools for API testing. Swagger is an open-source tool for API documentation and can also be used to validate the API endpoints.
Testing REST API with Postman
To get started, download and install latest version of Postman.
Create and send HTTP Request
You can launch the Postman from the start menu or the desktop shortcut. Once the Postman is launched you can start creating the request by clicking on the new tab with + icon.
- Select GET request from the request method dropdown
- Enter the request-URL (http://httpbin.org/anything) in the URL fields
- Click “Send” button
Verify HTTP Response
Once a successful GET request is sent to http://httpbin.org/anything, the server has sent back the HTTP response. The response contains Status-code, Header and Response body.
The status code is set to 200 OK, which means that the request was processed successfully.
The response headers contains information about the response body such as:
- Content-Type: application/json – indicates that the data in the response body is in JSON format.
- Date – date and time the message was sent.
- Content-Length: 279 – indicates the size of the data in the response body
The response headers also contains other information that is required by the client to process and display the response to the user.
The response body contains the resource requested by the client from the given URL. In this case the response body is some data presented in JSON format.
Read more about using Postman for API testing here.
API Testing Mind map