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
---------------------------------------------------------------------------------------------------