I want to know apart form verifying status codes ( 200, 400, 500 ) and json what else we can verify to make sure API's work as intended ? PS : I have little Idea about Schema validation as well. If anybody can help me with the good resources ( Blog, website ) etc It will be great. And I am looking for both manual and automation testing for the same.

5 Answers 5


I really like this question, it's something I've thought about a lot. Validation response codes and a JSON body is a good start, but like you said, there's a lot more that can be done.

I built an API testing tool Assertible (https://assertible.com), and have written a few blogs on approaching different ways to test/validate a REST API, these are some of the higher-value ways:

  • Contract testing / schema validation - you briefly mentioned this one, but JSON Schema validation is a big one as it gives you way to test the entire nested response body to ensure every field is correct.
  • Response time and performance testing - testing response times ensures that the API replies to the request in a decent time-frame. We use this at Assertible to ensure our Dashboard and website pages load quickly. This is more important on GET requests that it is on POST/PUT/DELETE.
  • Testing malformed requests - this is an important one, actually. How does your API response when you send a malformed request? Try a method that shouldn't be allowed on a certain endpoint. Omit keys from POST bodies and see what happens. You'd be surprised how many APIs doesn't validate requst bodies.
  • API security monitoring - Similar to the above point, try testing an HTTPS API over HTTP. Is any sensitive data exposed?
  • Health checks and performance testing - This is more basic status code validation, but run very frequently (like 1 or 5 minute intervals). You can pick up brief outages that give you information on stuff you never even know happened!


Those approaches are all taken from various blogs I've written on Assertible:

Hope this is helpful!


REST API is just an API to a system, so the way the system responds to your request depends often not only on your request but also on the state of your system and time when you call it. So you should control those elements in your tests as well. For instance, whether money transfer request will be successful depends on whether a source account has enough money.

And the response of your REST API is not the only things that happens after your request. System have also intended side-effects that you may need to check. For instance, when you request money transfer the response might be HTTP 200 (OK) but additional side effect is that on a target account you should expect balance increase.

Obviously, there are additional things specific for REST and HTTP, e.g.:

  • checking how the system behaves when some request headers are missing, e.g., Content-Type, Authorization, etc.
  • checking what happens if you provide query parameters for a method that should accept only form parameters in a body
  • verifying whether a protected resource is not available over HTTP when it should be only on HTTPS

Tools: Web browser (for GET requests), curl, REST-Assured, Retrofit, Postman, SOAP UI.


The best reference to design your test cases is API documentation a.k.a API contract. This document describes:

  • How to call the APIs
  • What to expect from them

Generally, you can have these kind of test levels for your APIs (based on the contract):

  1. Acceptance testing
  2. Contract testing e.g. pack (includes your idea: schema validation)
  3. Performance testing

Performance Testing (or at least some concurrency testing to ensure that if 2 users call the same endpoint exactly at the same time it will still work as expected).

The tools which could be used:


Apart from the things mentioned above you can also check response time, validate schema, check the entire response,etc using Rest Assured which is a Java Library.

I would recommend you to check my blog:

Check Response time using Rest Assured

It's a step by step tutorial on testing REST API.

  • You need to state in your answer that you wrote the blog you linked to, or you risk your answer being deleted as spam.
    – Kate Paulk
    Commented Nov 9, 2016 at 12:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.