Checklist for API Verification
These days where Applications talk to each other using API, the verification of any message between the applications/microservices needs to be verified. This checklist includes some best practices for API verification.
Join the DZone community and get the full member experience.
Join For FreeMicroservices are a designer's way to address the complexity of applications in today's world. Verification and Deployment of these applications are however lost in the implementation as the same thought the process is very rarely communicated in the Real-world.
A web application that could be decomposed into Model-View-Controller architecture has morphed to the world of Unstructured Data<->Microservice<->Frontend. The ability to have a configurable backend(datastore as opposed to a DB) and a Flexible Frontend places Microservice API as a premier source of data interchange.
This check is a work in process to the traditional tester/validation team to address real-world challenges in the deployment of Infrastructure as Code.
openapi: "3.0.0"
info:
title: Simple API overview
version: 2.0.0
description: >-
API To Test Hello World.
version: '1'
termsOfService: 'http://swagger.io/terms/'
host: 'localhost'
paths:
/:
get:
operationId: listVersionsv2
summary: List API versions
responses:
'200':
description: |-
200 response
content:
application/json:
examples:
foo:
value:
{
"versions": [
{
"status": "CURRENT",
"updated": "2011-01-21T11:33:21Z",
"id": "v2.0",
"links": [
{
"href": "http://127.0.0.1:8774/v2/",
"rel": "self"
}
]
},
{
"status": "EXPERIMENTAL",
"updated": "2013-07-23T11:33:21Z",
"id": "v3.0",
"links": [
{
"href": "http://127.0.0.1:8774/v3/",
"rel": "self"
}
]
}
]
}
'300':
description: |-
300 response
content:
application/json:
examples:
foo:
value: |
{
"versions": [
{
"status": "CURRENT",
"updated": "2011-01-21T11:33:21Z",
"id": "v2.0",
"links": [
{
"href": "http://127.0.0.1:8774/v2/",
"rel": "self"
}
]
},
{
"status": "EXPERIMENTAL",
"updated": "2013-07-23T11:33:21Z",
"id": "v3.0",
"links": [
{
"href": "http://127.0.0.1:8774/v3/",
"rel": "self"
}
]
}
]
}
/v2:
get:
operationId: getVersionDetailsv2
summary: Show API version details
responses:
'200':
description: |-
200 response
content:
application/json:
examples:
foo:
value:
{
"version": {
"status": "CURRENT",
"updated": "2011-01-21T11:33:21Z",
"media-types": [
{
"base": "application/xml",
"type": "application/vnd.openstack.compute+xml;version=2"
},
{
"base": "application/json",
"type": "application/vnd.openstack.compute+json;version=2"
}
],
"id": "v2.0",
"links": [
{
"href": "http://127.0.0.1:8774/v2/",
"rel": "self"
},
{
"href": "http://docs.openstack.org/api/openstack-compute/2/os-compute-devguide-2.pdf",
"type": "application/pdf",
"rel": "describedby"
},
{
"href": "http://docs.openstack.org/api/openstack-compute/2/wadl/os-compute-2.wadl",
"type": "application/vnd.sun.wadl+xml",
"rel": "describedby"
},
{
"href": "http://docs.openstack.org/api/openstack-compute/2/wadl/os-compute-2.wadl",
"type": "application/vnd.sun.wadl+xml",
"rel": "describedby"
}
]
}
}
'203':
description: |-
203 response
content:
application/json:
examples:
foo:
value:
{
"version": {
"status": "CURRENT",
"updated": "2011-01-21T11:33:21Z",
"media-types": [
{
"base": "application/xml",
"type": "application/vnd.openstack.compute+xml;version=2"
},
{
"base": "application/json",
"type": "application/vnd.openstack.compute+json;version=2"
}
],
"id": "v2.0",
"links": [
{
"href": "http://23.253.228.211:8774/v2/",
"rel": "self"
},
{
"href": "http://docs.openstack.org/api/openstack-compute/2/os-compute-devguide-2.pdf",
"type": "application/pdf",
"rel": "describedby"
},
{
"href": "http://docs.openstack.org/api/openstack-compute/2/wadl/os-compute-2.wadl",
"type": "application/vnd.sun.wadl+xml",
"rel": "describedby"
}
]
}
}These are some guidelines that could be used to check the payload, response, deployment, and parameters from the YAML for the API to be tested.
Steps to Check for API Completeness When a YAML File Is Shared
1. Get the YAML or API specs listing the URL. i.e https://localhost:8089/API/Vx/Resource
- Info (Actions allowed on the Endpoint/Resource)
- server(Environment/URL where the Application would be hosted)
- path( API Endpoint and Port details for Deployment)
- components( Endpoint from which the resource can be accessed)
- Check for deployed versions and implemented Vx version
2. Confirm and verify the Method (GET/POST/PUT/PATCH/UPDATE) and URL to the server Deployed to ex: (https://<ENVIRONMENT>:PORT/ ) along with valid :
A: credential with Bearer Token
B: Parameters?XXKEY=XXVAL&YYKEY=YYVAL ( from the Path section)
C: The body of the Method is well-formed ( from the Schema) and declared in the header
3. Verify that the API and API versions are deployed to <ENVIRONMENT> for Testing
4. Check for Payload ranges for Min/Max and Out of Range Values in the body of the payload
5. Check for REST API Response codes as listed on the YAML/API
- 200: OK
- 201: for PUT it is a Create request
- 400/404/409: refer to Network or Resource Errors
- 50x: refer to Server Logs for Error
6. Match the Data on the UI with the GET/PUT Body to match the value(s) displayed on the UI.
7. Check for Schema Error with Mandatory/Optional fields in the API Body/headers. refer[3] for Schema Validation.
General Checks
- Check for Performance or latency in calling the API(response time as seen for the API to complete round trip).
- Check for CORS/Cross-Site scripting Errors on deployment
- Check for Repeated calls referring to API or Resources that take too long to load(mapped resources are to be hosted on CDN or on a Static content site).
- Pagination and parameterized parameters for client-side queries need to be checked for validation.
- Cybersecurity-related aspects related to Headers and Allowed domains for queries.- also refer to OWASP API Security for OWASP API security.
Opinions expressed by DZone contributors are their own.
Comments