About REST : An introduction to REST

HTTP - Hypertext is a text which contains links to other texts.


Hypermedia is not constrained to be text-based. It can include other media, e.g., graphics, images, and especially the continuous media - sound and video.

Ted Nelson used these terms in 1965.

How hypermedia works 
Information is distributed into units, called nodes. Nodes can contain text, graphics, videos, and sound. One unit per window is displayed. Units are linked by links. Clients navigate hypermedia database by selecting links and traverse from one unit to another. In shared hypermedia systems, multiple users may simultaneously access the hypermedia database. Shared systems may be implemented as distributed systems, in which portions of the database are distributed across multiple workstations and file servers on a network.

Below is an example of documents distributed across network and linked to each other -
Ref -http://bernstein.iicm.tugraz.at:8080/Ressourcen/Theses/cguetl_diss/diss_html/literatur/Kapitel04/References/Akscyn_et_al._1988/p820-akscyn.pdf

We can also say hypermedia is a way to transition from one Web page to another.
The use of hypermedia controls, or links, to enable the identification of forward paths in our exploration of the information space is called structural hypermedia.
Information is loaded as lazily as possible, and the user is encouraged to browse pages – traverse a hypermedia structure – to access information. Breaking information into hypermedia-linked structures decreases the load on a service by reducing the amount of data that has to be served.  Instead of downloading the entire information model, the application transfers only the parts pertinent to the user.  Not only does this laziness reduce the load on Web servers, the partitioning of data across pages on the Web allows the network infrastructure itself to cache information.

Structured Hypermedia  
A hypermedia system is characterized by participants transferring resource representations that contain links according to an application protocol. Links advertise other resources participating in the application protocol. Links are often enhanced with semantic markup to give domain-specific meanings to the resources they identify. For example, in a consumer-service interaction, the consumer submits an initial request to the entry point of the service. The service handles the request and responds with a resource representation populated with links. The consumer chooses one of these links and interacts with the resource identified by the link in order to transition to the next step in the
interaction, whereupon the process repeats. Over the course of several such interactions, the consumer progresses towards its goal. In other words, the distributed application’s state changes. 
- http://dret.net/lectures/ppos/reading/wsrest2010-hypermedia.pdf

Resource Representation
Transformation of application state is the result of the systemic behavior of the whole: the service, the consumer, the exchange of hypermedia–friendly resource representations, and the acts of advertising and selecting links. Access to a resource is always mediated by way of its representations.Resource representation is a view of resource's state at an instant in time encoded in one or more transferable formats like xhtml, xml, atom, json, etc. Access to a resource is always mediated by way of its representations. That is, Web services exchange representations of their resources with consumers. They never provide access to the actual state of the underlying resources directly – the Web does not support pointers! URIs are used to relate, connect, and associate representations with their resources on the Web.

Distributed Hypermedia & REST-
REST was described in the Roy Thomas Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures". 
Fielding also coined the phrase ―Hypermedia as the Engine of Application State - to describe a core tenet of the REST architectural style
He mentioned - 
"Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Distributed hypermedia allows the presentation and control information to be stored at remote locations. By its nature, user actions within a distributed hypermedia system require the transfer of large amounts of data from where the data is stored to where it is used. Thus, the Web architecture must be designed for large-grain data transfer.
The usability of hypermedia interaction is highly sensitive to user-perceived latency: the time between selecting a link and the rendering of a usable result. Since the Web's information sources are distributed across the global Internet, the architecture needs to minimize network interactions (round-trips within the data transfer protocols).".


Roy Fielding mentioned, there are two ways to design or start on application -
REST follow the second approach. We start wil blank and apply following constraints one by one -
1. Null state - No boundries between systems
2. Client-Server -> [ Client - Server ] OR [ UI concerns - Data storage ] 
3. CSS (client stateless server) style -> All requests from client to server will contain all information. This constraint induces visibility, reliability, and scalability.
4. client-cache-stateless-server -> cache constraints -> data in response should be labeled cacheable or not. Improve efficiency, scalability, and performance.
5. Uniform interface between components -> identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
6. Layered system -> Component can't see beyond layer with which it is interecting
7. Code-on-demand -> Allows client functionality to be extended by downloading and executing code in the form of applets or scripts

