REST API

REST APIs enable you to develop any kind of web application having all possible CRUD (create, retrieve, update, delete) operations.

Guarantees following principles:

1) Client-Server application

2) Statelessness: No change to actual state of accessed resource

3) Cacheable: Client decided whether cache needs to be generated or not

4) Layered Architecture

5) Code on demand: Servers allows to send code to client anytime

6) Uniform interface

API Testing:  Testing application at business layer

A URI (Uniform Resource Identifier) is a string containing characters that identify a physical or logical resource. URI follows syntax rules to ensure uniformity. Moreover, it also maintains extensibility via a hierarchical naming scheme.

Eg: https://uatapi.gst.gov.in/bankapi/v0.2/payment (URL+API Name+Version+Module)

HTTP Methods:

1) GET

Use GET requests to retrieve resource representation/information only – and not to modify it in any way.

GET and HEAD methods should be used only for retrieval of resource representations. 

Response code:

Data found: 200 (Success)

Data not found: 404

Request is not correctly formed: 400 (Bad Request) 

2) POST

POST methods are used to create a new resource into the collection of resources.

Response code:

Post Creation: 201

Resource that can be identified by a URI: 200

No Content: 204

3) PUT

Use PUT APIs primarily to update existing resource (if the resource does not exist, then API may decide to create a new resource or not) 

Complete updation/Replace

Post Creation: 201

if an existing resource is modified: 200

No Content: 204

4) DELETE

DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources.

Response code:

Successful response: 200

If the response includes an entity describing the status: 202 (Accepted)

Calling DELETE on a resource a second time: 404 (Not found)

5) PATCH

HTTP PATCH requests are to make partial update on a resource

PATCH method is the correct choice for partially updating an existing resource, and PUT should only be used if you’re replacing a resource in its entirety.

Response code:

Method not allowed: 405 

6) HEAD

Fetch only headers.

7) PATCH

Used for partial update not complete like PUT method.

8) OPTIONS

- Used for checking all options available in API

- Used in exploratory testing

---------------------------------------------------------------------------------------------

100- Information messages

200- Successful 

300- Redirection (Request has more than 1 response from which Client should select one)

400- Client error

500- Server error

Code

Status

Description

200

OK

The request was successfully completed.

201

Created

A new resource was successfully created.

400

Bad Request

The request was invalid.

401

Unauthorized

The request did not include an authentication token or the authentication token was expired.

403

Forbidden

The client did not have permission to access the requested resource.

404

Not Found

The requested resource was not found.

405

Method Not Allowed

The HTTP method in the request was not supported by the resource. For example, the DELETE method cannot be used with the Agent API.

409

Conflict

The request could not be completed due to a conflict. For example,  POST ContentStore Folder API cannot complete if the given file or folder name already exists in the parent location.

500

Internal Server Error

The request was not completed due to an internal error on the server side.

503

Service Unavailable

The server was unavailable.

---------------------------------------------------------------------------------------------

Eg: POST/ PUT request

Body will uniformly consist of three attribute:

·       Action

·       Data

·       Sign

 

JSON Payload will be similar to below format

{

“action” : “Action as per requirement”,

“data” : “ Payload ”,

“sign” : “Above data can be encrypted through a digital certificate”

}

---------------------------------------------------------------------------------------------

SCENARIOS FOR TESTING IN API:

1) Endpoints are correctly named, that resources and their types correctly reflect the object model, that there is no missing functionality or duplicate functionality, and that relationships between resources are reflected in the API correctly.

2) API test actions

2.1) Verify correct HTTP status code

2.2) Verify response payload

2.3) Verify response headers

2.4) Verify correct application state

2.5) Verify basic performance sanity

3) Test scenario categories

  • Basic positive tests (happy paths)
  • Extended positive testing with optional parameters
  • Negative testing with valid input
  • Negative testing with invalid input
  • Destructive testing
  • Security, authorization, and permission tests

4) Test flows

4.1. Testing requests in isolation – Executing a single API request and checking the response accordingly. Such basic tests are the minimal building blocks we should start with, and there’s no reason to continue testing if these tests fail.

4.2. Multi-step workflow with several requests – Testing a series of requests which are common user actions, since some requests can rely on other ones. For example, we execute a POST request that creates a resource and returns an auto-generated identifier in its response. We then use this identifier to check if this resource is present in the list of elements received by a GET request. Then we use a PATCH endpoint to update new data, and we again invoke a GET request to validate the new data. Finally, we DELETE that resource and use GET again to verify it no longer exists.

4.3. Combined API and web UI tests – This is mostly relevant to manual testing, where we want to ensure data integrity and consistency between the UI and API.

We execute requests via the API and verify the actions through the web app UI and vice versa. The purpose of these integrity test flows is to ensure that although the resources are affected via different mechanisms the system still maintains expected integrity and consistent flow.

---------------------------------------------------------------------------------------------------


No comments:

Post a Comment