REST API Testing

By Qautomation on May 28, 2019 • ( Leave a comment )

An API or Application Programming Interface is a set of programming instructions for accessing a web-based software application.

In other words, a set of commands used by an individual program to communicate with one another directly and use each other’s functions to get information.

Rest stands for Representational State Transfer.REST is a software architecture style, commonly used for web services.

REST (Representational State Transfer) is a software design pattern typically used for web applications. We can think about REST as a software architecture style. The basic idea of REST is treating objects on the server-side (e.g rows in a database table) as resources that can be created or destroyed. When we say RESTful APIs we are referring to the web services implementation of REST architecture.

The word “representational” means there is a transfer of representations of resources, and the resources can be pretty much anything that can be named on the Internet like a list of users or a list of photos, comments, posts, articles, pages, videos, books, profiles, etc. To understand how exactly we get a representation of resources, you need to look at how everyone interacts with web pages, the client-server model, and the HTTP. Here’s the HTTP protocol:

Everytime you type a URL in a browser, you’re sending a request to the web server and the web server responds with a resource. What’s important to understand here is, everytime you type a URL in a browser or click on a webpage link, you’re sending a request for a specific resource or resources from a web server. And the web server responds and delivers the request your resource to your browser as in a formal web page or whatever format that the resource is in. The second important point to understand is that the web server doesn’t actually deliver the resources. It doesn’t send you the database that it has, but rather a representation of that resource in a format that is readable. For example, HTML or an image. Think of actual resources, physical things located on a web server database or stored a web server hard drive, and representations of those resources as copies in either readable format for human beings like HTML or image or easy-to-work-with formats for programmers like JSON and XML. It’s also helpful to think of the whole web as a bunch of resources. We always request the resource when clicking on a link or type in a URL, no wonder that URL stands for Uniform Resource Locator.

So what’s about the word “state?” Take a look at an example: whenever I click a link, the application state changes and I am presented with another resource, which is a page with all the other content of that resource. And as I click through all these different pages, the application state keep changing from one state to the next. When the resource gets transferred from the web server, we send a request for the resource and we get a representation back and whatever formats the resources presented. This is what is meant by the word “transfer.” However, it can also refer to the transfer of the application state when we click on the next link and get transferred to another page.

The most basic way of thinking about RESTful is as a way of formatting the URLs of your web applications. For example, if your resource was called “articles”, then:

/articles – How a user accesses ALL posts.
/articles/:id -How a user accesses and views an individual post which was retrieved based on their unique id.
/articles/new How a form for creating a new post is displayed.

RESTful API defines a set of functions that developers can use to perform requests and receive responses via HTTP protocol, such as GET, POST, PUT and DELETE.

Sending a GET request to /users would retrieve the users from the database level.
Sending a POST request to /users would create a new user on the database level.
Sending a PUT request to /users/:id would update the attributes of a given user, again identified by a unique id.
Sending a DELETE request to /users/:id would delete a given user, again identified by a unique id.

So in a nutshell here is what each of these request types map to: