REpresentational State Transfer (RESTful) Web Services
By: Mohit Sharma
Tags: API, Restful, Rest Api, Statelessness, Restful Service

Web Services

In the most layman terms, web services are client and server applications that communicate over WWW/HTTP.

Now both client and server can be written in different languages and running on completely different platforms and frameworks. For example, the server can be written in Java and the client can be written in Ruby. So, how do they communicate with each other?

Well, this is where web services come into the picture. Web services provide a standard means of inter-operating between client and server by using open standards such as HTML, XML, WSDL, and SOAP.

For example, through Web services, a Windows server can interact with a Linux server or serve an application to computer desktops, laptops or smartphones and other mobile devices over the World Wide Web (WWW).

Types of Web Services

Big Web Services uses XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats. RESTful Web Services is an architecture style for designing network applications. It relies on stateless, client-server architecture, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol. It treats server objects as resources that can be created or destroyed.

Stateful vs Stateless System

Stateless System: A stateless system can be seen as a black box where at any point in time the value of the output(s) depends only on the value of the input(s).

From the parallel programming point of view, a stateless system, if properly implemented, can be executed by multiple threads/tasks at the same time without any concurrency issue.

Stateful System: A stateful system instead can be seen as a box where at any point in time the value of the output(s) depends on the value of the input(s) and of an internal state.

So, basically, a stateful system is like a state machine with “memory” as the same set of input(s) value can generate different output(s) depending on the previous input(s) received by the system.

A stateful system will require that multiple threads of execution access and update the internal state of the system in an exclusive way, hence there will be a need for a serialization [synchronization] point.

Let’s understand stateful and stateless architecture with the help of a basic authentication sequence. Let’s say a user wants to view his profile on some website.

Stateful System:

User sends http://IP_of_LoadBalancer?user='mohit'&password='abc'. This request goes to Load Balancer. State store DB maintains session key and is used to ensure that the requests from the same user go to the same server. So for the first time, Load Balancer creates an entry something like “All the requests coming from a user should go to server-1(let’s say)”. Load Balancer selects the server and redirects the login request to server-1 only. Server-1 receives the request, validate the credentials by querying the DB and if the user is actually who he says he is, then server-1 marks logged_in flag to true. So logged_in is actually maintaining the state. Server-1 sends back the request to Load Balancer Load Balancer returns the response back to the user. Now user sends http://IP_of_LoadBalancer/view-profile to Load Balancer Load Balancer fetches from state store which server will handle the request from user. (i.e server-1) and redirects the request to it. Server-1 receives the request. Also since the logged_in flag is marked as true, server-1 may fetch the requested content from DB and respond back to Load Balancer with the response. Load Balancer sends the response back to the user.

Disadvantage:

But what would happen if the selected server goes down in the middle of the request? Clearly, no other server can handle the request because they don’t know about the state of the user. So the user has to login again.

Suppose you’re buying some product on an e-commerce website and adding the products you want to buy in the shopping cart. Suddenly the server handling your requests goes down. What then? Not only will you have to login again but to add the same products again in the shopping cart.

Stateless System:

User sends http://IP_of_LoadBalancer?user='mohit'&password='abc'. This request goes to Load Balancer. Load Balancer selects a server (server-1) based on some selection strategy and sends the request to that server. Server-1 creates a session entry in session table of DB and generate some token. Server-1 takes the token which often has validity as well and returns the response back to Load Balancer. Load Balancer returns the response back to the user. {status:”200 OK”, response:{token:”xyz”, valid_till:”30 mins”}} Now user again sends request http://IP_of_loadBalancer?token='xyz' Load Balancer receives the request and again based on some selection strategy (server-2 let’s say). Server-2 validates the token by querying in session table of DB If token validates, server-2 sends back requested response back to Load Balancer Load Balancer then sends the response back to the user

A good test is to consider whether the interaction can survive a restart of the server.

Key elements of RESTful implementation

Resources: Data and functionalities are considered resources and are accessed using Uniform Resource Identifiers (URIs) also called endpoints. The resources are acted upon by using a set of simple, well-defined operations called Request verbs. Request Verbs:

GET: retrieve data from a specified resource.

PUT: Update the specified resource.

POST: Submit new resource to the server.

DELETE: Delete already existing resource from the server

HEAD: Same as get but does not return a body.

OPTION: returns supported HTTP method.

PATCH: Update partial resources. Request Headers: Additional instructions sent along with the request. These might define the type of response required or the authorization headers. Request Body : Data sent along with the request. Response Body: Data received from server. Response Status codes:

2xx Success: 200 OK, 201 Created

3xx Redirection: 301 Moved Permanently, 304 Not Modified, 307 Temporary Redirect

4xx Client Error : 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 408 Request Timeout

5xx Server Error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

Thanks for reading!!