API Testing Tutorial Part 8 – Introduction to REST & REST API

Hello Folks,

As part of our API Testing series, we will see below topics in this post:

  1. What is REST?
  2. Six principles of REST.

 

What is REST?

REST stands for REpresentational State Transfer. It is an architectural style that defines a set of constraints to be used for creating web services or API. Web services which are built using REST are called REST API or RESTFul API or web services. These web services provide interoperability(Communication) between computer systems on the Internet. REST-compliant web services allow the requesting systems to access and manipulate textual representations of web resources by using a uniform and predefined set of stateless operations.

It was introduced by Roy Fielding in his 2000 PhD dissertation “Architectural Styles and the Design of Network-based Software Architectures”.

Wikipedia defines REST in very crispy way as below:

Representational State Transfer (REST) term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state-machine) where the user progresses through the application by selecting links, such as /user/tom, and operations such as GET or DELETE (state transitions), resulting in the next resource (representing the next state of the application) being transferred to the user for their use. By using a stateless protocol and standard operations, REST systems aim for fast performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system as a whole, even while it is running.

Six principles of REST:

REST provides six guidance principles or constraints which must be satisfied if an API is called as RESTFul API. Those principles are as below:

  1. Client–server architecture
  2. Statelessness
  3. Cacheability
  4. Uniform interface
  5. Layered system
  6. Code on demand

 

Client–server architecture:

You request for available flight details from an Airlines provider on internet. At high level you are a client who is requesting data from an Airlines provider (Server) over HTTP. It is called Client-server architecture. It separates Client and Server related things. You can request airlines details from multiple platforms. Separating user interface concerns from the data storage concerns improves the portability of the user interface across multiple platforms improve scalability by simplifying the server components.

Statelessness:

In client-server architecture, server does not save any information about client between requests. Every request to server from any client must contain all required information so that server can understand and response with proper response. It does not matter if same client is sending request to same resource multiple times. Session state is therefore kept entirely on the client.

Cacheable:

We know response is returned by server on request of client. This response may be cacheable which helps in reusing data for later equivalent requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance. A REST API should be designed to encourage the storage of cacheable data.

Uniform interface:

Client-server architecture separates or decouples the the architecture, which enables each part to evolve independently. Changes at either architecture, will not impact others. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

Layered system:

In Client-server architecture , we generally see two layers but in fact there are so many layers with some responsibilities in between request and response. These Intermediary servers/layers can improve system scalability by enabling load balancing and by providing shared caches. They can also enforce security policies.

Code on demand:

This is an optional constraints which allows for code or applets or client-side scripts such as JavaScript to be transmitted via the API for use within the application.

More about API Testing in upcoming posts. Stay tuned.

If you have any doubt, feel free to comment below.
If you like my posts, please like, comment, share and subscribe.
#ThanksForReading
#HappyApiTesting

 

 

2 thoughts on “API Testing Tutorial Part 8 – Introduction to REST & REST API”

Leave a Reply

Your email address will not be published. Required fields are marked *