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.


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 will call the same endpoint exactly at the same time it will still work as expected).

The tools which could be user:


Disclaimer: I'm cofounder of Rest Secured.

Depending on your coding skills, you need to choose a tool that will help you automate writing test scripts.

Unit & functional testing

  1. cucumber - github.com/jayzes/cucumber-api-steps
  2. rest assured- github.com/rest-assured/rest-assured

For manual testing, I recommend SoapUI or Postman client where you can manually play with API. SoapUI can help you write more complex scripts. It can help you prepare load testing as well.

I also recommend create schema specification if it doesn't exists - you can read about one here

And finally you can do security testing


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 Nov 9 '16 at 12:47

At Checkly https://checklyhq.com, (full disclaimer: I am a founder) we give you API monitoring with the following perks:

  • Geographic spread: You can run your API monitors from multiple geographic locations to give you a clear and accurate overview of how things are going.

  • JSON payload validation: You have can use our intuitive assertion creator to create simple assertions that checks the most relevant parts of your API's response. Response time, JSON values, headers and even specific element in JSON arrays. (learn more...)

  • Metrics & Alerts: Once run, we collect all connection type metrics like DNS, First-Time-To byte and the full response of your API.

  • Error checks: You can explicitly trigger 404's or 500 errors and treat them as "correct". This way you check for the correct behaviour of your API in error situations.

  • "SSL monitoring". Crucial for availability. We automatically alert you when your SSL certificate is about to expire.

Together, this should give you most of the things you want from your API monitoring. Global coverage, inspection of your payload and historical graphing and alerting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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