5 important validations when testing an endpoint

1. The response code

The most basic test when validating an endpoint is the code of the response.
Usually, the happy path will have a 200 status response — sometimes a 202. (For an incomplete process).

Validation of negative scenarios (or error response codes) should also be included, such as 400–404–409.

2. The message response

Along with the status, validation of the expected response in each case. It’s usually in the form of a Json schema.
The response message we get should match the expectation in the User story or documentation.
This tool can help us compare two Json texts automatically: http://www.jsondiff.com/

3. The orchestration

The orchestration is the way the endpoints connect with each other (Sometimes within different APIs) and serve as input for other calls.
The architects High Level Design (Or Detailed Design) should include one or several diagrams depending on the flow to be build which will be helpful once we start working on these more complex scenarios.

4. The Max and Min values

As the name indicates, this are more simple (But sometimes tedious) validations. Max and Min values are often overstepped but it’s necessary specially on endpoints that are client exposed.
Usually we would use boundary values, which would include for example:

Field: Name
Min: 1 Max: 40

Validations:
0 (empty) — 1–2- 39–40–41
where 0: invalid,
1: valid
2: valid
39: valid
40: valid
41: invalid

You can check the tool https://www.charactercountonline.com/ which I use when having to execute this type of testing so I don’t have to count them manually.

5. The data input type

Similar to the above validation, endpoint fields need to be validated on the type of input they expect.
Could be a string, boolean, int, enum. We need make sure that we are not setting “true” as a string for a field that is expecting a boolean because this could cause issues in the db or the endpoint that consume and uses that field in the full flow.