API Structure

Objective: This Document represents API Structure which requires to be maintained while
developing any project which includes APIs. There are rules and practices must be covered.

Introduction: We are having two structures to build RequestAPI and ResponseAPI named
as Request Construction and Respond Construction. This structure bifurcate each on into
Actions, Device, Status (Exclusive for response) and Data.

Practices:
1) In Login Response (On success) API, There will be one compulsory parameter named
TokenId which must be passed under section of Device. This will be a random string
generated automatically and lives till the session of user who is logged in. That
TokenID should be in every Request json inside Device Section, All the activities done
by user after login. This TokenId will be updated every time into database.
2) All the Section Headers must have initial letter capital.
3) All the Keys must have initial letter capital. Keys which contain more than a word
must contains initial letter capital of each words like InputParamer1, FirstName.
4) All the Data contain in Values of related Key can have any data type and any format.
If in case of Null return of any specific values could be replaced constant Value
_ZERO.
5) API name must be Action name. Each API must have unique identification number
inside Header section, value of key ID
6) There must API Document which includes All APIs details (Data, key, Inter-related
Effects) and Team Lead, Developers of both platform and Q/A must know overall flow.
The Document also consists of data entry of employees who have updated it last with
brief description of what has been updated.
7) CODES for response status Identification.
> 200 OK
> 400 Bad Request
> 401 Unauthorized (TokenId Wrong, Login Credential Failure)
> 404 No Action Found
> 408 Time out
> 500 Server Error

Vishal Vyas

Page 1

API Structure
REQUEST CONSTRUCTION:
{
Header:
{
Id: Numerical Value
Action: Web service Name,
Description: Screen Name: Purpose brief
},
Device:
{
TokenId:Token-Id received after Login,
DeviceId:Device Id of instrument from where request is received,
DeviceType:Android/Iphone/Ipad/Tablet/WindowsPhone,
TimeStamp:DD-MM-YYYY HH:MM:SS
},
Data:
{
InputParameter1:Value1,
InputParameter2:Value2,
..
InputParameterN:ValueN
}
}

RESPONSE CONSTRUCTION:
{

Vishal Vyas

Page 2

API Structure
Header: {
Id: Numerical Value,
Action: Web service Name,
Description: Screen Name: Purpose brief
},
Device:
{
TokenId: TokenId generated for User Session /* ONLY WHEN LOGIN SUCCESSFULLY */
DeviceId:Device Id of instrument from where request is received,
DeviceType:Android/Iphone/Ipad/Tablet/WindowsPhone,
Timestamp: DD-MM-YYYY HH:MM:SS
},
Status:
{
Code: 200/400/401/404/408/500,
u_Message: Message for User,
p_Message: Message for Developer,
Status: Success/Failure
},
Data:
{
OutPutParameter1: Value1,
OutPutParameter2: Value2,
TokenId: TokenId,

/* ONLY APPLICABLE WHEN LOGIN API RESPONDS with

SUCCESS */

OutPutParameterN: ValueN
}
}

Testing Methodologies/Practices

Vishal Vyas

Page 3

API Structure
Goal is to describe some of the practices that have worked well for ECS while
testing the all the API Projects. We hope that the information that I detail here will
be beneficial and useful in next tests cases.
1) There must be priority when Test Cases started to performed by Q/A Engineer
or API Team.
2) For the API which starts to develop needed to be verified with configuration
environment of development tools. There must be a technical feasibility
study.
3) For cases like these you will probably have excel sheet mechanism to check
behavior of API on the system. For example, if you need to write test cases
for delete (List Element) function you will probably validate size of the list,
absence of list element in the list.
4) If API is triggering some event or raising some interrupt, then you need to
listen for those events and interrupt listener. Your test suite should call
appropriate API and asserts should be on the interrupts and listener.
5) Make sure of Request data (JSON/XML) in exact structure that has defined.
6) Make sure of Response data (JSON/XML) in exact structure that has defined.
7) Iterative Data (JSON/XML) must be coded as an Array.
8) If responded - API key returns any NULL values then it must contain constant
value _ZERO.
9) In the Data Section of any construction (request/respond) , Mobile Developer
and Web Developer must need to confirm about Keys and Data which will be
received/sent after it has been developed. This Scenario must cover all
interlinks of database as well as mobile screens.
To achieve it, there must be a document consist of API data-values of each
and every APIs Function along with URLs. Any modification in the document
must be acknowledged by APIs Team and Mobile Team.
10)
There must be naming conventions of any type of file which is to be
uploaded on server from portable device.
11)
There must be scenario testing after one request and response
travelled successfully.
12)
There must be request validation before accepting values and make
required action on them from request parameter.
13)
Message should be easy and to the point, so that one can really predict
where the glitch is!
14)
On Occurring on any error, API developer need to maintain Log Table
which will revised and stored with its Time Stamp and User Details
15)
Tester should be aware of whole flow before started API to develop.
16)
Along with Data sending and retrieval, API Team and Mobile Team also
maintain a flow which could be previously decided. There may be related
entries of each screen, so a API response/Request have ability to change
other data values, those related data, API, screen and Database effect needs
to be cross verify. If the API has dependencies, you may choose to mock
those dependencies out so you can more thoroughly test all of those
interactions and hit all of the positive and negative code paths.
Vishal Vyas

Page 4

API Structure

17)
Special care must be taken while handling one time call functions like Delete, Close Window.
There are some APIs which can be called one time for one session, APIs team
has to be sure that, there will be no change, no crash while it repeatedly
called.
18)
There must be limit in insertion of data, Mobile App user must not
allowed to upload, insert limitless records/files because it contains security
risk of dummy data entries.
19)
There must be preemption of sql queries in Data section of
Request/Response.
20)
There must not be unusual flags.
21)
Duplicate entries of same data must not occur, API Team must take
care of this scenario

Test Case

Vishal Vyas

Page 5

API Structure

Vishal Vyas

Page 6