Blog

Recently, I got a chance to test some APIs developed for a large and complex ads-network system. As per my experience, testing an API from Black box approach is simply about testing requests-responses. APIs can return responses in form of JSON, XML, CSV, HTML etc.

In this blog, I will focus only on JSON response type and the guidelines/standards to test it. As we know a properly designed API should return two things in response: an HTTP response status-code and the response body.

HTTP Status Codes:

Testing the status-code is especially important for web applications having authentication and permissions set. Below is a list of the HTTP response status codes for the GET (retrieve), POST (create), PUT (modify), and DELETE operations that are normally used in APIs.

200: OK – Self-explanatory, the request went successful
204: No Content – Request was successful but no response body is required
400: Bad Request – Malformed syntax or query
401: Unauthorized – Authentication credentials were invalid
403: Forbidden – The resource requested is not accessible
404: Not Found – The resource doesn’t exist on the server
501: Not Implemented – Request sent not implemented yet
503: Service Not Available – Service not available at the moment
A detailed list of HTTP Status codes could be found on W3Schools or Yahoo API guide.

Response Body:

Response body contains the resources or data that is requested. Data should be present in proper JSON format. JSON format validation could be done using tools like JSON-Lint. Response body should not contain any attributes that were not requested or that are private. It is quite simple to test GET requests, but becomes little complicated while testing response to POST or DELETE requests. To completely test POST/DELETE requests, it is important to validate that request has made expected effects on other end.