RR - replicated repository (more than one process provide the same service)
$ - cache (replication of the result of an individual request such that it may be reused by later requests)
U - uniform
CS - client server
LS - layered system
VM - virtual machine
COD - code on demand
LCS - layered client server
CSS - client stateless server
C$SS - client cache stateless server
LC$SS - layered client cache stateless server
LCODC$SS - layered code on demand client cache stateless server

Above figure by Roy Fielding shows how REST architecture style is derived from several architecture style.
If it's too complex, below is the simple one from book - "REST: From Research to Practice"
Lets again revisit the constrains -
1. Client - server : Client initiates the request and server responds
2. Statelessness : Server should not be responsible for remembering every client, Server should be able to forget a client instantly
3. Caching : If every client has to cpeak directly to the server everytime then they wont be able to scale.
4. Uniform interface : Everyone on the web has to use exact same API
5. Layered System : We can add or remove hardware anytime without any downtime. The Web has to up 24/7, it has to be ready to grow along the way. We can hardware even after 10 years
6. Code-on-demand : We send the code to the client and let code run on client. Originally this idea was applied to Applets, ActiveX but now more common is JavaScript.


What are components? We can identify lots of components: databases; file systems; message queues; transaction-manager tools; all your source code. These are components.
Fielding wanted to constrain the way things connect to each other, not the way they(components) operate.
components. I dont care what database you use, how often you change, and how it works.
What are Connectors? Connectors include Web servers, browser agents like your typical browser, proxy servers, caching servers, etc.. These connectors are the things that understand how that one API works. And, on the Web, that one API is most often the HTTP protocol.

When we build application, we dont build connector, we use them. We decide on what programming language to use, and language has HTTP connectors and caching connectors in libraries.
While creating application, how do I make connector model work, i.e. generic connectors - I use Uniform Interface

I was reading the REST magazine from InfoQ, and they have explained REST in simple terms and also explained the Roy Fielding's paper in simple.
What we have understood till and what we can say is REST is about maximizing the full potential of web, and it starts with -
Give everything an ID - yes like Amazon has to give an ID to every product they sell. Now according to REST id should be URI, so that we have consistent scheme and no one comes up his or her own naming scheme. Thing is a resource but can be far more abstract - a database entry like order item or combination of database items like order (multiple order items form one order). Optionally URI's should be human readable.
Links things together - HATEOAS - A link can follow more links - Client calls link to obtain resource and also more links to obtain more information.  Server (or service provider) provides a set of links to the client (the service consumer) enables the client to move the application from one state to the next by following a link.
Use standard methods - We type URI in browser and browser knows what to do with it, and so every resource should share same interface and same methods (operations) : GET, POST, PUT, HEAD, etc. In Java terms we can assume that every resource extends a Resource interface, and same interface is used by every resource -
GET supports efficient caching - idempotence means if we don't receive response then issue request again. PUT(update this resource with this data, or create it at this URI if it’s not there already) & DELETE are also idempotent. POST means create new resource.
In REST, we have to come up with generic interface and don't provide different set of operations for different set of resources like OrderService with createOrder operation AND CustomerService with addCustomer operation, instead it should be like -

So fix set of operations but indeed universe of resources (sadly).
Resource with multiple representations - how does client how to deal with data it receives ? Simple solution is the client asks for a representation in particular format -
The result is company specific xml format.
Communicate Statelessly - Server should not maintain communication state. Obvious reason is scalability - number of clients interacting will seriously impact server footprint. Statelessness also means two requests from same client can land to two different servers.

References -