API Testing


Veteran Agile evangelist Martin Fowler famously postulated the Test Pyramid, which defines a level of measure of importance of the types of tests that you should be doing. If you take a look at the pyramid – it consists of basically three levels

  • Unit Tests
  • Service or Integration Tests
  • UI or E2E Tests


Integrations tests, like UI tests, slice through various layers of the application, but in this case they don’t go through the UI. Here, in the case of this web application, the integration tests mimics the HTTP calls the browser would normally be making on behalf of the user as they were logging.

So, for example to visit the login page, an integration test would send an HTTP GET request to the web server with the address of the login page it wants to navigate to.

get log_path

Then it send the username and password, the user would have normally entered, with something called an HTTP POST which would include the user’s credentials

post login_path, session: { email: ‘user@test.com’, ‘password: ‘password’ }




Now a days most of the applications implement the integration using what we call webservices or API. If you don’t know what API’s are, please take a look at this wonderful explanation provided on wikipedia.

There are two major types of web-services that exist in today’s applications ( there are more though) –

  • SOAP
  • REST

For the sake of the tutorials, we shall focus on the second one – which is REST.

REST stands for Representational State Transfer. REST is nothing but a software architecture that is based on stateless communication protocols, most commonly using either HTTP or HTTPS. REST commonly returns data in lightweight data formats like XML, YAML or the most commonly used JSON. The basic idea of REST is treated objects on the server side as resources that can be created, edited or destroyed. So when we say REST API’s or RESTful API’s we’re actually referring to the web services that are implementing the REST architecture.

REST defines a set of commands or functions that the developers can use to perform requests, receive response, edit that response, authentication etc. via the HTTP protocol. Some of the most common REST verbs that are used are

  • GET
  • POST
  • PUT

There are other than these four verbs – like HEAD etc. but these four are the main stay of any web services developed using REST.


Now since most of the web applications now a days maintain some kind of web services or rely on the web services over the internet, so it becomes very important to test these API’s or web services (these terms are used interchangeably). To test these API’s there are two major approaches – you can use either a manual testing approach or use an Automation tool to do the same.

There are a couple of tools that can help you manually test the REST API’s  –

  • Advanced REST Client
  • curl command
  • Fiddler

On the other hands there are a vast number or tools that can be used for automation of REST API testing. Some of them are


In the coming series we’ll try to explore each of these tools. I have already written a tutorial about Postman , and how to automate the API’s using JavaScript libraries and Postman. You can read the first part here.