From Grundy
Jump to navigation Jump to search

REST is short for REpresentational State Transfer.

Unlike the Wikipedia article linked above which you can refer for an apt technical description of RESTful, let us try to explore a hands-on description of what REST is really about. In simple words, it is manipulating server state based by making certain requests by the client, and rendering the output given by the server based on its current state. For my fellow digital electronics enthusiasts, the server is a finite state machine which gives a certain output based on its state and changes state based on the input given. Look at this piece of Python code which handles adding, modifying and deleting student records, built for managing a class of projects as part of the Rattlesnake project.

Use it

You simply need to download the file and use it as python in the respective directory to try and execute the code. You will understand the following sections better if you tinker around with the application first.

Let us Understand

We will walk through the program as it is executed. The main loop of the program is the following

177 while True:
178     # "server"-side computation
179     state_representation, links = handle_request(*request)
180     # "client"-side computation
181     request = render_and_get_input(state_representation, links)

What's going on here? It is a two-step process.

  1. The server tries to process the request sent by the client, and return a representation of the present state of the server.
  2. The client renders an output to the interface based on the server's response and then waits for the user to provide the next input.

For our present purposes, there are two types of requests, GET and POST. In the grand scheme of things, the only difference is that a POST request sends some sort of data to the server. With this setup, let us enter the program, the first line to be executed is l 179 with the following input

176 request = ["get", "default", None]

This is a GET request with the parameter default and no data to go with it.

How is this request handled? The handle_request function interprets this as a call to the fuction default_get_handler which has a simple code.

15 def default_get_handler(args):
16     rep = "What would you like to do?"
17     rep += "\n1 - Quit" + "\n2 - Upload File"
18     links = {"1" : ["post", "execution", None], "2" : ["get", "file_form", None]}
19     return rep, links

The representation is asking the user for options, and the options are sent as data. The next line to be executed is l 181, which displays the rep and based on the response, passes the respective link as the next request to be sent and we're back at l 179 and so on.

This is the entirety of the execution process, and the different actions differ on what the server does for each request. As an example, consider the add_post_handler which adds a student.

35 def add_post_handler(args):
36     def add_to_data(new_data):
37         for key in data:
38             data[key].append(new_data[0].split(','))
40     if args == None:
41         return error_state()
42     new_data = args
43     try:
44         add_to_data(new_data)
45     except:
46         return error_state()
48     return main_get_handler([session['filename']])

Here the client also passes a data as an argument, which is added to the data dictionary.


If you examine the code carefully, there is another concept at play here, which is sessions. The filename is stored in a global session dictionary, maintaining some state of the connection au contraire the traditional stateless RESTful service.

Moral of the Story

The server-client HTTP model is implemented using the same concept which is exemplified with a small Python program above. The only difference is that the server lies on a different computer connected to the client computer by the Internet, unlike this program where all data is stored in program heap and available to all processes trivially.