REST stands for REpresentational State Transfer. It was introduced by Roy Fielding as a part of his doctoral dissertation. It’s purpose is to allow the use of data while not having it tied to an entity specifically. This allows the data to be represented differently through various mediums we refer to as hypermedia.
A RESTful interface is resource dependent. In order for an application to follow REST guidelines, it must adhere to a set of constraints. The first constraint states an interface should interact on a client-server basis. The client machine should be able to make requests to the server, and in return the server will respond according to the information it received.
The second constraint states the client-server interaction must utilize a uniform interface. In order for the client and server to interact RESTfully, the use of Universal Resource Identifiers (URIs) is imperative. Any resource that is involved between the client and server must be identifiable in order for the interaction to be successful.
Thirdly, all requests between the client and server must be stateless. This means that a request made from the client side must have all the necessary information so the server can complete the request. This is necessary to keep the workload on the server to a minimum as it handles various requests from different clients. The burden of keeping track of the session state of the application is the responsibility of the client, and it basically gives a snapshot of the current state to the server when the request for additional resources is made.
The fourth constraint states that any response from the server must either be cacheable or non-cacheable. This will allow the client to reuse data from a request for a certain period of time (if the server allows it) without having to resend the request to the server.
The fifth constraint states that the client and server should have layers in between them. This allows legacy systems to have continued support as improvements and new features are added to the system. This will continue to work as long as the implementation of the interface has not been changed.
The last constraint is an optional one and it’s called code on demand. This constraint states that the functionality of a client can be extended by allowing code to be downloaded and executed. This allows the client to be simpler.
While I found all of this to be informative, I was mostly taken aback that the formulation of this architecture is to be accredited to a student pursuing their doctorate degree. It places things in perspective for me that any assignment that I am given does not only have to be completed for a grade, but it can be used as an opportunity to change the way the world interacts with things.
The information that I conveyed in this post is all thanks to two the following links
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.